kevtris

I posted the final Atari 2600 stuff tonight, including all of the rarer stuff like Okie Dokie, Edtris, SoundX, Gameline modem in box, Berenstain Bears, etc. http://rover.ebay.com/rover/1/711-53200-19255-0/1?ff3=4&pub=5574883395&toolid=10001&campid=5336500554&customid=&mpre=http%3A%2F%2Fwww.ebay.com%2Fsch%2Fnintendomatic%2Fm.html%3Fitem%3D200958292895%26pt%3DVideo_Games_Games%26hash%3Ditem2eca0c339f%26rt%3Dnc%26_trksid%3Dp2047675.l2562

When I was testing all of my Atari 2600 games for that auction, I found several that were bad. All of the carts USED to work, but after a decade or so I found several that don't work any more. First up is Shootin' Gallery. This has a mask ROM and bits 1/2 are both stuck "high" for every location. I dumped it and that's what was wrong. Next was Strategy-X. This game had a bad mask ROM too. 4 or 8 of the locations near the end of the ROM are bad. The symptom was the game would sorta work but was all screwy. Finally is Time Pilot and Smurfs Save the Day. Both do not work on the 7800. I resurrected my ancient Atari 2600 cart dumper I made some time in 1995 or 96 and fired it up and tried to dump both of those games, and both came back as 4K instead of 8K. These two games use the same PCB inside, and have an EPROM along with 4 TTL chips to do F8 style bankswitching. There was quite a bit of corrosion on the PCBs, so I decided to desolder the 4 TTL chips, clean the board and solder new chips on I had laying around for fun. I also traced the circuit out to see how they did it. Not too surprising but interesting they made a set/reset FF out of two cross coupled NOR gates instead of using a flipflop. After all this, I checked with the meter to make sure there were no open routes, and fired both of them back up on the 7800.. still nothing! Dumping the boards again produced the same result- 4K of ROM data only, and the carts seemed to be triggering on 1FF6/1FF7 instead of 1FF8/1FF9! I finally broke out the 2600 and tried both on there and they work fine! I read up about which games were incompatible with the 7800 and sure enough, one of those games is Time Pilot. My Smurfs Save the Day doesn't work on the 7800 either, and both use the same board so I'm guessing maybe the problem is with the circuit design itself instead of the game data. Does anyone else have Smurfs Save the Day and a 7800 and can test to see if it (and maybe Time Pilot) work? Thought I'd post what I found in case someone else found it useful or informative.

Yeah I know but I don't want to deal with selling individually. If I only get 60-75% of full value that's fine. Someone else can have the fun of lotting it up or selling individually :-)

Well I gotta sell off my collection. I am thinking of moving and have to reduce bulk, and get some funds to do said move! So all the 2600 stuff has to go. As it says on the tin, there's 456 games and a ton of extras included in this auction. Included is an absolutely mint Chase the Chuckwagon with instructions. The label's not even scratched or damaged. Instructions are in great shape too. http://rover.ebay.com/rover/1/711-53200-19255-0/1?ff3=4&pub=5574883395&toolid=10001&campid=5336500554&customid=&mpre=http%3A%2F%2Fwww.ebay.com%2Fitm%2FMASSIVE-456-Game-Atari-2600-Lot-Chase-the-Chuckwagon-Espial-Miner-2049er-II-ETC-%2F200957576977%3F

Yeah I only have a paper copy. I will be getting it scanned and it will be posted eventually. It's 43 pages long and has 2 duplicate pages where some Atari engineers scribbled notes on it, making it 45 total. It's extremely buggy and the DMA hole logic is totally missing. I think it was very early in the design process when Atari reorg'd. This schematic is a "combo" TIA/Maria one so it would've been for another revision of the 7800 to reduce costs. Sure. I am using an HP/agilent 16700B logic analyzer I got off ebay for $200 (it came with three acquisition cards). I had to buy some probes for it too (naturally, also off ebay). To connect it to the 7800, all I did was solder some .1" headers onto the pins of the CPU. 20 per side. I set the header pins on top of the chip legs where they exit the package, and soldered it to them. This was done for the 40 pins of the CPU which contained almost every signal I needed. I soldered a few pins to the Maria to get at its clock input line. The Maria clock is driving the logic analyzer's capturing, so it captures 1 sample each 14.318MHz clock cycle. This let me do easy cycle counting by just setting markers and reading off cycles directly. The probe pins just plug into the headers directly so there's no fuss or soldering other than putting the pins on the chip originally. Now that I'm done, I will probably just leave the pins on the CPU since they aren't hurting anything. The case will still close just fine and if I ever have to probe it again, it's ready to go. I set a trigger up on the display list address so it would start capturing data when the DL line in question on Realsports Baseball was accessed. The picture I took shows the signals I was monitoring- the address bus, data bus, HALT, R/W, and phi0 into the CPU. This analyzer as it sits with the 3 acquisition cards can monitor about 200 signals and has a depth of 2 million samples. So far I have used it to totally reverse engineer timing of the Videobrain, Arcadia 2001, and now I used it to poke the 7800. It's strong medicine but it gives clear results in seconds to minutes instead of hours or days or more using any other means. The next job for this logic analyzer will be unraveling the mysteries of the Gameboy's video rendering to the LCD. It's extremely complex and convoluted.

