156 replies to this topic

[Bruce Tomlin]

I tried a lot of other 128K games and there were two problems. Some of them wouldn't work, and some had a bunch of squares for the sprites (which was the unitialized SRAM pattern). These were obviously games that worked in "LOW" mode, with bank N-1 at $4000-$7FFF. The second group were the ones that needed RAM. They seemed to run fine, but the Maria was not happy and the screen was full of ugliness. So clearly there was a problem with the RAM. I doubt it's a speed problem, because it's a 70ns chip, and it's in a board position that was designed for it.

I decided to tackle the low-mode problem first, especially when I realized that using the extra bank switch output (nominally BA17) could generate the N-1 bank address by jumpering it to BA14 and using its output enable to force a zero in $4000-$7FFF. After most of a day's work, and having to rewire the board twice before even getting the GAL programmed, I got Xenophobe running. (that was one of the games that wouldn't work at all earlier) I got up to the delta-level base before the xenos broke my puffer gun and kicked my ass.

So I'm going to add another jumper point to my schematic, because, after all, someone might want to make a copy-cart of Klax or something. That makes three modes (8-48K with a 7402, 128K w/RAM, 128K low-mode) that fit in the GAL socket so far. Hooking up a Pokey eventually is going to be interesting, and I'm probably going to hang it off of another hot-glued board.

I still need to figure out what's wrong with the RAM, and then I'll see about getting some photos of my frankenboard. (It's not quite the ultracart yet... maybe superdupercart?)

// Atari 7800 supercart 128K ROM + 8/16K RAM or 128K ROM + 16K ROM

chip 20V8R;   // 20V8 registered mode

pin  1 CLK;   pin 24 VCC;
pin  2 CLK2;  pin 23 P_23;
pin  3 RW;    pin 22 LCO;
pin  4 P_4;   pin 21 !RAMCS;
pin  5 A14;   pin 20 !ROMCS;
pin  6 A15;   pin 19 BA14;
pin  7 P_7;   pin 18 BA15;
pin  8 D4;    pin 17 BA16;
pin  9 D0;    pin 16 BA17;
pin 10 D1;    pin 15 !OEO;
pin 11 D2;    pin 14 D3;
pin 12 GND;   pin 13 !OE;

BA14 := D0;
BA15 := D1;
BA16 := D2;
ROMCS =  A15 &         RW;        // 8000-FFFF read
RAMCS = !A15 &  A14 &       CLK2; // 4000-7FFF
  !LCO =  A15 & !A14 & !RW & CLK2; // 8000-BFFF write
   OEO = !A14;                     // output bank select at 8000-BFFF

// 20V8R needs OE term for non-registered pins
ROMCS.OE = 1;
   LCO.OE = 1;
   OEO.OE = 1;
RAMCS.OE = 1;
  BA17.OE = 1;

// Atari 7800 supercart 128K ROM with bank 6 at $4000-$7FFF
// this configuration needs a jumper between pins 16 and 19

chip 20V8R;   // 20V8 registered mode

pin  1 CLK;   pin 24 VCC;
pin  2 CLK2;  pin 23 P_23;
pin  3 RW;    pin 22 LCO;
pin  4 P_4;   pin 21 !RAMCS;
pin  5 A14;   pin 20 !ROMCS;
pin  6 A15;   pin 19 BA14;
pin  7 P_7;   pin 18 BA15;
pin  8 D4;    pin 17 BA16;
pin  9 D0;    pin 16 ZA14;
pin 10 D1;    pin 15 !OEO;
pin 11 D2;    pin 14 D3;
pin 12 GND;   pin 13 !OE;

BA14 := D0;
BA15 := D1;
BA16 := D2;
ROMCS =  A15 &         RW |       // 8000-FFFF read
                 A14 &  RW;        // 4000-7FFF read, C000-FFFF read
RAMCS = 0; // RAM not used in this configuration
  !LCO =  A15 & !A14 & !RW & CLK2; // 8000-BFFF write
   OEO = !A14;                     // output bank select at 8000-BFFF
  ZA14 = 0;                        // drives BA14 low to select bank 6

// 20V8R needs OE term for non-registered pins
ROMCS.OE = 1;
   LCO.OE = 1;
   OEO.OE = 1;
RAMCS.OE = 1;
  ZA14.OE = !A15 & A14 & RW;  // 4000-7FFF read, to drive BA14 low and select bank 6

Edited by Bruce Tomlin, Sun Jul 10, 2005 1:05 PM.

[Bruce Tomlin]

Well, I got all the 128K-low games working. But that RAM thing is a big problem. I took another supercart board that I had put in sockets for RAM and ROM and added the 32-pin mezzanine socket and tried that with Summer Games. Still no luck. I tried an assortment of 32K RAM chips with no luck, then I burned a copy of Impossible Mission and tried that with an 8K RAM. Still no go.

Now I've got to figure out what makes the RAM in those carts work right in the first place. So I'll probably have to take apart a Summer Games or a Winter Games and see what the deal is. There were only five games with RAM, and those two had 16K. The 8K games were Impossible Mission, Tower Toppler, and Jinks. I guess nobody will care if I trash a Jinks cart. :-)

