512K Cartridge Status

[brain]

So, on your AVR solution, hwo do you signal to the AVR which banks of GROM you want to be active for a given config? I assume you have a ROM menu or default GROM implementation that shows a menu, and then menu siwtches the ROM and the GROM to some other "bank". But, how does the GROM bank work? Is there a set of presets (preset 1 is GROM banks 3 4 5 6 and they come from PROGRAM MEM 0-32K. preset 2 is banks 3,4 and those come from PROGMEM 32-48K, etc.? Or is it done differently?

 

Jim

[Tursi]

I'm not sure if you are asking me for the hardware details or someone else for software details...

 

Because terminology I'll just describe the hardware here. If you are asking after software you might need to specify which software to get a description from the author.

 

GROMs are accessed via an address in the 9900's memory space called a "base". The default GROM base is at >9800. However, there is provision in the design of the console and support in the startup code for additional bases to exist at other memory addresses, separated by four bytes. The console itself checks for up to 16 of these bases.

 

So, the base is selected via the address you use to access the GROM. The AVR thus checks the 4 least significant bits of the 15-bit address bus when a GROM access comes in to determine which base the program is accessing.

 

The way that the console is wired, the console GROMs respond to all bases, thus, my AVR as released is designed to avoid conflict with them by responding only to cartridge GROM addresses (>6000 - >FFFF).

 

Where the data comes from in my AVR for a specific base and specific GROM address depends on the configuration that the user has set up. It has a full memory mapper in it and can locate any of its memory or peripherals at any combination of base and address (which I called a 'slot' for that reason.)

[Gary from OPA]

I'm not sure if you are asking me for the hardware details or someone else for software details...

 

Because terminology I'll just describe the hardware here. If you are asking after software you might need to specify which software to get a description from the author.

 

GROMs are accessed via an address in the 9900's memory space called a "base". The default GROM base is at >9800. However, there is provision in the design of the console and support in the startup code for additional bases to exist at other memory addresses, separated by four bytes. The console itself checks for up to 16 of these bases.

 

So, the base is selected via the address you use to access the GROM. The AVR thus checks the 4 least significant bits of the 15-bit address bus when a GROM access comes in to determine which base the program is accessing.

 

The way that the console is wired, the console GROMs respond to all bases, thus, my AVR as released is designed to avoid conflict with them by responding only to cartridge GROM addresses (>6000 - >FFFF).

 

Where the data comes from in my AVR for a specific base and specific GROM address depends on the configuration that the user has set up. It has a full memory mapper in it and can locate any of its memory or peripherals at any combination of base and address (which I called a 'slot' for that reason.)

What about the ROM's, on my POPCart design I had it setup that the pair or quad set of rom's would switch also based on the slot of grom that was being accessed, allowing for multiple cartridges containing both rom and grom to work without any patching.

 

But using also the CRU interface found in pre v2.2 consoles, the POPCart would reply to the CRU Base >0B00 and allow for manually forcing of certain bank of rom, or disable the auto-switching or totally disabling the ROM space to allow ram to come inplace instead at the >6000 space, and to enable or disable GROM write access.

 

Is this something you decided to do, or setup a similar system of control?

Edited May 28, 2014 by Gary from OPA

[+acadiel]

AFAIK, no CRU control or any other way to control what roms go with which GROMs unless both ROM/GROM programs are patched with new ROM banks locations. We wanted to keep the design simple. :-)

[Gazoo]

What about the ROM's, on my POPCart design I had it setup that the pair or quad set of rom's would switch also based on the slot of grom that was being accessed, allowing for multiple cartridges containing both rom and grom to work without any patching.

 

But using also the CRU interface found in pre v2.2 consoles, the POPCart would reply to the CRU Base >0B00 and allow for manually forcing of certain bank of rom, or disable the auto-switching or totally disabling the ROM space to allow ram to come inplace instead at the >6000 space, and to enable or disable GROM write access.

 

Is this something you decided to do, or setup a similar system of control?

 

That's how the HSGPL operates, each Grom page has a quad set of Roms that are linked to it. So you can put any cart that isn't hard coded for a particular Grom page into any page. And every page has all 8 Groms, so you have to use the same Grom0 in every page or you get 'unpredictable results'. Although I've found you can change the character set in Grom0 if a cart needs a particular set, such as Turboforth, with no ill results.

 

Gazoo

[Gary from OPA]

