Has Anyone Worked on an FPGA Atari 7800?

[kevtris]

As the topic title says... I thought I'd give it a go and see what happens. I just finished the FPGA Arcadia 2001 and the 7800 looked like a decent target for the next system.

 

I have some tech information about the system and a few disassemblies which should help matters. Also, a schematic of the Maria chip which is proving invaluable for this project. I don't think it will be 2600 compatible (I already got an FPGA 2600) because of the sheer amount of peripheral logic on that system, but obviously I will simulate the TIA stuff that is required (fire buttons, sound).

[+Stephen]

Sounds great - good luck on your project. Over in the 8-bit forum, there is major progress being made on the Atari 8-bit computer chipset.

[Trebor]

Very cool and best wishes for a successful endeavor, kevtris.

[nichtsnutz]

Hello kevtris,

 

in another thread that I do not find right now, Curt had posted a chip picture of the maria chip

that he had recovered from the original netlist from the tapes.

Unfortunately he has not made the data available public.

May I ask where do you have the schematics from and are they at gate level ?

Is the schematic of the maria chip available for free download ?

 

Greetings,

vasilis

[kevtris]

Hello kevtris,

 

in another thread that I do not find right now, Curt had posted a chip picture of the maria chip

that he had recovered from the original netlist from the tapes.

Unfortunately he has not made the data available public.

May I ask where do you have the schematics from and are they at gate level ?

Is the schematic of the maria chip available for free download ?

 

Greetings,

vasilis

 

Yes, it's transistor level. It's actually a schematic for a combo maria/TIA chip. I've so far found several errors in it though. I have finished converting the dynamic Maria logic into static logic coded in verilog. It took about 6 days to do this, and the end result is around 1300 lines of verilog.

 

So far I have gotten the timing generator to work and it produces the proper 1.78MHz / 1.19MHz clock to the CPU depending on the state of the "slow" line, and it is generating video timing.

 

One odd thing is the 7800 appears to have 263 scanlines per frame, instead of 262. This is either how it is, or it's another error in the schematic. I was going to try and confirm that on the logic analyzer later when I get it running games.

[Trebor]

Maybe this helps

 

https://sites.google...television-tech

 

A post to the 7800 Programming forum may receive responses that can explain too.

 

Eric Ball I believe put together the linked site and is extremely knowledgeable on the internal specifics of the 7800. He noted a difference here between actual measurements and what the schematics stated at least in one case.

 

Not schematics, but some good Maria specifics here:

 

http://www.atarimuse...maria_specs.pdf (March 84)

http://www.atari7800...Maria_Specs.pdf (October 84)

 

Sorry if any of this seems "elementary" kevtris...Just trying to help.

[+Gemintronic]

Would a pre-made board like this be useful or the FPGA in it is too small?

http://dx.com/p/fpga-ask2ca-5-diy-learning-development-board-blue-black-217808

[nichtsnutz]

Hello Kevtris,

 

thank you for your answer.

 

Some years ago, I had done some measurements of the frame timing for PAL here

http://atariage.com/forums/topic/166451-pal-frame-timing/?do=findComment&comment=2057088

and I got horizontal : 454 clocks @ 7,09MHz and 313 lines.

PAL has normally 312,5 Lines per field and normally this is rounded down to 312 lines per frame,

but they have done 313.

So I think, they have done the same for NTSC.

 

Maybe you can tell if the NTSC maria also is doing 454 clocks per line ?

I suggest this,as I think that they only changed the vertical part of the maria chip

and the color generation when doing the PAL chip.

 

Many success with your project!

 

Greetings,

vassilis

[kevtris]

Would a pre-made board like this be useful or the FPGA in it is too small?

http://dx.com/p/fpga...ue-black-217808

 

Naah, that board doesn't have any RAM at all on it and only a 3 bit RGB so it'd be very basic colour wise, and no audio DAC either. I am running my designs on a custom made board. The DE1 or DE2 by Terasic is more what would be required. These boards are fairly nice and have flash, SSRAM, SDRAM, audio/video DACs, and lots of other goodies to help development/debugging. They cost a bit more too, but the cost is actually fairly low for the hardware. You'll have a hard time finding an FPGA that big for less than the cost of the entire dev board since they are subsidized.

 

Right now, I am using an EP3C25 which has 25000 logic blocks (not sure what the equivelant is in xilinx-land), a 24 bit RGB DAC, DVI encoder, and a stereo 24 bit audio DAC. There's also 16Mbytes of SDRAM and a microcontroller and a few other things on there, too.

[kevtris]

Hello Kevtris,

 