I forgot to mention I ran it for over 24 hours on my doodad and it didn't crash. I played it for about a half hour last night and it seemed OK. Cool game btw. I will probably be playing it more! I couldn't actually play it until last night since it didn't support one button controllers. I fixed that last night so then I could play it properly other than running around and falling off that first ladder as before. I got stuck between the two dragons on the ground 'cause I couldn't jump so I left it there all night and it was still running the next day. I still think it's some kind of weird NMI problem. WHEN does it crash? Is it between screens or just sitting there on a screen without moving can trigger it? If it's between screens I'd think it might be NMI. If it's while the game just sits there, I don't know. Make sure you're not letting them point somewhere invalid, like 0000h if you're clearing the RAM out and writing a new one in. I doubt it, but I thought I'd throw it out there. The emulators tend to have well defined behaviour if you try to read from unimplemented ("open bus") areas of memory, vs. a real system. I have not seen anything about this game. I will find it on the forum and play it.

Yes this was it. Thanks for the tip on that. I checked and the schematic has nothing at all about the DMA memory holes, actually. I read everything I could and the documentation all said that when a DMA memory hole is hit, it will simply write 00h to all the bytes instead of whatever is being read from memory, so that's what I did. Obviously the caveat is that you have to terminate the DMA's early too! The logic analyzer showed this. As for the memory ranges affected, I wrote out the addresses it was fetching and did notice that when it was fetching Axxxh on the RS Baseball screen it would only DMA 1 byte instead of all 20. I didn't make the connection between that and the DMA hole bit being set. Oh well, that saved me hours of debug time. Yeah that's nice- I needed one of those :-) I ended up writing a simple one in QB64 to decode the DL's during debugging. So I guess in the end there is no silicon bug and I feel kinda silly for thinking there was, now. In any event, the FPGA 7800 is about done now. I added 2 button support and tested a bunch of games without finding any more new bugs. I will do a regression test tomorrow and run every game again to see if anything else broke but I ran 20 or so and they were all fine. Played up to level 5 on Xenophobe and not a graphic disappeared. RS BB's title screen is perfect, too. Still find it interesting that only 2 titles were affected out of all of them, though! In a few days if I get around to it I will make a video of it running various games.

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.

I had similar type things happen during development of the FPGA 7800. The main cause was too many NMI's. Some games (Klax) did things like turn the DMA on before it set up the display lists- it would grab random crap out of open bus / RAM / god knows where and if bit 7 is set it would do a DLI. The timing was very close on this and being off a few cycles was enough that it couldn't recover. Make sure you are not accidentally setting DMA mode to 0 or 1. The game Beef Drop (I am not sure if all versions do it, or the version I had which was a dev one) does it. It sets DMA mode 0 sometime when it changes from the title screen to the game screen. This puts the DMA state machine into a tizzy and it will fetch one DL header from god knows where. If bit 7 is set, it will NMI and trash the game, causing the in game to be all corrupt. I fixed it by disallowing NMIs if the DMA mode is not 3. The other possible explanation is your code's expecting to execute more instructions than it can on a real system. The emulators aren't very good at deducting cycles used by the DMA's yet (or if they do, they top out at some default value). The emulators have no problem fetching more graphics than can be rendered, too. The issues raised in this thread is proof of that. But if I had to guess, NMI is most likely what is causing your crashes. If you have the cycles, you could put a re-enterant protector in your NMI loop. Check an "already in NMI" flag and RTI if it's set. If not, set it, do your NMI then clear it and RTI. This will prevent multiple NMI's stepping on each other. I am not sure why Atari didn't use IRQ for this, instead... seeing how it goes unused. It's maskable and will not perform more IRQs until the current one is finished. My only guess is they didn't want the overhead of clearing the IRQ flag on the chip when the IRQ was serviced.