[cschell]

Silly question, but you did remember to combine both the clk line and the r/w line for the ~we line on the RAM right?

Chad

[Bruce Tomlin]

No, because the C100339 cartridge schematic I was working off of didn't do that, so I didn't have anything to "remember". I cracked open a Jinks and found out that it used a C300565, which had a different selection of chips. I suppose I would have found that out soon enough once I traced out the circuit.

Of course that means that I need to use another GAL output, which pretty much kills the option of using 256K ROM + RAM with a 20V8. Not that anybody is at the stage of needing 256K ROM yet. And it really screws a Pokey+RAM combo with a 20V8. Again, rare enough right now that if anybody really wants to do that, they can spring the extra cost for a 22V10.

[Mitch]

Bruce Tomlin, on Tue Jul 5, 2005 9:26 AM, said:

No, because the C100339 cartridge schematic I was working off of didn't do that, so I didn't have anything to "remember".  I cracked open a Jinks and found out that it used a C300565, which had a different selection of chips.  I suppose I would have found that out soon enough once I traced out the circuit.

Have you checked out the schematics that Dan Boris has on his site? He has pretty much all of the major ones.

Mitch

[cschell]

You have to make sure the WE is only active during the portion of the bus cycle during which addresses are stable, otherwise you can accidentally write to the wrong address, violate setup and hold times, etc. This is true for memory systems in general, not just the 7800.

I said "remember" because I've forgotten to add the clock in more than once when throwing together some programmable logic.

Just trying to be helpful.

Chad

[Bruce Tomlin]

Ahhh... that's better. Thanks for the pointer, Chad. I had to trace out the new circuit to find the whole story. It wasn't just adding CLK2 to the WE; the CLK2 had to be removed from the RAM CS equation as well.

Curse you, Atari... not only did you get it wrong, but you put the trace I needed to cut in a place where I couldn't reach it! I had to desolder my U2 socket to get at that trace.

FWIW, I also looked at a schematic that Harry Dodgson made of the C100339 board, which just reinforced the validity of the bad version. That's what I get for assuming that just because the board connected the WE pin, RAM support was working.

This one works...

// Atari 7800 supercart 128K ROM + 8/16K RAM or 128K ROM + 16K ROM

chip 20V8R;   // 20V8 registered mode

pin  1 CLK;   pin 24 VCC;
pin  2 CLK2;  pin 23 P_23;
pin  3 RW;    pin 22 LCO;
pin  4 P_4;   pin 21 !RAMCS;
pin  5 A14;   pin 20 !ROMCS;
pin  6 A15;   pin 19 BA14;
pin  7 P_7;   pin 18 BA15;
pin  8 D4;    pin 17 BA16;
pin  9 D0;    pin 16 !RAMWE;
pin 10 D1;    pin 15 !OEO;
pin 11 D2;    pin 14 D3;
pin 12 GND;   pin 13 !OE;

BA14 := D0;
BA15 := D1;
BA16 := D2;
ROMCS =  A15 &         RW;        // 8000-FFFF read
RAMCS = !A15 &  A14;              // 4000-7FFF
RAMWE =               !RW & CLK2;
  !LCO =  A15 & !A14 & !RW & CLK2; // 8000-BFFF write
   OEO =        !A14;              // output bank select at 8000-BFFF

// 20V8R needs OE term for non-registered pins
ROMCS.OE = 1;
   LCO.OE = 1;
   OEO.OE = 1;
RAMCS.OE = 1;
RAMWE.OE = 1;

Edited by Bruce Tomlin, Sun Jul 10, 2005 1:03 PM.

[Bruce Tomlin]

And now I need to get some more hot glue so I can slap a Pokey socket onto this mess.

