Has Anyone Worked on an FPGA Atari 7800?

[Trebor]

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.

 

Well if you throw the Vectrex in you would have completed my childhood console gaming.

I didn't even bother mentioning it due to the vector graphics. I didn't think it would 'carry over' well - especially when you factor vector graphics with the overlays.

 

Yeah, screw the 5200 and go with Vectrex... j/k.

[kevtris]

Well if you throw the Vectrex in you would have completed my childhood console gaming.

I didn't even bother mentioning it due to the vector graphics. I didn't think it would 'carry over' well - especially when you factor vector graphics with the overlays.

 

Yeah, screw the 5200 and go with Vectrex... j/k.

 

I am kinda close to that, because I think writing a vector to raster renderer would be really fun. Because this is an FPGA, there's no such thing as "too much processing" and "slowdown" and other such trivia. The solution to the problem is probably high enough resolution so the vectors don't look very jaggy. I can implement the overlays easy enough which is what the PC emulators do. I was going to get it going using the RGB outputs to drive an XYZ monitor at first, then once that works, move onto the vector to raster converter. I think it's possible to have a decentish vectrex on the FPGA myself. (I have a real one too so doing side by side isn't too hard).

 

That's still all up in the air, though. I need to fix/solve this 7800 problem first! I was thinking of hooking my 7800 up to the logic analyzer, though I do not have RS baseball on cart, I don't think. I can make one however if needed.

[kevtris]

Here's the pictures of the 7800 issue I was having with RS Baseball. There's two parts of the logo affected- the middle on the right and the bottom, at the L's.

 

[Trebor]

Hmmm...

 

Before...

 

...and after...

 

...the emulation changes mentioned earlier.

 

They obviously had no impact on RealSports Baseball, as it always displayed fine under MESS.

 

Nonetheless, besides "\%root%\src\mess\drivers\a7800.c" & "\%root%\src\mess\machine\a7800.c", the complete MESS 7800 emulation also requires:

 

#include "emu.h"

#include "cpu/m6502/m6502.h"

#include "sound/pokey.h"

#include "sound/tiaintf.h"

#include "imagedev/cartslot.h"

#include "machine/6532riot.h"

#include "includes/a7800.h"

 

Do you think perhaps looking at some of the other source files may help? Perhaps the issue is with the 6532riot or m6502(?)

 

Looking over the 6532riot.c file there seems to be some important notes and fine points of how it functions. Ditto with the m6502.c file.

 

I've includes all the above mentioned source files and more for emulation of the 7800 under MESS in the attached: MESSA7800SRC.zip

 

Honestly, I am way out of my league here. Hoping the above and the attached helps you though.

 

And let's make sure we're playing with the same game (dump): RealSports Baseball (1988) (Atari).zip

 

Just as a side note, the above will not run under the ProSystem emulator. The ProSystem emulator has a bug reading 64Kb images and requires overdumped images of 64Kb ones to functioning properly. For the curious, here's the overdumped ROM image (with header) as well: RealSports Baseball (1988) (Atari) o1.zip

[kenfused]

How does my work-in-progress Tetris clone look on it?. It probably comes pretty close to maxing out all of the DMA on some of the zones. https://atariage.com/forums/topic/205803-wip/page__hl__wip__st__50

I more or less tweaked it by trial and error until it looked ok on the real thing and no graphics were disappearing. I don't remember how my calculation of cycles compared to the maximums though.

 

--Ken

[kevtris]

How does my work-in-progress Tetris clone look on it?. It probably comes pretty close to maxing out all of the DMA on some of the zones. https://atariage.com...hl__wip__st__50

I more or less tweaked it by trial and error until it looked ok on the real thing and no graphics were disappearing. I don't remember how my calculation of cycles compared to the maximums though.

 

--Ken

 

Thanks for the link. I will test it soon when I get the CRT back on the desk. I had to remove it so I could put the logic analyzer up on the desk.

[PacManPlus]

Very cool - especially if the 5200 is added.

 

I'm already in for one of these, if the 5200 and/or Vectrex is added that just makes it even more definite!

 

Probably a stupid question, but is it possible to have solder points to put a cart connector on one of these a'la Flashback 2?

[+Gemintronic]

Very cool - especially if the 5200 is added.

 

I'm already in for one of these, if the 5200 and/or Vectrex is added that just makes it even more definite!

 

Probably a stupid question, but is it possible to have solder points to put a cart connector on one of these a'la Flashback 2?

 

Sounds like 5200 is more likely than 8086. I wouldn't mind either way. I honestly don't want to lug out my 5200 for testing my games. Although, if a XT firmware comes out I could make DOS QuickBASIC games that play like they were on a console ^_^

[+Mitch]

If you are doing the 5200 it might not be too difficult to add the XEGS as it's almost the same machine with a larger software library.

 

Mitch

[kevtris]

Update on the 7800 problem: The logic analyzer comes through once again. I know HOW it is screwing up, but not WHY. The Maria chip appears to have a bug or two in it!

 

A bit of background: I modified a 7800 cart by adding a socket for an EPROM and did a bit of rewiring so I can use 32 pin chips. Then I hooked my logic analyzer up to the 7800's address, data, and control busses and finally ran the game and had it capture data when the address bus was 1A6Ch, the start of the display list. I checked to make sure the real 7800 and the FPGA 7800 and MESS all had the same display list- they do.

 

