Re: 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_at_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 14:04:41 2009