Dumb ideas for full 8k paged in cartridge mem

[wierd_w]

I don't know why my brain won't let this go, but here it goes anyway.  I am pretty sure, since this has never really been done before, that this won't work.  I will be up front about that. This is mainly a transparent plea to silence the bad ideas part of my head by giving me information needed to shut it up.

 

That said, here is the idea that won't die.

 

First, how GROM is SUPPOSED to work.

 

A GROM is accessed first by GROM Select High enabling the GROM chip, setting the M line Low, and then MO pin High. This tells the GROM chip that you are wanting to write to it (Specifically), and that you are writing an address to the address counter. Then you write the 8 bit address you want, and then set M High, and MO Low. This tells the GROM that you are reading, and want the data bits.  Each subsequent read is auto incremented.

 

One could also read the current address (even though it increments, I understand, once you do) by setting M High, and setting MO High, then getting the value from the chip register.

 

This gives the following truth table, assuming Grom Select is high.

 

M | MO
---------
H  |  H  == Read Address
L   |  H  == Write Address
H   |  L  == Read Data

L   |  L  == Write Data

 

Since you cannot (normally) write to a GROM, we could use M=Low + MO=Low + GSelect=High to determine that a page switch is requested, then capture the 8bits written as the page number (0-255) to swap to.

 

This could be caught with a latch, to drive a mapper chip.

 

With a single "GROM chip" (either a real GROM abstracted with a latch, or clever "Latch + Rom" circuit), this would give us potentially 2Mbyte of memory in 8k pages that could be tracked and mapped in and out.

(If you have a second GROM, and thus another grom select line, you could further expand this exponentially for each grom ID you use for this.)

 

The caveat is that the write attempt will increment the GROM address register, so a bankswitch with this approach will be execution cycle expensive. (Burns at least 2 operation cycles-- One to do the bank-switch, and another to reset the GROM address register.) As long as you are not paging like crazy, this should not be a big deal though. 

 

This COULD be avoided though, if having that combination of signal lines set causes the latch circuit to disable the GROM chip temporarily (only removes the data/address lines, does not detach GROM CLK), set GROM Ready High, catch the written byte, then re-enable the GROM chip. This would prevent the GROM chip actually noticing that any operation was done to it at all, and thus prevent the increment.

 

 

 

Thoughts, criticisms, or other commentary?

 

 

 

[+Ksarul]

There are some issues here: the console power-up routines only recognize a limited number of GROM bases, and each GROM base is "technically" limited to five GROM chips (GROMs 0, 1, and 2 are in the console and are generally excluded, but may be used, as seen with applications for the GRAM Kracker, GRAMulator, HSGPL, and MaxiMem). The UberGROM board allows you to set up 15 GROMs (and 1 GRAM space), using multiple GROM bases of your choice. Similar multiple GROM-base solutions were also used BITD: the OPA POP Cart, the Guion-modified Triton Super Extended Basic cartridge, and at least one German multicart board. Note that even more devices emulate the 5-chip cartridge GROM space of a single GROM base (Wiesbaden Supermodul and Supermodul-2, TCB Modul, Karlsruhe Modul, Errorfree Modul, FinalGROM, TI EGROM cartridges, and others). So it has been done to some extent, just not at all matching your use case. The HSGPL card is probably closest, as it fills a 512K space with GROM data and switches context from module to module from a master menu.

[brain]

@Ksarul Is there a way to describe how the banking is done on these other devices?

 

@wierd_w I like the idea, but I would consider making it more bulletproof.  Since a writeable GRAM device is possible using today's tech, it seems prudent to make the "write" more compatible with such GRAM devices.  Maybe use the 1fff location as the address to "write", or something like that.

 

I'd love to prototype a GROM with this capability for test.

 

Jim

 

[Tursi]

The GROM banking that is the default on the console works by also capturing a few of the CPU address lines, and determining which "base" address was used to access the GROM - treating each base as a unique 40k bank of GROM. (It's 40k, because the console GROMs 0,1,2 respond to /all/ bases, and so unless you want to force override them, they aren't included). So the normal access address is >9800, the next base would be >9804, then >9808, and so on until we run out of address space in the reserved memory. (All the various addresses are likewise incremented). The console itself scans the first 16 bases for GROM headers.

 

One nice thing about your concept is that you don't need to tie in the extra address lines, and in fact all that memory can live in a single base - so you could still have multiple bases of very large GROM. The address increment isn't really a huge deal - after changing bank you'd be well advised to set the GROM address again anyway.

 

I might steal the idea if there's no objection.

 

[wierd_w]

I really dont mind. Go right ahead.

 

Bear in mind that the original intent was to bank a supercart's SRAM, not to bank GROM chips, but it could be used for either.

Edited September 9, 2020 by wierd_w

[Omega-TI]

Comment:

This brief (so far) thread has been one of the most enjoyable ones for me to witness in quite a while.   I love it when an idea is not immediately discarded, gets some traction through discussion and morphs into something that may indeed come to fruition.  Forty years on, and the brilliant minds here are still keeping the hobby fresh. 

 

👍