Attached Thumbnails

• 
• 

[Bruce Tomlin]

Commando works now.

I wired up a new sub-board for a Pokey chip Friday, but had neither Pokey nor time until today. Before I left, I set aside a Commando cart so that I could desolder the Pokey and later trace out the board. In the past hour I desoldered it, plugged it into the board, and tested the board to make sure it still worked. Then I double-checked the GAL equations, programmed a new GAL, reprogrammed the flash chip, and fired it up. It worked the first time.

Pictures later.

// Atari 7800 supercart 128K ROM with pokey at $4000-$7FFF

chip 20V8R;   // 20V8 registered mode

pin  1 CLK;   pin 24 VCC;
pin  2 CLK2;  pin 23 P_23;
pin  3 RW;    pin 22 LCO;
pin  4 P_4;   pin 21 !RAMCS;
pin  5 A14;   pin 20 !ROMCS;
pin  6 A15;   pin 19 BA14;
pin  7 P_7;   pin 18 BA15;
pin  8 D4;    pin 17 BA16;
pin  9 D0;    pin 16 !POKCS;
pin 10 D1;    pin 15 !OEO;
pin 11 D2;    pin 14 D3;
pin 12 GND;   pin 13 !OE;

   BA14 := D0;
   BA15 := D1;
   BA16 := D2;
   ROMCS =  A15 &         RW;        // 4000-7FFF read, C000-FFFF read
   RAMCS = 0;                        // RAM not used in this configuration
    !LCO =  A15 & !A14 & !RW & CLK2; // 8000-BFFF write
     OEO =        !A14;              // output bank select at 8000-BFFF
   POKCS = !A15 &  A14 &       CLK2; // 4000-7FFF

// 20V8R needs OE term for non-registered outputs
ROMCS.OE = 1;
   LCO.OE = 1;
   OEO.OE = 1;
RAMCS.OE = 1;
POKCS.OE = 1;

Edited by Bruce Tomlin, Sun Jul 10, 2005 1:26 PM.

[Bruce Tomlin]

Ballblazer/Beef Drop:

// Atari 7800 supercart 32K ROM with pokey at $4000-$7FFF

chip 20V8R;   // 20V8 registered mode

pin  1 CLK;   pin 24 VCC;
pin  2 CLK2;  pin 23 P_23;
pin  3 RW;    pin 22 LCO;
pin  4 P_4;   pin 21 !RAMCS;
pin  5 A14;   pin 20 !ROMCS;
pin  6 A15;   pin 19 BA14;
pin  7 P_7;   pin 18 BA15;
pin  8 D4;    pin 17 BA16;
pin  9 D0;    pin 16 !POKCS;
pin 10 D1;    pin 15 !OEO;
pin 11 D2;    pin 14 D3;
pin 12 GND;   pin 13 !OE;

    BA14 = A14;                      // pass through A14
    BA15 = A15;                      // pass through A15
    BA16 = 1;                        // BA16 not used
   ROMCS =  A15 &         RW;        // 4000-7FFF read, C000-FFFF read
   RAMCS = 0;                        // RAM not used in this configuration
     LCO = 0;                        // latches not used in this configuration
     OEO = 0;                        // OEO not used in this configuration
   POKCS = !A15 &  A14 &       CLK2; // 4000-7FFF

// 20V8R needs OE term for non-registered outputs
   LCO.OE = 1;
RAMCS.OE = 1;
ROMCS.OE = 1;
  BA14.OE = 1;
  BA15.OE = 1;
  BA16.OE = 1;
POKCS.OE = 1;
   OEO.OE = 1;

[Shawn Sr.]

THis is great work your doing on the 7800 board. I can't wait unitl I'm able to get all the new 7800 games (pacman, burgertime, frogger) all on real carts!!

[Bruce Tomlin]

Yeah, well now the hard part is getting down and dirty with PCB design.

I've been thinking that just as Pixels Past has regular and bankswitched 2600 cart boards, maybe it would be a good idea to make a simple 48K board that uses a 7402. It would need jumper points that let you connect the A14 and A15 inputs to +5 for the VPP and /PGM inputs of 2764/27128/27256 chips, but the smaller board would probably be cheaper to make and handle most of the near-term homebrews.

I'd leave the option for a 7402 on the Ultracart board, but since the only times that a 7402 is useful would be handled by the smaller board anyhow, it would be deprecated.

[Mitch]