Next, timing is checked. The timing matches my FPGA and the documentation, so that's a relief. Finally, I checked out WHAT the Maria chip was fetching, and from where and compared that to what it should be fetching.

 

On two of the 20 byte fetches, it only reads one byte! The four display list entries of merit are:

 

1A94: 28 2C 99 00 (20 bytes, from 9928h)

1A98: 50 2C A9 00 (20 bytes, from A950h)

1A9C: 3C 2C 99 50 (20 bytes, from 993Ch)

1AA0: 64 2C A9 50 (20 bytes, from A964h)

 

Instead, here's what my real 7800 is doing:

 

1A94: 28 2C 99 00 (20 bytes, from 9928h)

1A98: 50 2C A9 00 (20 bytes, from A950h) -- fetching ONE byte

1A9C: 3C 2C 99 50 (20 bytes, from 993Ch)

1AA0: 64 2C A9 50 (20 bytes, from A964h) -- fetching ONE byte

 

That answers the question of how the 7800 can run this game without showing graphical corruption, but not the question of why this happens!

 

Looks for sure like a hardware bug. I have not seen any errata on the Maria chip either that could explain it.

 

Has anyone making a homebrew run into any mysterious disappearing graphics bugs before? That'd be the symptoms of this bug.

[iesposta]

Very interested in this project.

Any chance for a Bally Astrocade?

I just can't bring myself to spend the money for failure prone Bally hardware, even though new boxed games are cheap.

I had one of its joysticks back in the day, don't know why, guess I got it mail order or something. The pistol grip/ fire button with top joystick/knob was fascinating.

[+5-11under]

Good to see Videobrain on the list. I had one up until a few years ago, and I miss playing the Othello game.

[Trebor]

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.

 

Thinking about this...Desert Falcon is on the list that needs 'NTSC artifacting' as well. The stones/spots you see on the ground shimmers/glistens on a CRT or under CRT emulation (I.E. YIQ Emulation turned on with HLSL under MESS).

 

Without it they just look like random spots/specks on the ground.

[tep392]

Instead, here's what my real 7800 is doing:

 

1A94: 28 2C 99 00 (20 bytes, from 9928h)

1A98: 50 2C A9 00 (20 bytes, from A950h) -- fetching ONE byte

1A9C: 3C 2C 99 50 (20 bytes, from 993Ch)

1AA0: 64 2C A9 50 (20 bytes, from A964h) -- fetching ONE byte

 

 

At which scanline? H16 is set for this 8 line tall zone (offset=7). Maria shouldn't DMA out of the odd 4k blocks at $9000 and $b000 when H16 is set. The first DL in this list will only grab data for the top line from $a028. The second DL will grab the next 7 lines from $a950-$af50. Same for the 3rd and 4th DL's. My guess is that the one byte fetch was for the top line of the zone. Maybe Maria grabs one byte before it know's it's in an odd 4k block.

 

Are you positive you are handling holy DMA correctly?

 

edit:

One more observation. The corupted "LL" at the lower right of the Baseball graphic is generated by a DL that shouldn't use excessive Maria cycles. This display list starts at $1beo and the DL headers of interest are at $1bf8 and $1bfc.

[kevtris]

At which scanline? H16 is set for this 8 line tall zone (offset=7). Maria shouldn't DMA out of the odd 4k blocks at $9000 and $b000 when H16 is set. The first DL in this list will only grab data for the top line from $a028. The second DL will grab the next 7 lines from $a950-$af50. Same for the 3rd and 4th DL's. My guess is that the one byte fetch was for the top line of the zone. Maybe Maria grabs one byte before it know's it's in an odd 4k block.

 

Are you positive you are handling holy DMA correctly?

 

edit:

One more observation. The corupted "LL" at the lower right of the Baseball graphic is generated by a DL that shouldn't use excessive Maria cycles. This display list starts at $1beo and the DL headers of interest are at $1bf8 and $1bfc.

 

This would explain it I guess... though from the documentation I read, it still fetches data with holy DMA mode enabled... it just throws the data away. But if it just totally aborts the DMA, that'd make sense too. The only time it would matter is if the kangaroo mode bit is set, where it'd be writing background colour pixels in there instead of transparent ones.

 

Thanks for the heads-up on that and I will change my thinger to kill the DMA length of anything with holy DMA mode enabled. Incidentally, this is not in the schematic, either I don't think. I would've saw it. Unless the holy DMA part is on a page unrelated to the DMA which I guess IS possible. I will look at them again tonight and see what the deal is.

 

Interesting that only two games were affected by this! You'd think more stuff would be. I will modify the FPGA code to kill any DMA in progress after 1 fetch if it is in one of the DMA holes.

[tep392]

I'm only hypothesizing here, but the behaviour you observed seems consistent with holy DMA being enabled. Also, it would seem logical to not waste time reading memory that will only be thrown away. I would think that it is documented though, unless the documents we have are not final production. I'd be looking for logic tied to A15 and A12 (H16) or A15 and A11 (H8) being set.

[tep392]

I took a quick look at the Maria Spec on Atarimuseum.com and it does mention terminating DMA early when holy DMA is enabled.

[+Mitch]

Also check out toward the bottom of page six of the Maria Specs. http://www.atari7800.org/manuals/Devcard.htm

Setting the "holy DMA" bits A12ENable or A11Enable enables checking for "invalid" graphics addresses: Detection of PP + OFFSET addresses with A12 or A11 = 1 results in aborting the object that requested the address

 

I'm assuming this is what you are referring to anyway.

 

Mitch