That's how the HSGPL operates, each Grom page has a quad set of Roms that are linked to it. So you can put any cart that isn't hard coded for a particular Grom page into any page. And every page has all 8 Groms, so you have to use the same Grom0 in every page or you get 'unpredictable results'. Although I've found you can change the character set in Grom0 if a cart needs a particular set, such as Turboforth, with no ill results.

 

Gazoo

Yeah, well from my understand of Ubergrom it will not have this problem as it does not override the console groms.

 

But I would like to see Ubergrom handle the auto ROM switching of slots similar to HSGPL and my POPCart switching blocks of ROM pages based on the current grom bank address, would make it easier to mix and match almost all cartridges out there without problems.

 

As for GROM 0 I think I produced a page of entry points that are needed for a shorten grom 0, just enough to any cartridge to use, switching back to actual grom, from my memory it was less then 1k in side, leaving you the other 7k available for your own code in other banks, and only a couple of modules i found use hard-coded jumps into ti basic, so that normally not a problem.

[Gazoo]

It really does make sense on the ground tie--the resistor drops the voltage and the point we sample for our low is then right at ground potential. We have very few resistors on this port (I keep component count as low as I can on the cartridge boards), and previous iterations have had one or two more than this one has now.

 

My reference on the IC I was looking at was based on the timing data to generate valid output data--it triggers from whichever of the two signals goes low first. Reading further, it looks like it still doesn't release the data though, so we're good.

 

Well, I've got a board with a resistor and switch ready to test, just need my 1 meg eproms to show up.

 

Could the circuit being discussed be used to reset the 74LS378 chip? Use a resistor in series with the +5 power to the chip (pin 16), and a spst pushbutton switch to temporarily ground pin 16, thereby resetting the chip to it's initial state. This would provide a means of resetting the cart to the bank with the header in it if it somehow got 'lost', or eliminating the need to re-power the console when using Tursi & Acadiel's eprom. I don't know a whole lot about the subject, but it's seems like a reasonable assumption.

 

Gazoo

[Gary from OPA]

Well, I've got a board with a resistor and switch ready to test, just need my 1 meg eproms to show up.

 

Could the circuit being discussed be used to reset the 74LS378 chip? Use a resistor in series with the +5 power to the chip (pin 16), and a spst pushbutton switch to temporarily ground pin 16, thereby resetting the chip to it's initial state. This would provide a means of resetting the cart to the bank with the header in it if it somehow got 'lost', or eliminating the need to re-power the console when using Tursi & Acadiel's eprom. I don't know a whole lot about the subject, but it's seems like a reasonable assumption.

 

Gazoo

The problem is the 378 does not always seem to power-up with the same initial state, different batches power-up different ways.

 

You can add a reset switch to all consoles to do a hard-reset as if you pulled and pushed in a cartridge, one of my special homebuilted super-carts has one.

Edited May 28, 2014 by Gary from OPA

[Gazoo]

The problem is the 378 does not always seem to power-up with the same initial state, different batches power-up different ways.

 

You can add a reset switch to all consoles to do a hard-reset as if you pulled and pushed in a cartridge, one of my special homebuilted super-carts has one.

 

I've added reset switches to carts, too. That's not the issue here. The 378's appear to all power up in the first or last bank WHEN RE-POWERED, which is an acceptable condition. A console reset does not accomplish that task.

 

Gazoo

[Tursi]

We believe a reset switch should work on the 378, haven't done it. I can't think of why not though.

 

A cartridge with a GROM on it can use a powerup routine to reset the 378's default bank, though. That's what my failed Chicago Demo cart does

 

As for switching ROM banks, there's no provision for an automatic hardware selection on the board, but you could do it in software a few different ways. The GROM offers four dedicated GPIO pins, so with a little board hacking you could re-route those to the ROM and have your menu program set them before launching. (Just as one idea. Any room for four more jumpers, Jim? )

 