Bruce Tomlin, on Tue Jul 12, 2005 8:05 AM, said:

Yeah, well now the hard part is getting down and dirty with PCB design.

I've been thinking that just as Pixels Past has regular and bankswitched 2600 cart boards, maybe it would be a good idea to make a simple 48K board that uses a 7402.  It would need jumper points that let you connect the A14 and A15 inputs to +5 for the VPP and /PGM inputs of 2764/27128/27256 chips, but the smaller board would probably be cheaper to make and handle most of the near-term homebrews.

I'd leave the option for a 7402 on the Ultracart board, but since the only times that a 7402 is useful would be handled by the smaller board anyhow, it would be deprecated.

Yeah, that's sounds like a good idea. Hopefully someone will write a larger game though so that all of your hard work on the bankswitched board doesn't go to waste.

Mitch

[Shawn Sr.]

Bruce Tomlin, on Tue Jul 12, 2005 10:05 AM, said:

Yeah, well now the hard part is getting down and dirty with PCB design.

I've been thinking that just as Pixels Past has regular and bankswitched 2600 cart boards, maybe it would be a good idea to make a simple 48K board that uses a 7402.  It would need jumper points that let you connect the A14 and A15 inputs to +5 for the VPP and /PGM inputs of 2764/27128/27256 chips, but the smaller board would probably be cheaper to make and handle most of the near-term homebrews.

I'd leave the option for a 7402 on the Ultracart board, but since the only times that a 7402 is useful would be handled by the smaller board anyhow, it would be deprecated.

With the non-bankswitchable boards that would cover most of the early 7800 releases also would it not? I know alot of them where not very complicated layouts but I could be wrong. The big boys like Alien Brigade and Crossbow are the ones that are gonna hurt correct?

[Bruce Tomlin]

Quote

With the non-bankswitchable boards that would cover most of the early 7800 releases also would it not? I know alot of them where not very complicated layouts but I could be wrong. The big boys like Alien Brigade and Crossbow are the ones that are gonna hurt correct?

Yesterday I would have said yes.

This morning, I realized that the small boards are the ones that need to take either a 7402 or a GAL. Then a single, SMALL board could handle 8-48K flat, 64/128K bank switched, and 64/128K bank switched low-mode. And possibly even as much as 1MByte bank switched. The simplest mode (8-48K with a 7402) would need two jumpers (which would also need to be jumperable to +5 for 27256 or smaller, even without a GAL chip), and there would need to be a jumper for ROM pin 30 to be either +5 or BA18, but I don't think anything else would need a jumper. (there are a couple of other places where a jumper would be nice, but no other jumpers are absolutely necessary)

Then the only games that would need the full Ultracart would be:

* uses RAM
* uses POKEY
* uses 144K (ROM in RAM socket)
* and not even the Ultracart would handle non-standard (Activision/Absolute) bank switching

Of the games released in the day, this is the list of the ones that won't work:

78POKEY.BNK - Ballblazer
78SC_POK.BNK - Commando
78SC_R8K.BNK - Impossible Mission, Jinks
78SCR8SM.BNK - Tower Toppler
78SC_R16.BNK - Summer Games, Winter Games
78SC_BIG.BNK - Alien Brigade, Crossbow
ABS78.BNK - F-18 Hornet
ACT78.BNK - Double Dragon, Rampage

Everything else made back in the '80s will be able to use either a 7402 or a single GAL configuration, on a board with three 3-pin jumpers.

Being able to run low-mode 128K games in the mini-Ultra would mean ONLY TWELVE GAMES of the originals would be unable to run on a mini-Ultra, and two of those (Alien Brigade and Crossbow) could probably be made to work with a 256Kbyte ROM and clever bank switching control with BA18. Two more (Ballblazer and Commando) would work if they didn't need a Pokey. Homebrews so far with Pokey support have made attempts to work either with or without a Pokey.

So that means 80% of the games, including Klax and Sentinel, could be run on a mini-Ultra.

I'm going to put my efforts into the mini-Ultra first.

EDIT: added schematic

Attached Thumbnails

• 

Edited by Bruce Tomlin, Wed Jul 13, 2005 8:15 PM.

[supercat]

I was just pondering how I might set up a game and was wondering whether there are any carts (CC2 perhaps?) that could be adapted a bank-switching scheme like this:

• Addresses $8000-$FFFF would map to 32K of ROM
  
• Addresses $4800-$7FFF would map to 14K of RAM
  
