I merely brought up the use of "vector to VGA" for simulation purposes only :-)! It is downright
satanic to play vector games on a raster monitor :-) (although MikeJ's Asteroids DEluxe did look rather cool
on an LCD)! Also, I agree that the focus of this should just be for CCPU replacement .... maybe the ability to use a different vector monitor .... but nothing more. With some slight modifications, you could use that vector to VGA logic to drive BMP or TIFF files out of your simulations....however, that Excel method you are using is rather slick :-)! Moreover, I don't think
Modelsim XE would simulate at anything near a "respectable level" if you were to add that vector to VGA logic for
simulation.
Chris, based on my experience with this stuff, you are at a point where you are going to have to
go to hardware soon to get a better feel for how well things are working on your end....while it
is excellent that you are cranking out frames, there's also a chance that something else can crash
several hundred frames into the simulation....you'll be waiting forever :-)....just some advice there.
FWIW, however, when I was able to crank out a few frames of an Atari 2600 game, 99% of the time
that game worked 100% perfectly :-)!
William, let me get a text file together for you describing my design and you can upload it if you don't mind. Someone is going to help verify what I have thus far. It'd be pretty funny to have both an RTL and "virtual TTL" level version of the CCPU design
released simultaneously after all of these years :-) (although I think Chris is *very* close). I am swamped for the next few weeks, but I hope that this can be finished once and for all since I am sick of having my version rotting on various hard drives :-)!
I have various ideas for a sound system ... IIRC, many CCPU games have Z80 based sound systems...the Opencores
Z80 model is working just fine. As for the sounds generated by discreet analog components, those can be
emulated by various digital filters and the like. The Z80 core is somewhat large though....nothing earth shattering, but
it won't fit in the tiniest Spartan 3e or Cyclone III device. I think a bank of programmable wave generators would
do the trick for that "discrete" class of sound system (these devices have 18x18 multipliers embedded which really
lighten the load in terms of resource utilization).
This is why I hate jobs...they always get in the way of the fun stuff....but I do enjoy getting paid :-)!
On a more selfish note, I wouldn't mind having the ability to play Solar Quest in my Asteroids Deluxe cabinet :-)!
OK, back to work :-)!
Ed
________________________________
From: William Boucher <boucher@mnsi.net>
To: vectorlist@vectorlist.org
Sent: Friday, April 10, 2009 2:04:57 PM
Subject: Re: VECTOR: Cinematronics CCPU on Xilinx FPGA
Chris...
Regarding: "Agreed, will post what I have done to date, but where
??"
If you want, I will post your files on my own
personal website on www.biltronix.com I'll make a page for
it. I have lots of server space left over so it won't cost me
anything. If you want, type up whatever text you'd like to see describing
it and I'll put that on the new page and create links for people to download
whatever files you want. If you have images (i.e. screenshots) then email
me those as well. I'll put the page together and put it up and keep it
up. If you ever request it to be removed, I will take it down. If
you ever want files replaced with updated ones, just email them to me and I'll
apply them.
Being just a beginner with respect to Xilinx
FPGA/CPLD and VHDL, I am truly impressed with your project. I suppose that
the ultimate evolution of it would be a single design that can play all of the
CCPU based games. Of course that would require adding more logic and a
little more I/O to the design, as well as some new and some modified ROM
code, to allow for game selection. Modified code could re-map the I/O
to make the control panel inputs and sound outputs use common pins. The
new code would take care of the different memory addressing scheme used between
2716 and 2732 ROMs as well as inverted/non-inverted chip select outputs.
Someone would still have to design a multi-game multi-voice sound board
with a logical input for game selection. It could employ fully
digitized sound samples, or it could be a collection of the old style
circuits comprised of modern miniature package styles combined with
new additional logic that selects/enables the sounds for a specific game as
dictated by the new all-in-one CCPU.
For a while last year, I was considering building a
CCPU digital to analog converter to go between the CCPU video output port and an
analog vector monitor such as a GO5-802. Personally, I prefer to rebuild
an original Cine monitor and use that but I'm aware that many people have a
working GO5-801/2 monitor available and either don't have a Cine monitor or
don't know how to rebuild it. I thought that a plug-in converter would
solve that problem. Then someone told me that Mame now plays almost all of
the vector games anyway. I see in this thread also that someone mentioned
modifying the CCPU output by converting it within VHDL into standard video or
HDMI directly. That would eliminate the conversion hardware entirely,
which is great, but... if people are going to play Cine games in Mame or on a
single FPGA, what's the difference? Most people wouldn't know, or care,
how it works anyway. And if they watch it on a HDTV or LCD
monitor regardless, then that furthers my point. I thought that putting
the CCPU onto an FPGA in the first place was so that a person could have a new
board into which they could plug in an original sound board, cp, and Cine
monitor, and play the game with the original controls, original sounds, and a
true vector display. Am I missing something? All of my vector games
run on original, albeit restored, hardware and I truly enjoy that aspect of
them. They hum and buzz and play like they always did since they were
new. Once it all goes onto a new chip, be it a single FPGA driving a new
monitor or a personal computer running Mame or some other emulation, what's
the difference there? Ultimately, when all of the old CCPU boards and Cine
monitors have died, the FPGA and/or PC solutions will be the only way to play
the classic games running their original ROM code, and that's great because it
would be tragic to lose them forever. Maybe that has been the
ultimate goal here and I have been missing that point.
Regardless, I thank that the value of creating an
FPGA solution cannot be underestimated. Even if someone were to route and
manufacture a brand new CCPU board, finding a large stock of all of the original
IC's would not be easy. Heck, finding a programmer that can handle all of
the bproms is challenging too and don't forget that troubleshooting a CCPU using
an exorciser setup takes patience and some skill as well. A single-chip
solution on a board that the other original hardware (mon, cp, sc) plugs into
would be great. I guess the debate over where to draw a line between
original hardware and new hardware, what is acceptable and what is going too
far, will rage forever. I think that PC based solutions are a great
alternative for people who do not have access to original hardware or lack
the skills or funds to repair it. After all, playing the games
on a PC based system is better than nothing and it certainly doesn't take any
value away from the classic machines. For people like myself, I
prefer to repair and run all original hardware even though that reduces the
number of games that I can run. Some people will choose something in
between such plugging the FPGA CCPU into an original machine.
William Boucher
----- Original Message -----
From: Chris Leyson
To: vectorlist@vectorlist.org
Sent: Friday, April 10, 2009 10:32 AM
Subject: Re: VECTOR: Cinematronics CCPU on Xilinx FPGA
Apologies for not replying to all those who kindly posted replies, I've been a little distracted getting the bugs out of the CCPU. Actually, obsessed is more accurate :)
It's really rewarding to see a lot of interest and enthusiasm in the project. Who knows, it could lead on to further things, but more about that later.
I'm reasonable confident in the CCPU model, I've added an IIR filter to simulate the RC network and run through a few frames of Spacewar. Plotting the vector start
and end points in a spreadsheet gives me the start-up screen :). Where are my spaceships !! Damn, haven't done the I/O yet, so no coin input :) Grrrrr
Next step is to clean up the clocking and register some of the glitchy logic.
So, here goes, some replies...
Ed Henciak wrote:
Freakin' sweet :-)! Your best QoR for area is going to be the gate level approach you are taking. The
tradeoff is "time to implement" in most cases.
Also, keep in mind that a behavioral design means exactly what it says...it doesn't mean it is synthesizable.
Moreover, if anyone tells you one way is better than another they are nuts. The example I sent you is more
abstract (i.e. RTL)...what's cool is that XST seems to do a decent job converting what I am "implying" when
I view the design using post-synthesis viewers. Still, area-wise, it will be no match to your results. For
designs like the CCPU, gate level is the way to go....I prefer the RTL approach since that's simply the way
I do things :-)!
I'm more a a "nuts and bolts" guy and would rather follow a schematic, but it all boils down to RTL at the end of the day.
Just a suggestion....goto www.fpgaarcade.com ... there is an Asteroids-on-a-chip package. In there,
MikeJ has a vector-to-VGA converter. You will need to add a ZBT SRAM model to your design.
You might be able to pump out some graphics....just be aware that what you see in simulation may not
match expected results graphics wise :-)!
What version of Modelsim are you using BTW?
Damn that's cool. That'll definitely be the next project, vectors to VGA or PAL, NTSC or HDMI.
PAL/NTSC is easy but HDMI is the way to go. ModelsimXE, the freebee.
Ed Henciak wrote:
Actually, it'd fit comfortably in a dirt cheap Spartan 3e (tiniest one) with room to spare :-)! I was
thinking about using the left over gates for an embedded CPU to drive a kick ass menu system
for the CCPU.
I sent Zonn most of my code a while back...I've been trying to find time to finish this off once and
for all. Quite honestly, if someone can help me with verification, I think we all can have a nice
VHDL model of the CCPU :-)!I basically have coding finished (I need to add the vector draw routines),
but I still want to make a solid testbench to verify the hell out of this thing.Will gladly help with the verification, I guess if we sync on reset we could run two implementations together and
xor test vectors to spot any differences.
A while back I put the Atari 2600 into an FPGA using that Opencores 6502...it's sheer joy to cycle-for-cycledebug a flaky 6502 core :-)!
I think we can do some neat tricks with Zonn's emulator and a VHDL simulation though.
Arghhh..... There are too many flaky cores out there. I like to see block ram microcoded implementations of old 8 bitters.
Wow.. 2600 on a chip, excellent !! Yet another project I'd like to do but haven't had the time. Really like the Atari 2600
games but the poor video quality lets the old consoles down, too much digital crap leaking into the video.
One of the smaller Actel parts might be able to fit the CCPU as well....I can run it thru Synplify in a minute here
to get a gate count...nice thing about them is that they run from a single 3.3V source if I am not mistaken.
Also, you can do neat tricks like run the XY outputs to a single DAC with dual outputs. I would need help with
the amplification part (I know there are analog gurus on this list that can make the "perfect, clean" vector driver :-) ).
I'm aiming to use Spartan 3 for the CCPU , no Actel design experience, so will go for Xilinx primatives in my design.
Agreed, DACs will have to be fast, preferably serial, but will require the analogue switch and RC network, this is
the best option for smooth vectors. The digital approach on the other hand wouldn't need the RC integrator but
would need faster, higher resolution DACs, not exactly cost effective.
Ed
PS If people are *really* interested, I will post what I have here on Vectorlist...I just don't know the protocol
for posting these kinds of things :-)! But I'd LOVE to see this project completed. It's just two text files of
VHDL source. I don't have a webpage or anything...but I'd prefer to keep it amongst us vectorheads for the
time being :-)!
Agreed, will post what I have done to date, but where ??
Omar Vega wrote:
Hey Chris,
Just in case you have more time these days than I do, it will synthesize
into a pretty small part (think spartan II < 100k gates, 50k IIRC). I had a
nice simulation running (starhawk roms) but mine hangs up after about 130 ms
or roughly a couple of full frames of drawing vectors (PITA debug). I agree
that Zonn's simulator is usefull for getting started and so is his
disassembler.
Omar Thanks for the simulator screen shots. It looks as if some of your sequencer logic is halting whilst drawing.
I will try out Starhawks roms and see how it compares.
Chris Schalick wrote:
I got started on a Verilog CCPU a while ago, with the same
structural approach. I got through a thousand instructions
or so till it went red on me, summer showed up and I lost track of it.
Much to my wife's chagrin, I speak Vhdl and would be happy to
help verify if you want help.
Chris
Hi Chris, sorry I can't speak Verilog, but I'm happy to send you what I've done so far so you can
debug the Verilog.
On this note, it's probably a good idea if I sat down and wrote out a few timing diagrams for different
opcode formats, both for even and odd rom addresses.
Chris
--------------------------------------------------------------------------- ** Unsubscribe, subscribe, or view the archives at http://www.vectorlist.org ** Please direct other questions, comments, or problems to
chris@westnet.com
---------------------------------------------------------------------------
** Unsubscribe, subscribe, or view the archives at http://www.vectorlist.org
** Please direct other questions, comments, or problems to chris@westnet.com
Received on Fri Apr 10 15:25:10 2009
This archive was generated by hypermail 2.1.8 : Sat Apr 11 2009 - 16:50:00 EDT