My intentions here (which may differ from Jim's) was not to offer an "all-in-one-does-everything" device, but to offer a way to move forward with new cartridges that include GROM, and also to reproduce old ones like E/A and XB.

[Gazoo]

We believe a reset switch should work on the 378, haven't done it. I can't think of why not though.

 

A cartridge with a GROM on it can use a powerup routine to reset the 378's default bank, though. That's what my failed Chicago Demo cart does

 

As for switching ROM banks, there's no provision for an automatic hardware selection on the board, but you could do it in software a few different ways. The GROM offers four dedicated GPIO pins, so with a little board hacking you could re-route those to the ROM and have your menu program set them before launching. (Just as one idea. Any room for four more jumpers, Jim? )

 

My intentions here (which may differ from Jim's) was not to offer an "all-in-one-does-everything" device, but to offer a way to move forward with new cartridges that include GROM, and also to reproduce old ones like E/A and XB.

 

The idea regarding the reset switch is for the 512k cart, there is no Grom present there to provide the code for Rom bank reset.

 

In the code I posted for the 632k cart, my Grom code writes to >6000 before starting Extended Basic v2.7, and it banks in the required banks of Rom when moving the utility programs to expansion memory. A reset for the 378 in that cart would be as necessary as tits on a bull.

 

Gazoo

[Gazoo]

Just to clarify, you do not need to worry about OE. the truth table for ROMs (and RAMs) is such that CE being inactive (typically high) completely isolates the ROM/RAM from the bus. Also, 2200 is a bit heavy, as 5V/2200 = 2.3mA, and FLASH ROM inputs typically only need 5-10uA to drive the pin. 10K puts 500uA on, which is way overkill, but is considered a standard given the wide variety of ROMs and RAMs (EPROM takes more, for instance).

 

I do concur the 27C080 with a switch on pin 1 would be preferred. Tie the pin to 5V through the 10K resistor and then ground with the switch.

 

Jim

 

Ok, it's done and works like a champ! I put both the 512k Gamecarts I created into one cartridge using a 27C080 eprom (1 meg). The 512k cart desired is selected with a toggle switch. There are a total of 76 games on this 1 cart!

 

Here's a few pics of the mod in case someone else wants to do it. Solder in the 10k resistor as shown, with a wire attached to the end shown. I drilled a hole in between traces on the board to bring the wire out on top to attach to the switch but you could probably wrap it around the end of the board. Solder another wire to the ground hole as shown. The switch is available at Radio Shack, part number 275-0645. The resistors are available there too, part number 271-1335.

The 1 meg file for the 27C080 is attached in case someone doesn't have the capability to join the 2 Gamecart files.

1MegGamecart.zip

Enjoy!

Gazoo

[+acadiel]

Nice work!! That reminds me of when I had to do the 128Kx4 because of the 74LS379 usage (before Ksarul suggested looking at the 378, which I didn't know existed at the time.)

 

It's amazing how this little cart board has evolved since I started. I'm truly impressed at everyone's effort!

[+Ksarul]

Actually, you and I had pretty much the same goal set with the ÜberGROM, Tursi. The fact that it can do a lot of extra things was a bonus, not a primary design goal. Most of my let's-try-to-make-it-do-everything energy has been directed at the 512K cartridges, as there are a lot more ROM developers than GROM developers.

 

I'll look to see what can be done on the jumper front too--I might actually be able to add the jumpers you need (just let me know which lines you need them connected to to effect the behavior you want).

[+Ksarul]

Excellent, Gazoo! This mod will be a lot easier to do with the next batch of boards, as all of the traces and space for the components will be in place--you won't even have to drill a hole for one of the the wires, as I placed solder pads to the left of the 74LS378 for them. Doing the mod does mangle the ability to use the 512K version of the non-volatile SRAM though (although I may be able to find space for a jumper to get rid of that problem too, as I've found the perfect spot to do it--if I can get a jumper block in place for it).

[Tursi]

I'll look to see what can be done on the jumper front too--I might actually be able to add the jumpers you need (just let me know which lines you need them connected to to effect the behavior you want).

I suspect it would work to jumper the GPIO pins so they can control the top four address lines of the ROM instead of coming from the 378. (Or, since they are jumpers, the developer can choose how many they want). Basically, then, the base ROM bank would be selected by writing to GROM.

 

I don't intend to test this, though... it should work fine but maybe it's better left as a hack? I don't know.

[Gazoo]

I suspect it would work to jumper the GPIO pins so they can control the top four address lines of the ROM instead of coming from the 378. (Or, since they are jumpers, the developer can choose how many they want). Basically, then, the base ROM bank would be selected by writing to GROM.

 

I don't intend to test this, though... it should work fine but maybe it's better left as a hack? I don't know.

 

Leave it as a hack. I don't see any need for it as the same function can be accomplished by using Grom code to select the Rom bank by writing to Rom.

 

Gazoo

[brain]

I'm not sure if you are asking me for the hardware details or someone else for software details...

 

Because terminology I'll just describe the hardware here. If you are asking after software you might need to specify which software to get a description from the author.

 

GROMs are accessed via an address in the 9900's memory space called a "base". The default GROM base is at >9800. However, there is provision in the design of the console and support in the startup code for additional bases to exist at other memory addresses, separated by four bytes. The console itself checks for up to 16 of these bases.

 

So, the base is selected via the address you use to access the GROM. The AVR thus checks the 4 least significant bits of the 15-bit address bus when a GROM access comes in to determine which base the program is accessing.

 

The way that the console is wired, the console GROMs respond to all bases, thus, my AVR as released is designed to avoid conflict with them by responding only to cartridge GROM addresses (>6000 - >FFFF).

 

Where the data comes from in my AVR for a specific base and specific GROM address depends on the configuration that the user has set up. It has a full memory mapper in it and can locate any of its memory or peripherals at any combination of base and address (which I called a 'slot' for that reason.)

 

I understood the basic design (AVR listens on the 4 address bases, and only responds to GROM 3-8 in a base.

THere is also some ROM on board the design.

 

My question was probably more directed at the memory mapper. Can the memory mapping be changed dynamically, or is this something that is hard coded into the AVR FLASH (so, to change it, you have to reflash the ROM with a new set of GROM files and a mapping?). If it is dynamic, how does someone state to the AVR: I would like to place this 5kB GROM file at this GROM slot on this base address...

 

Jim

[+acadiel]

Excellent, Gazoo! This mod will be a lot easier to do with the next batch of boards, as all of the traces and space for the components will be in place--you won't even have to drill a hole for one of the the wires, as I placed solder pads to the left of the 74LS378 for them. Doing the mod does mangle the ability to use the 512K version of the non-volatile SRAM though (although I may be able to find space for a jumper to get rid of that problem too, as I've found the perfect spot to do it--if I can get a jumper block in place for it).

 

Heh.. I think that'll be our next thing to tackle (jumpers). Otherwise, I'll be buying stock in bulk purchases of jumpers on eBay like this: http://www.ebay.com/itm/1000-PCS-2-54mm-Standard-Circuit-Board-Jumper-Cap-Shunts-Short-Circuit-Cap-/291138609395?pt=LH_DefaultDomain_0&hash=item43c936a0f3

 

:-) :-)