• Addresses $4000-$47FF would map to 16K of RAM through an interesting bank-switch arrangement: bits 6-7 of the address would be used in 4x3 LUT to select bits 11-13 of the address.
  
• Writing to address $3F00 would set the first LUT value; Address $3F40 would set the second; $3F80 the third; $3FC0 the fourth.

If something like this could be arranged, it would allow a game to animate up to four groups of tiled characters separately. If a game has large groups of entities that all move in lockstep, this would allow such entities to be animated with minimal overhead. Anyone know of any existing cart designs that can do anything at all like that?

[EricBall]

Here's an interesting idea - separate CPU and MARIA banks, selected by the HALT line. Or 32K of RAM as two 16K banks selected by HALT XOR a CPU settable flag for implementing seamless double buffering of a bitmapped display.

[Bruce Tomlin]

supercat, on Thu Jul 14, 2005 7:16 PM, said:

I was just pondering how I might set up a game and was wondering whether there are any carts (CC2 perhaps?) that could be adapted a bank-switching scheme like this:
* Addresses $8000-$FFFF would map to 32K of ROM
* Addresses $4800-$7FFF would map to 14K of RAM
* Addresses $4000-$47FF would map to 16K of RAM through an interesting bank-switch arrangement: bits 6-7 of the address would be used in 4x3 LUT to select bits 11-13 of the address.
* Writing to address $3F00 would set the first LUT value; Address $3F40 would set the second; $3F80 the third; $3FC0 the fourth.

And how exactly is it supposed to know what kind of memory access is happening so that it can make such decisions? This isn't an NES where the video chip gets its own bus.

EricBall, on Fri Jul 15, 2005 11:44 AM, said:

Here's an interesting idea - separate CPU and MARIA banks, selected by the HALT line.  Or 32K of RAM as two 16K banks selected by HALT XOR a CPU settable flag for implementing seamless double buffering of a bitmapped display.

That sounds rather clever. Why don't you try it out? :-) Anyhow, if you have enough graphics to use up a whole 16K of RAM, you probably won't have enough CPU time to fill the buffers. And double buffering still won't help your frame rate if it takes 1/20 sec or more to redraw a new buffer. With less graphics, you should be able to just maintain two separate DLLs and switch between them during retrace by simply updating DPPH and DPPL. And if you really think that you need two 16K screens, it would probably be a good idea to try a 32K flat RAM mode first.

Sorry, folks, not me. I don't have the time to research completely new and radical ideas like that. My goal was a board that could run as many released games as possible, plus a few obvious extentions like more bank address lines. I didn't expect to find such an easy hack to implement low-mode with one extra GAL output, but I'm glad I did, as it seems like a really useful memory layout.

Heck, it was a lot of work just to get where I could find out that the Hat Trick board RAM wasn't compatible with Maria accesses. I think Chad Schell is the only other person (since the '80s) to have reached a point where this bit of trivia was important, and he may not even have realized that the problem existed when working on the CC2. Let's see some people actually use cartridge RAM with the Maria before going to a lot of work like that.

Edited by Bruce Tomlin, Fri Jul 15, 2005 4:12 PM.

[supercat]

Bruce Tomlin, on Fri Jul 15, 2005 5:09 PM, said:

And how exactly is it supposed to know what kind of memory access is happening so that it can make such decisions?  This isn't an NES where the video chip gets its own bus.

Well, there could just be a range of addresses that's configured to always operate like that. Or the HALT line could be used (even better idea--wish I'd thought of it).

Quote

Sorry, folks, not me.  I don't have the time to research completely new and radical ideas like that.  My goal was a board that could run as many released games as possible, plus a few obvious extentions like more bank address lines.  I didn't expect to find such an easy hack to implement low-mode with one extra GAL output, but I'm glad I did, as it seems like a really useful memory layout.

My personal thinking is that CPLD's are getting sufficiently cheap that a board where a CPLD has near-total flexibility in memory layout would be quite practical. Once the board was laid out, new memory mapping schemes could be tried out simply by loading the CPLD with a new fusemap (which can even be done in-circuit). On the Atari 2600, a Xilinx 95C36 (a pretty cheap CPLD) can take all 13 address lines and 8 data lines as inputs, and have enough outputs to drive a 64Kx8 flash and 32Kx8 SRAM, controlling all but the bottom 7 address pins (which are supplied direct from the CPU). Because the 7800 has three more address bits from the CPU plus the timing signals, it would be necessary to lose some generality or else go to a larger CPLD (about $3-$4 more). The latter approach may be good from a development-community standard because the board could be made entirely general and then people could discover which features are really useful.