thank you for your answer.

 

Some years ago, I had done some measurements of the frame timing for PAL here

http://atariage.com/...g/#entry2057088

and I got horizontal : 454 clocks @ 7,09MHz and 313 lines.

PAL has normally 312,5 Lines per field and normally this is rounded down to 312 lines per frame,

but they have done 313.

So I think, they have done the same for NTSC.

 

Maybe you can tell if the NTSC maria also is doing 454 clocks per line ?

I suggest this,as I think that they only changed the vertical part of the maria chip

and the color generation when doing the PAL chip.

 

Many success with your project!

 

Greetings,

vassilis

 

Thanks! Yeah I am going to put my real 7800 under the knife and hook it up to the logic analyzer to confirm basic frame timing and a few other things. So far I found a few more errors in the schematics with regards to the DMA controller, but I did manage to get the DMA unit to start working! It dutifully fetched some rows of graphics and stuffed it into the line buffer (though I am not sure if that worked, hehe).

 

I was surprised actually how simple the 7800 hardware is- it's really minimal, much simpler than a TMS9918a (colecovision) or NES PPU, or nearly anything else like that. There's just the two line buffers, the DMA engine, and some frame timing and little else.

[Bakasama]

What does this piece do exactly if you don't mind me asking.

[Trebor]

It takes the hardware chips, logic, design found in a 7800 and compresses it into a *much* smaller footprint.

More technical info here: https://en.wikipedia...able_gate_array

[kevtris]

Well I'm nearing the end of the road on the FPGA Atari 7800. Almost all the games are running now. I had an interesting little discovery here. I was sure that Jinks and Tower Toppler still had some major issues, then I realized that it might be OK after all.

 

Turns out they are using NTSC artifacting! Tower Toppler looked terrible until I switched from RGB to NTSC output, then it looked fine.

 

Out of the entire library, all but 10 games are working properly.

 

The Atari 7800 ROM set was in pretty bad shape, too so I cleaned up all the headers. Several of the headers were bad- things like Commando not having the POKEY bit set, and other games having it set that do not have POKEYs, and then the header control bytes being swapped on another. I wrote up my changes in a text file if anyone wants those.

 

(The goal was to have a set of ROMs that do not need CRC testing to make them work which was the point of the header, hehe).

 

There was one weird thing I am still scratching my head at, and that's Realsports Baseball. It appears that they are DMAing too much on part of the logo, so the right half of the logo for 8 scanlines doesn't show up properly. On inspection, the DMA would have to run for a significant number of cycles past the point where it is forced to terminate. I am not sure why this is- could be a bug elsewhere causing it to write a malformed display list in there I guess.

 

Also, the A78 header does not seem to have bits for the Activision and Absolute mappers so I added those. I was toying with adding one more bit to the header to denote Jinks and Tower Toppler so that I can selectively turn on emulation of that NTSC artifacting. Without it, Tower Toppler is horrible looking. I don't want to have it across the board since it will make the sharp 320 pixel mode look terrible on other games.

 

I am working on getting the Maria chip schematics scanned so I will eventually be able to post this- it's just so full of errors and bugs though. Interestingly, the DMA unit IS NOT buggy, which is probably the most important bit. Most of the magic happens there on a 48 state state machine. I have documented most of the states, and it conforms to the existing docs about the chip with regards to timing.

[Trebor]

Turns out they are using NTSC artifacting! Tower Toppler looked terrible until I switched from RGB to NTSC output, then it looked fine.

 

Yep...http://atariage.com/...2/#entry2660238

 

That's why tower Toppler looks horrible under ProSystem or any other Atari 7800 emulator, but shines under MESS Throw on HLSL and YIQ emulation under MESS, and Tower Toppler along with any other game/system that uses NTSC artifacting, will appear as it should on a CRT.

 

Regarding the ROM set(s), you may have some bad ones as Commando (A good dump of it) does have the POKEY bit set and runs beautifully under MESS (Which requires both a good header and the bit to be set to run properly).

 

The 'bad roms' also holds true if you do not see a bits set in the header for Absolute or Activision titles. It is present in the header:

 