[+Ksarul]

I found a good deal on a bag of 5,000 of them a couple of years ago, Acadiel. I think I paid $5, shipped. The pricey part of jumper installation are the breakable header pins--I prefer the gold plated ones, but most everything that is showing up for sale in larger quantities isn't gold plated anymore, even when the listing says they are. . .I've been burned by two different sellers on that one, so I have a few hundred 40-pin strips that I won't use.

[+acadiel]

Hey Gazoo, here's another one.

 

Attached is the 32K EPROM (copy to 32K) as well as the raw >A000, >C000, and >E000 code.

 

 

arcturus.zip

[Asmusr]

I hate soldering the jumper headers, they always move out of place, and it's one of many situations where you need at least three hands when soldering. First I started to glue them on before soldering, and on my latest boards I replaced them with hard wired connections. Is there any trick I should know?

[Gazoo]

I hate soldering the jumper headers, they always move out of place, and it's one of many situations where you need at least three hands when soldering. First I started to glue them on before soldering, and on my latest boards I replaced them with hard wired connections. Is there any trick I should know?

 

"Honey, can you come here and help me for a minute?"

[+Ksarul]

I just take a small block of wood, drill some shallow holes into the appropriate spots, fit the jumpers, put the block in place and flip the board over. It also works fine doing this using an undrilled board, but sometimes a couple of the jumpers get away the first time. Then I just solder the ones that made it and repeat. . .until I get them all. I've gotten pretty good at not losing any after soldering well over 100 of the V2, V3, V4, V6, V8, and V9 boards. . .

[+acadiel]

I hate soldering the jumper headers, they always move out of place, and it's one of many situations where you need at least three hands when soldering. First I started to glue them on before soldering, and on my latest boards I replaced them with hard wired connections. Is there any trick I should know?

I have a trick for this. Do you know that black ASD foam that chips come seated in? I simply put that over the headers to keep them in place while I flip the board. I then solder one from each jumper header, flip it back over, take off the foam, straighten if needed, and then solder the other one. I only have to solder the other one or two ones separately that aren't part of that cluster.

 

And no, the solder gun doesn't melt the foam for some reason :-)