# Brainstorming new ROM carts beyond 2MB

## Recommended Posts

Yep.

I know Jim has been hard at work with the 512MB and 2M boards... but let's think a little bigger and talk about this, because I'm really wanting to find out what some of the limits and options are for more "cold storage", so to speak. Why? Cause it can be done

I saw Jim talking a little bit in the Zeno board thread, and didn't want to hijack that one, so I made this one to talk about thoughts going forward on this.

Let's take a rundown of what we've done so far (just speaking of ROM carts):

1st run of boards: 74LS379, only one gate latch out of 4 attached (A14 on TI), meaning 16K possible

2nd run of boards: 74LS379, three gate latches attached (A14, A13, A12), meaning 64K possible (and I hacked some to 128K).

3rd run of boards: 74LS378, six gate latches attached (A14 down to A09), meaning 512K possible

4th run of boards: 74LS377, eight gate latches attached (A14 down to A07), meaning 2MB possible

So where are we as far as the way we're doing this?

According to a nice diagram Stuart Connor made, it kind of looks like this:

So that means, we can use A3, A4, A5, and A6 on the TI left with this banking method. (Someone please explain why A0-A2 are ghosted out; I never asked. I just assumed we couldn't use them because of them because they were not a reliable way because they were going high/low for something else.)

Future expansion from here means:

A3 - We have a 4MB cart

A3,A4 - We have a 8MB cart

A3,A4,A5 - We have a 16MB cart

A3,A4,A5,A6 - We have a 32MB cart

Issue #1:

So, we have gone all the way to the 74LS377, which is eight latches. We need to go to twelve. I have not yet found a discrete flip flop with enable for 12 flip flops.

Some potential brainstorming:

1) Daisy chain two logic chips together with some added discrete parts; (yeah, we're already tight on the board as it is)

2) Program a PAL or GAL to do it

Issue #2:

We're running out of large parallel EPROMs that can be addressed with 8 Bit. Ksarul found some pretty rare 2MB ones that are hit and miss when programming in 8 bit mode. If we want to find an 4MB, 8MB, 16MB, or 32MB one, we're probably out of luck, but I haven't Googled too extensively to find any.

Some potential brainstorming:

1) Parallel to flash RAM adapter using some support circuitry. 32MB flash (5V capable or 3.3 with a level shifter)

2) Possibly I2C?

3) Adapting Serial flash chips? Those are tiny. We can probably use several.

Go forth and comment.

##### Share on other sites

... so I'm sitting this one out! It's very interesting though!

##### Share on other sites

What are you going to put in a larger cart? In the 2 meg cart we've got 8 pages of menus. It gets extremely complex to program such a device at that point and it certainly won't get any easier to do a larger cart. Seems to me like 2 meg is plenty, there's only 1 .bin file so far to fill the cart we have now, and I don't see any more being created by anyone yet.

Maybe if some other individuals stepped up and created some more large images for the 2 meg cart it would make sense to make a larger one, but it looks as if making a larger capacity cart would be putting the cart before the horse.

Gazoo

##### Share on other sites

I know very little about cartridges but I thought their size was limited by only having 12 grom bases available?

Obviously not.

Edited by mnbvcxz

##### Share on other sites

I've nearly finished a design for a 128MB - 512MB board using 128MB flash chips, I'm just (slowly) drawing out the schematic.

The basic concept is to use the existing write-to-rom scheme for the first 32MB of space, using 12 bits of latch (which is the maximum possible with that scheme), and make up the additional bits with CRU. (To make the board flexible the CRU has a basic address extension to 128MB, and then chip selects to select which 128MB chip. This makes flashing the chips in circuit easier). I'll have to get home to see the chips I found again, but they are 8-bit compatible. They do require a 3.3v level shifter.

I'm still working out whether the write line would be best served with CRU or if a physical switch will do (to change between banking and flashing). I have a feeling CPU control may be necessary, but I need to double check the datasheet.

This was after working out a compact-flash based system and an ARM/SD combination -- this solution is available, simpler, and inexpensive enough. It does require surface mount parts so I need to look into manufacturing for it.