/***************************************************************************
CARTRIDGE HANDLING
***************************************************************************/
#define MBANK_TYPE_ATARI 0x0000
#define MBANK_TYPE_ACTIVISION 0x0100
#define MBANK_TYPE_ABSOLUTE 0x0200
/* Header format
0	 Header version	 - 1 byte
1..16 "ATARI7800	 " - 16 bytes
17..48 Cart title	 - 32 bytes
49..52 data length	 - 4 bytes
53..54 cart type		 - 2 bytes
bit 0 0x01 - pokey cart
bit 1 0x02 - supercart bank switched
bit 2 0x04 - supercart RAM at $4000
bit 3 0x08 - additional state->m_ROM at $4000
bit 8-15 - Special
 0 = Normal cart
 1 = Absolute (F18 Hornet)
 2 = Activision
55 controller 1 type - 1 byte
56 controller 2 type - 1 byte
0 = None
1 = Joystick
2 = Light Gun
57 0 = NTSC/1 = PAL
100..127 "ACTUAL CART DATA STARTS HERE" - 28 bytes
Versions:
Version 0: Initial release
Version 1: Added PAL/NTSC bit. Added Special cart byte.
		 Changed 53 bit 2, added bit 3

[PacManPlus]

I am sooooooooooooooooooooo looking forward to this. Hoping it becomes a 7800-on-a-chip kind of thing.

[+Mitch]

I think I had fixed all of the A78 headers for the ROMs on my website. I guess you may have downloaded some old ones.

 

Mitch

[kevtris]

Yep...http://atariage.com/...2/#entry2660238

 

That's why tower Toppler looks horrible under ProSystem or any other Atari 7800 emulator, but shines under MESS Throw on HLSL and YIQ emulation under MESS, and Tower Toppler along with any other game/system that uses NTSC artifacting, will appear as it should on a CRT.

 

Regarding the ROM set(s), you may have some bad ones as Commando (A good dump of it) does have the POKEY bit set and runs beautifully under MESS (Which requires both a good header and the bit to be set to run properly).

 

The 'bad roms' also holds true if you do not see a bits set in the header for Absolute or Activision titles. It is present in the header:

 

 

I actually searched pretty good for the Tower Toppler and Jinks problems, but I didn't use the right search terms- I was looking for "buggy' and "emulation" and stuff because the lightbulb hadn't gone off yet that it might be deliberate. hehe. And yeah I will try to get a hold of a new set of ROMs that have proper headers to make sure compatibility is 100%.

 

I am sooooooooooooooooooooo looking forward to this. Hoping it becomes a 7800-on-a-chip kind of thing.

 

I am still hoping to sell my device in the future via Kickstarter. I just am not sure if there will be enough interest yet. I'd like to get it out there in the world. I can run 14 classic systems so far.

 

 

I think I had fixed all of the A78 headers for the ROMs on my website. I guess you may have downloaded some old ones.

 

Mitch

 

I will give it a look, thanks for the tip.

 

 

As for updates, I am down to 2 or 3 titles now with problems. All the traditionally difficult games (from what I googled) seem OK- Ballblazer (yes I have pokey emulation!), Centipede top line, Kung Fu Master.

 

I have a difficult problem now- Realsports Baseball and Xenophobe appear to be "illegal" when it comes to DMA. Both are trying to DMA way too much data, and there's no way this can possibly work, yet they both run on the real system. (I have not tested the two ROMs I have on a real 7800 so I am unsure if they work there or might be bad somehow).

 

RS Baseball uses waaaay too many DMA cycles on the title screen for the logo, since it draws the field (very inefficiently) and then the title. There's a total of TEN 4 byte fetches with a short header (8 cycles each header, 12 cycles for the data, which is 20 cycles. There's 10 of these which is 200 cycles so far. These make up the field. Then there's 4 20 byte cycles for the title on top of the field. This is 8 cycles for the header and 60 cycles for the data which is 68 cycles per, and there's four of them for a total of 68*4 = 272 cycles... This is a grand total of 472 cycles, and I haven't even calculated the 6 on the end for the DLL fetch!

 

So here's the total DMA count at scanline 51h:

 

10x 4 byte fetches (8 cycles header + 12 cycles data = 20 cycles per) 200 cycles

4x 20 byte fetches (8 cycles header + 60 cycles data = 68 cycles per) 272 cycles

 

That's waaaaaay more cycles than this can possibly support, yet it seems to work on real hardware? Either the DMA unit is much faster than all the documentation, or something screwy is going on. For fun I ran it on MESS and then dumped RAM from MESS while the game sits on the title screen, and my FPGA while it sits on the title screen.

 

The result is both match for the most part- the DLL and display lists all match, so that rules out a CPU or emulation bug. I know MESS *does not* (unless it was changed recently) take into account cycles used by the DMA. Unsurprisingly, MESS displays the title screen properly, even though there's still way too many DMA cycles.

 

Only the very left and right of the field is visible here, so it's surprising they are DMAing at least 8 useless blocks of data.

 

As for Xenophobe, I am having similar issues. When there's two of the jumping green xenos on the screen with me and one knocks me down, the left/right walls disappear for about 8-16 scanlines. The elevator screen on the second level does it too without anything else being present, other than the elevator. In that case parts of the elevator door disappear.

 

I investigated both cases and both times there were waaaay too many DMA cycles on the scanlines in question- the DMA spilled over and was terminated by the edge of the border like it should be.

 

The only thing I can think of is that the 7800 DMAs faster than all the docs we have indicate (including the schematic) or the two games are a bad dump, or have some kind of weird issue causing this problem. I assume the dumps on AA here (I downloaded new ones juust in case mine were bad) have been tested on a Cuttle Cart 2 and such so they are good dumps.

[Trebor]

For the longest time MESS had issues displaying Xenophobe properly (Screen was always "shaky"). It now displays perfectly. The following relatively new changes were implemented:

 

-Changed default difficulty switch setting to 'A' so Tower Toppler loads the first level.

-Added 7 cpu cycle delay between hsync and Maria DMA (based on atari docs).

-Rewrite of video code to emulate Maria line ram buffers.

-Rendering from line ram no longer uses maria write mode bit (should only use read mode bits).

 

"Huygens" made the above changes.

 

It also fixed a long standing line running across the box on the Centipede top display (which you mentioned as already handling).

 

Additionally though, the changes fixed Kung-Fu Master (Which had horrible graphics corruption) among the following other improvements:

 

-Pole Position II = Horizon/road fixed.

-Alien Brigade = Title Screen Text corruption fixed.

-One-On-One Basketball = Floor/Wall line corruption fixed.

-Midnight Mutants = Top Box/Graphic Corruptions fixed.

 

Those changes came in under MESS 0.148u5. Not sure what version you are using, but the latest is currently 0.149u1. Or if you really want bleeding edge: SVN r24769.

 

Maybe looking at the MAME/MESS source will assist you (particularly what I italicized and bold above)? In the case of Xenophobe perhaps looking at the 0.148 source and compare the changes to 0.149 will help.

 

Check \%root%\src\mess\machine\a7800.c

 

0.148 Source: http://www.mamedev.o...s/mame0148s.exe

0.149 Source: http://www.mamedev.o...s/mame0149s.exe

[kevtris]

For the longest time MESS had issues displaying Xenophobe properly (Screen was always "shaky"). It now displays perfectly. The following relatively new changes were implemented:

 

-Changed default difficulty switch setting to 'A' so Tower Toppler loads the first level.

-Added 7 cpu cycle delay between hsync and Maria DMA (based on atari docs).

-Rewrite of video code to emulate Maria line ram buffers.

-Rendering from line ram no longer uses maria write mode bit (should only use read mode bits).

 

 

 

Thanks for the source links. I did look at the source actually to see how a few things were handled. Does MESS properly emulate LENGTH of DMA bursts now? i.e. if your DMA continues too long it will be forcibly terminated. This is the problem I am having with Xenophobe and RS Baseball. Both of them have a DMA burst that's too long, so graphics are simply disappearing because they cannot be DMA'd fast enough.

 

As far as I can tell, every other game works properly. I too did have the flickering graphics issue with Xenophobe but fixed that one. Timing accuracy is extremely important on it. Here's the DMA list that RS Baseball uses on the title screen. It's easy to see that it's waaay too long. (this was dumped directly from MESS in its debugger). I would expect many many games to have issues if my DMA was not as fast as the original system. If DMA can effectively be infinite like on most 7800 emulations, these two bugs I have encountered will not be visible.

 

(starts at 1A6C)

1A60: 00 00 00 00 00 00 00 00 00 00 00 00 90 FC 88 00 ................
1A70: 98 FC 88 10 68 FC 88 20 B8 FC 88 30 70 FC 88 40 ....h.. ...0p..@
1A80: 74 FC 88 50 BC FC 88 60 6C FC 88 70 9C FC 88 80 t..P...`l..p....
1A90: 94 FC 88 90 28 2C 99 00 50 2C A9 00 3C 2C 99 50 ....(,..P,..<,.P
1AA0: 64 2C A9 50 00 00 00 00 00 00 00 00 00 00 00 00 d,.P............

I have converted this to human readable format:

Entry Address Palette	  Width Hpos wm in Cycles Total
1 8890h 7		 4	 0 0 0 20	 20
2 8898h 7		 4	 16 0 0 20	 40
3 8868h 7		 4	 32 0 0 20	 60
4 88B8h 7		 4	 48 0 0 20	 80
5 8870h 7		 4	 64 0 0 20	 100
6 8874h 7		 4	 80 0 0 20	 120
7 88BCh 7		 4	 96 0 0 20	 140
8 886Ch 7		 4	 112 0 0 20	 160
9 889Ch 7		 4	 128 0 0 20	 180
10 8894h 7		 4	 144 0 0 20	 200
11 9928h 1	 20	 0 0 0 68	 268
12 A950h 1	 20	 0 0 0 68	 336
13 993Ch 1	 20	 80 0 0 68	 404
14 A964h 1	 20	 80 0 0 68	 472
15 0 h 0		 0	 0 0 0	 0	 472

 

472 cycles (not counting DMA startup, shutdown, and DLL entry reading) is way too many. With startup, shutdown, and DLL reading we add another 30ish cycles at least, pushing us well past the number of cycles even available in any given scanline. The first 10 DL entries draw the field in the background in a very inefficient manner, then the last 4 entries draw the logo proper on top. So they end up writing to all 160 pixels THREE times. once in the first 10 DMA's then two more times on the last 4. Those first 10 entries could've easily used the indirect mode with cwidth set to increase efficiency enough so that it'd work.

 

There's three possible reasons for this occurring I can think of:

• The docs are wrong. Data fetches really take only 2 cycles, instead of three as described in all docs and the schematic.
  
• MESS and my FPGA both are wrong. The code is malfunctioning on the game and making extra long DMA lists. (I doubt this)
  
• The ROM is a bad dump. Again, I seriously doubt this, because people would've discovered it with the CC2.
  

If it comes to blows, I can whip out my logic analyzer and probe things while this game runs. I will have to make a cart of it but this isn't a problem. I have EPROMs and cart boards I can use to do this. I'll have to solder headers onto several of the chips to plug the probes in.

 

edit: For some reason, the code editor chewed up my table heading and I can't fix it. adding a space or two adds lots of them instead.

Edited August 6, 2013 by kevtris

[Loktar]

Kevin, I bet you would get a lot of interest in a device like that on kickstarter. Ill back the hell out of it. Retro/emulation/etc. is in right now, esp if you are emulating any nintendo systems.

[kevtris]

Kevin, I bet you would get a lot of interest in a device like that on kickstarter. Ill back the hell out of it. Retro/emulation/etc. is in right now, esp if you are emulating any nintendo systems.

 

Yeah I do :-) I wonder if it'd be a good idea to solicit ideas about what I was hoping to include on the hardware proper. The following systems are fully supported, 100%, fully debugged as far as I can tell (runs all the games without glitches)

• Sega Master System
  
• Game Gear
  
• Colecovision
  
• NES (all sound chips, 205 mappers, Vs. system, plays NSFs)
  
• Atari 2600 (full support for almost everything like Supercharger demo unit, etc)
  
• Intellivision (with Intellivoice and ECS support)
  
• Odyssey^2 (with "The Voice" support)
  
• Adventure Vision
  
• Supervision
  
• Studio 2
  
• Fairchild Channel F
  
• Videobrain
  
• Arcadia 2001
  

 

I also have a few "non game system" fun things on it too:

• SNES SPC700 music (.SPC) with visualizations
  
• Realtime Mandelbrot renderer
  

These systems are still in development:

• Atari 7800 (almost done, as can be seen in this thread :-)
  
• Gameboy (almost done, some video timing issues I want to nail down)
  

[+5-11under]

Sounds like a great living room or portable solution!

[Trebor]

Having the Atari 7800, NES, and Sega Master System is awesome in itself.

 

Add having a Atari 2600, ColecoVision, and Intellivision...

 

Wow...It's almost my complete video game childhood chronology.

 

To round out the Atari family and curious if there's been any thought towards the 5200, or is it not a target/desire for you?

 

You have somewhat of a start supporting the POKEY portion of the 7800

[kevtris]

Having the Atari 7800, NES, and Sega Master System is awesome in itself.

 

Add having a Atari 2600, ColecoVision, and Intellivision...

 

Wow...It's almost my complete video game childhood chronology.

 

To round out the Atari family and curious if there's been any thought towards the 5200, or is it not a target/desire for you?

 

You have somewhat of a start supporting the POKEY portion of the 7800

 

Yeah I'm trying to think of my next target. It's going to be 5200, Lynx, or Vectrex I think. The bonus with the first two is I already have a CPU done, the vec will need me to make a 6809 core first. Once I have the 6809 I will go ahead and port some arcade machines that used it like robotron and such.

[+Gemintronic]

Think hard. I'd love to play IBM PC Alleycat on an FPGA Arcade!