[Bruce Tomlin]

Like I said, go ahead and try it. :-)

The only way you can make sure a hardware project like that gets done is to do it yourself. That's why I started this whole thread in the first place: There are no boards for 7800 homebrews yet, and I wanted to see a board that was as flexible and simple as possible.

CPLDs are not "simple", if only because anything that involves surface-mount parts is not simple. There is also a lack of open software for them, and I don't do Windows.

[supercat]

Bruce Tomlin, on Fri Jul 15, 2005 5:35 PM, said:

CPLDs are not "simple", if only because anything that involves surface-mount parts is not simple.  There is also a lack of open software for them, and I don't do Windows.

Xilinx makes the software for the 95Cxx parts available for free. A programmer costs less than $100, or one can use plans available on-line to make one's own.

While it is certainly true that most people who would program a homebrew game would have neither the interest nor expertise to design a new fusemap for it, using a CPLD which could be set for one of a few 'normal' configurations for people who weren't ambitious but could be programmed to a special configuration by someone who was, would seem the best approach.

[Bruce Tomlin]

I think you still don't understand what I'm trying to say.

Unless you can find someone who is both a) capable of and b) wants to do such a project (and I am neither), it's not much more useful than someone posting in the Homebrews forum that they have a "great idea" for a 2600 game, and they want someone to program it for them.

[supercat]

Bruce Tomlin, on Sun Jul 17, 2005 1:41 PM, said:

Unless you can find someone who is both a) capable of and b) wants to do such a project (and I am neither), it's not much more useful than someone posting in the Homebrews forum that they have a "great idea" for a 2600 game, and they want someone to program it for them.

Well, I'd like to do it, but first on my agenda is a 2600 RAM-plus cart. But if I get that working, the 7800 cart hardware should be pretty easy.

[EricBall]

EricBall, on Fri Jul 15, 2005 11:44 AM, said:

Here's an interesting idea - separate CPU and MARIA banks, selected by the HALT line.  Or 32K of RAM as two 16K banks selected by HALT XOR a CPU settable flag for implementing seamless double buffering of a bitmapped display.

Bruce Tomlin, on Fri Jul 15, 2005 5:09 PM, said:

That sounds rather clever.  Why don't you try it out?  :-)  Anyhow, if you have enough graphics to use up a whole 16K of RAM, you probably won't have enough CPU time to fill the buffers.  And double buffering still won't help your frame rate if it takes 1/20 sec or more to redraw a new buffer.  With less graphics, you should be able to just maintain two separate DLLs and switch between them during retrace by simply updating DPPH and DPPL.  And if you really think that you need two 16K screens, it would probably be a good idea to try a 32K flat RAM mode first.

It's something which occurred to me over on the Lemmings! 7800 thread. The double buffering is just so the CPU can update the bitmap without corrupting the active display. I agree that the amount of CPU time will be very small, which will probably mean a low frame rate to boot.

Bruce Tomlin, on Fri Jul 15, 2005 5:35 PM, said:

The only way you can make sure a hardware project like that gets done is to do it yourself.  That's why I started this whole thread in the first place: There are no boards for 7800 homebrews yet, and I wanted to see a board that was as flexible and simple as possible.

Hmm, I think I've heard something like that before. Ahh, right, it was me responding to request for arcade-perfect ports to the 7800.

Bruce Tomlin, on Fri Jul 15, 2005 5:09 PM, said:

Sorry, folks, not me.  I don't have the time to research completely new and radical ideas like that.  My goal was a board that could run as many released games as possible, plus a few obvious extentions like more bank address lines.  I didn't expect to find such an easy hack to implement low-mode with one extra GAL output, but I'm glad I did, as it seems like a really useful memory layout.

Hmm, I didn't realize that was your original goal, although it seems that you have accomplished it. I thought you were trying to come up with a cheap & simple way to create >32K 7800 homebrews.

[Shawn Sr.]

So is AtariAge or Pixels Past gonna put this thing into production when Bruce is done? Or do you plan on getting it produced yourself Bruce? I'm getting excited enough I might break down and buy a cheap EPROM burner..lol..

This thread makes me smile everytime I see a new reply to it. I can't wait for this 7800 board to get produced for the public!!