I had kind of gotten off track on my other post, so I thought I'd make the post in here, since it's a programming issue. The basics of what I have found tonight is simply that there's some kind of nasty bug in the Maria's DMA fetcher. The game Realsports Baseball's title screen exhibits this problem (as does Xenophobe, but not on its title screen). I have done a bunch of research using three sources: MESS, my FPGA 7800, and a real live Atari 7800 connected up to a logic analyzer. Here's the sequence of images that go with the post, first: First, I soldered some headers onto the 6502 in the 7800. Next, I connected up the logic analyzer: Then I had to make an EPROM cartridge: Here's the logic analyzer showing the defective DMA fetch: And Finally, what it looks like if your DMA unit is *NOT* buggy: The good news: I have confirmed that the Maria chip's basic DMA fetching cycle times are accurate. The bad news: The Maria chip will fetch only 1 byte instead of the number specified in the DL header! I cannot seem to find much of a pattern to why it is doing this. At first I thought that it was shortening the same DL entries on one zone each scanline, but it is not. It's more complicated than this. In RS Baseball, the zones are all 8 scanlines tall typically (at least on the title screen). The way RS Baseball makes up its title screen is it draws the field and then overlays the title graphic on top of it. On the first affected zone (middle of the logo where the right half is missing), it starts attempting to perform 14 DMA's. The first 10 DMA's are fetching 4 bytes each, and make up the baseball field, then the last 4 DMA's fetch the title screen. We're only interested in these last 4 fetches, since 2 of them will be shortened from 20 bytes, to 1 byte! These 4 DMA's are as follows (address on the left is where in RAM the DL entries are sitting. The DL starts at 1A6Ch) 1A94: 28 2C 99 00 - DMA 20 bytes from 9928h 1A98: 50 2C A9 00 - DMA 20 bytes from A950h 1A9C: 3C 2C 99 50 - DMA 20 bytes from 993Ch 1AA0: 64 2C A9 50 - DMA 20 bytes from A964h Here's the weird part: On the *first* scanline of the zone, the following occurs: 1A94: 28 2C 99 00 - DMA 20 bytes from 9928h <-- instead of 20 bytes, it only fetches 1. 1A98: 50 2C A9 00 - DMA 20 bytes from A950h 1A9C: 3C 2C 99 50 - DMA 20 bytes from 993Ch <-- instead of 20 bytes, it only fetches 1. 1AA0: 64 2C A9 50 - DMA 20 bytes from A964h On the other 7 scanlines of the same zone, the following occurs: 1A94: 28 2C 99 00 - DMA 20 bytes from 9928h 1A98: 50 2C A9 00 - DMA 20 bytes from A950h <-- instead of 20 bytes, it only fetches 1. 1A9C: 3C 2C 99 50 - DMA 20 bytes from 993Ch 1AA0: 64 2C A9 50 - DMA 20 bytes from A964h <-- instead of 20 bytes, it only fetches 1. To cork it all off, the programmer of RS Baseball had to have a clue what was going on, because he only put the title screen graphics in the correct places! The top scanline of the graphic is at 9928-994Fh, while the other 7 scanlines of the graphic are at A950-A977 On my logic analyzer picture, above, you can see it read the display list entry out of 1A9C-1A9F, then instead of 20 bytes of DMA it only fetches one, before reading the next display list entry at 1AA0-1AA3. This was taken on the last scanline of the zone, so that the addresses fetched do not have an offset. I think this is pretty iron-clad proof that there is something very "funny" going on in the Maria chip! One interesting use for this would be for emulator protection- you could use purposely buggy DMA's that would work on a real system, but overwrite and corrupt the graphics on screen if the emulator executed the DMAs "properly" without emulating the DMA bug. I am not sure how deep this particular rabbit hole goes, and I cannot seem to find any reasoning for these broken DMA fetches. There is obviously SOME set of triggering conditions, but I am not sure what that would be. Only two games exhibit this problem. At this point I am wondering if it has something to do with the horizontal pixel position when the width is being read. Anyone writing software hit upon this problem where "random" display list entries do not work?

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.

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.

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.

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.

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.

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)

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.. [email protected] 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.

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 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 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.

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.

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.

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.

Thanks to both of you for the information! I was going to look at the MESS source but had not gotten that far yet. I will implement all the mappers tonight, they don't look too tough. So far my CPU's making it through all the tests in the BIOS (there sure are a lot of tests... almost 1K worth). It then jumps into RAM to do the ROM hashing, and I have not confirmed it gets past that (it very well could be, but my video isn't functional yet :-)

As the title says. I spent about an hour looking around on the innertubes for an .A78 header document and didn't find much. Google only returned 7 hits which weren't terribly useful, and I even downloaded the source to Dan Boris' emulator (he apparently came up with .A78) but it has no documents about the header format in there either. I can reverse engineer the ROM loader in the emulator I guess as a last-ditch effort but was hoping a document exists about it. Thanks for any help in advance!

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.

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).