##### Share on other sites

(Someone please explain why A0-A2 are ghosted out; I never asked. I just assumed we couldn't use them because of them because they were not a reliable way because they were going high/low for something else.)

They don't exist on the cartridge port. If they did, there would be a lot more we could do there!

##### Share on other sites

I know very little about cartridges but I thought their size was limited by only having 12 grom bases available?

Obviously not.

There are two types of memory possible on a cartridge - ROM and GROM. ROM is accessed directly by the CPU, while GROM is a semi-independent memory space. GROM has actually got 16 bases defined, but that's only by convention. Stretching out the memory map allows 256 possible bases without conflict (but the console ROM will only search 16). That's without implementing your own banking system, too.

ROM is limited to 8k of space, but by implementing banking hardware on the cartridge we're already up to 2MB. Using the existing scheme we can hit 32MB, then we need to expand it.

The nice thing about banking though, is that you are not limited by anything but your imagination how you do it. The trick is just designing something that can actually be built.

##### Share on other sites

Tursi is the resident hardware guru, so I'll leave the technical stuff to him. But basically there are ways of expanding on what's been done. Like he said, it's just figuring out a way to do it that is efficient and cost effective. What has been done with the current boards is essential an addon MMU. I'm not even remotely familiar enough with the TI hardware or software to discuss in detail how one would go about expanding the system further. But since I'm currently building an 8-bit, I have researched quite a bit into expanded memory systems. There are lots of things that could be done once you start implementing software support. One clever example I saw a while back was a guy that used 8255 PIOs to implement a IDE interfaces with DMA. Which, is basically what was done with the nanoPEB of I'm not mistaken. But a scheme like this could also be done with ROM memory, I would think. But then, as pointed out above by Gazoo, what would you put in it? 2megs is a lot of data where the TI is concerned. Are there really that many Applications and Games you would want to stick on one board?

##### Share on other sites

I'm not the guru, I'm the "inventor" in the garage in the run-down house on the end of the street whose stuff only works about 10% of the time and never finishes most of them. If I had a wife she'd be nagging me to invent something useful. Only when other people run with it do you see a finished product. (But I like it.)

You know, though, there are other things you can do with a cartridge besides make a multicart. I need a new board for Dragon's Lair, for starters, because it's not going to fit in 2MB.

Anyway, one of the flash chips I was looking at is the Spansion S29GL01GP11 (http://www.digikey.com/product-detail/en/S29GL01GP11TFIR10/S29GL01GP11TFIR10-ND/3862806). This is a standard 8/16 parallel flash ROM in a TSOP 56-pin package with 128MB of space. It's not cheap, it runs about \$18 apiece, but that's why I figured the cart should be designed to transparently support 1, 2, 3 or 4 chips (I have a personal use for all 4 ). Slowest access time is about 155uS, which is on the slower side for modern memory but well within the TI's needs (and draws only 50mA when programming, 30mA when reading).

Voltage conversion is needed, but an octal bus transceiver like the TC74LVX4245 (http://www.digikey.com/product-detail/en/TC74LVX4245FS(EL,F/TC74LVX4245FSELFCT-ND/989662) could be used. We'd need a few on the board, but they are small and only about 1.82 in single quantities.

After that, we just need the 74 latches (two will do - http://www.digikey.com/product-detail/en/SN74LS377NSR/296-29917-1-ND/2782647 - \$1.45ea). So that gives us 25 bits of address space (13 on the cart port and 12 on the latches - total size 32MB - full compatible with what everyone already knows).

To fill out the rest of a 128MB chip, then we need another 2 bits (32x4=128) for the address space, then another 2 bits for chip select (4 chips). So we need 4 bits of CRU. (This was inspired by SuperSpace ). SuperSpace uses CRU base >0400, as it's unused otherwise, so that works. Thierry has a nice CRU circuit on his page, so if we borrow that, we can have 8 bits with a 74LS138 (http://www.digikey.com/product-detail/en/SN74LS138DR/296-14883-1-ND/562584 - 78c ea) and 74LS259 (http://www.digikey.com/product-search/en?vendor=0&keywords=74ls259&stock=1 - \$1.17 - but through-hole only. More searching needed for a replacement).

We should be good and decode the chip select, so that's another 74LS138 (sadly we can't reuse the extra space on the first one), otherwise we rely on software not to enable two chips at once. Not the best plan!

Note the above links are just samples, I haven't sketched the whole circuit out yet. But the bar napkin calculation says this is 9 chips for 128MB or 12 chips for 512MB (with 4 spare CRU lines, one of which may be needed for software flash control), with a rough chip cost of \$29 for 128MB or \$83 for 512MB. Because the flash are surface mount, the whole circuit could be surface mount, and that should work fine so far as space goes. Most of that cost IS the memory, admittedly, and serial flash is a lot cheaper, but the cartridge gets a lot more complicated.

The glue logic would also fit into a small CPLD pretty easily, which is nice since it doesn't need an EEPROM. The glue above was listing around \$5 (level shifters being the rest), cheap CPLDs start around \$1.20. So that knocks \$5 off the price and simplifies the PCB a lot at the cost of some VHDL. Looks like there are still a couple of 5V tolerant CPLDs that might be able to do level shifting for about \$5, so that is probably the way to go to reduce construction costs. (http://www.digikey.com/product-detail/en/M4A5-64%2F32-10VNC/220-1846-ND/2752324). But you could prototype it either way.

Then you still need filtering and 3v power on the board, so it's not going to be cheap either way unless you get the flash cost down. But this is just a first pass at feasibility. And just my thoughts. The nice thing about a compact flash or SD-based solution is you can build the large memory a lot cheaper (especially with an SD card - in fact you could drop an SD card onto an AVR, write some AVR software, and have full access to the memory over the GROM interface -- that was one of the original plans I didn't quite finish for UberGROM). You just can't get real time memory performance out of that solution - for copy carts and the like, you probably don't need it!

Edited by Tursi

##### Share on other sites

You know, though, there are other things you can do with a cartridge besides make a multicart.

... or a true F18A compatible GUI/OS interface!

But something like this would take the TI to a whole new level, are users ready for that?

##### Share on other sites

They don't exist on the cartridge port. If they did, there would be a lot more we could do there!

Ah, I knew there was a reason (without pulling out the pinout). Ksarul and I have been talking about a passthrough cartridge port on the sidecar bus to enable all these missing pins. Thoughts are right now that it can have possibly two card edge females; one for a standard 36 pin cartridge (or multiple ones, aka Widget), and one that will have a nice new pinout; including both items only on the cart port and ones only on the sidecar. I'm working on the mapping for that one right now, and will just need to work with some of you hardware gurus to figure out the buffer chips, since it'll be a passthrough device. I'm estimating a 50 pin connector would be a new 'enhanced' connector.

Pins that exist only on the cartridge port; would have to be brought to side with a passthrough from the cartridge port. We might be able to derive these from other pins on the 44 pin sidecar port.

01 RESET Resets the system (active high) [Note: sidecar has RESET*]

21 GS* Grom select. Active low is addr in >9800-9FFF

27 GRC GROM clock: color burst of VDP 9918A

31 GR Active high = GROM ready

34 ROMG* Active low if addr in >6000-7FFF

The benefits of side pins include:

2 SBE Low if addr in >9000-94xx (sound port)

3 RESET* System reset (active low)

4 EXTINT* External interrupt (active low)

20 A2 Address bus, bit 2

24 PHI3* Inversion of phase 3 clock

28 MBE* Active low if addr in >4000-5FFF (card ROMs)

30 A1 Address bus, bit 1

31 A0 Address bus, bit 0 (most significant)

32 MEMEN* Memory access enable (active low)

41 IAQ Interrupt acknowledged by TMS9900

44 AUDIOIN To sound generator AUDIO IN pin

##### Share on other sites

Acadiel, you have just given me an evil idea for the sideport. Set up a standard 378 latch that latches two chips simultaneously--one on 8K Boundaries and one on 16K boundaries. Stick that on a sideport with an 8K RAM space and a selector that allows you to go active sidecar or passive sidecar, and you get the possibility to write really nice programs that bank 24K at a time. . .and the plug-in cartridges for it don't need the banking circuitry or the 8K of RAM, because it is already in the sidecar. It would occupy the same space as the memory expansion, so using AMS memory might be a better option, but this would reduce what Tursi needs in his cartridges too. . .as the cartridges could use the larger chips and all of the level-shifting could be done on a larger board too.

##### Share on other sites

Just build something with an SD card reader built in dammit. Then all your problems are solved. Here's how I would do it (if I had the skills)

Put a bunch of RAM in the cart

Put a uController in the cart

Put an SD reader/writer into the cart connected to the uController

The SD card hosts ROM and GROM images. A GROM program (so that it can load at system startup) would allow the user to select which ROM/GROMs are "installed" in the cart slot from the ones that are available.

When a ROM/GROM cart is selected, the uController reads the appropriate files, and writes it into the RAM (which the 4A sees via the cart port).

'Cos it's ram the 4A could also write to it.

Awesome.

##### Share on other sites

Just build something with an SD card reader built in...

If/when something like that is ever built, I'm an automatic +1!

My head is spinning from all these ideas. You guys are bloody brilliant!!

##### Share on other sites

Acadiel, you have just given me an evil idea for the sideport. Set up a standard 378 latch that latches two chips simultaneously--one on 8K Boundaries and one on 16K boundaries. Stick that on a sideport with an 8K RAM space and a selector that allows you to go active sidecar or passive sidecar, and you get the possibility to write really nice programs that bank 24K at a time. . .and the plug-in cartridges for it don't need the banking circuitry or the 8K of RAM, because it is already in the sidecar. It would occupy the same space as the memory expansion, so using AMS memory might be a better option, but this would reduce what Tursi needs in his cartridges too. . .as the cartridges could use the larger chips and all of the level-shifting could be done on a larger board too.

Hi,

hmmm, as the topic here is called "brainstorming"...

/edit/ and I am oblivious

maybe something on the sideport, likely as the nanoPEB, with a memorycard which

1. is DSR-accessible as DSK5+ ("Call mount" maybe, but not from "nanoPEB-volumes" BUT from FAT16-DSK-files) ?

2. and wherefrom BIN-files for dynamically filling your "super-banks" can be pre-defined & read too

(where 1.this DSKs & 2. this BINs can be copied to the memorycard with the PC, because of FAT16 ?

3. and the whole DSR is updatable from a bootfile on the memorycard, at power-on (like the HXCSDFE.CFG-file on the HxC-drive)

And with a "passthrough" for the sidecar, like the speechsynthie, not terminating the connector/bus like the nanoPEB does.

Means on the left side the connector to the TI, and on the right side the passthrough-connector for i.e. the PEB or whatever.

Or, if you design something for the sideport, maybe it could optionally fit into the PEB too ? Not a SuperCart, but a SuperCard ?

Just like the Speech-in-the-PEB, as an adapter-option for PEB-owners. With its left-side-connector plus an small adapter stucked into the PEB.

And if this option is used, the passthrough-connector (right side) will be unused of course, and you maybe could use ist for further

expansions inside the SuperCard/ClamShell inside the PEB?

Oder so ? BrainHurrycane

##### Share on other sites

If/when something like that is ever built, I'm an automatic +1!

My head is spinning from all these ideas. You guys are bloody brilliant!!

Same here! But only if the device allows drag and drop functionality into the card and can handle various file formats.

##### Share on other sites

For this sidecar cart slot ..

* Passthrough slot for other hardware (Has buffer chips, so will work with other stuff)

* Uber 50 pin female for card edge with all signals from cart port etc.

* 2 or three 34 pin cartridge port connectors

* Three or four position switch, wired to actually kill the +5V correctly (so that this will also let the UberGROM cart work in the expander)

* Thinking of just soldering the extra five wires from the console (GROM pins from cart port, ROMG*, RESET) directly to the board, or via a small five pin connector. This leaves the cart port free too.

## Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

×   Pasted as rich text.   Paste as plain text instead

Only 75 emoji are allowed.

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.