Questions about cartridges

[brain]

On GROM bases and the cartridge port, you have to look at what addresses are scanned or GROM content at power-up, not the theoretical number of available bases. The 99/4A only scans the first 16 bases, so anything beyond that isn't going to show up on power-up.

:-) I don't want to start a major debate. I took your word "available" to be "addressable", not "scannable by the power up code". And, I agree that only 16 are usable by the startup code, but I posit that the rest are usable at the cart port, just not as power up GROMs

 

Cartridges from TI with more than 5 GROMs were never produced (even as prototypes).

Good to know

 

Only one PEB card was ever produced that used GROMs--the p-Code card.

I read about it. Quite the card.

 

The 99/8 also had a lot of GROMs in it--I think it was a total of 16 of them in two GROM bases (I'd have to look inside one of my 99/8s to be sure that it was only 16 of them).

 

The GSIM was a GRAM device from TI that they used to test code before committing it to silicon, somewhat fondly referred to as the silver pizza box. There are less than 20 of them in circulation (I have one that is functional as a GRAM device and one that was modified to make it into a test version of the PLATO cartridge using ROMs). The TI GRAM card from the TI labs at Almelo, Holland (four examples survive) was the next iteration of the GSIM. The design was then further updated to create the Mechatronic GRAM Karte sometime after TI pulled out of the market.

I'll try to find some pics online. It sounds like an awesome item.

 

Jim

[+Ksarul]

Here's a link to pictures of the Almelo card.

[Tursi]

Which means, if I understand the GROM correctly, putting GROMs at alternate base addresses would have been problematic if someone wanted to read an address, as the internal GROMs see all 98xx accesses, while fully decoded GROMs would only see a fraction of them. An address read of a GROM at 9804 would cause data bus contention, as I think all GROMs respond to a read address command. In the above a read address at 9804 base would bring the 9804 cart GROM online *AND* the 9800 base console GROMs online, but with different values for bits 0 and 1.

 

Of course, it is no worse than a data read at GROM address >0000 to >5fff with an external GROM responding to those addresses, but I wonder if the 16 bases were just a vestige of early development efforts, partially cost reduced out of the console due to the lack of full decoding on the console GROMs, or if TI truly was OK with the design, and simply assume no one would read an address from a GROM.

 

The console interpreter is /constantly/ reading address from the GROMs, pretty much every subroutine call. And since console GROMs see all bases, and since, as you surmised, all GROMs respond to a read-address request, if you implement chips on the GROM bus that don't track the same address as the console GROMs you are asking for bus contention. If you aren't running GPL from your GROM devices you might be more flexible, but there's no advantage to increasing the complexity that I can see...

 

To be clear, the console GROMs respond to /all/ activity on the GROM bus. They see every read, they see every write, and this is how they keep their address counters in sync. The only distinction is that during a read data access, only the GROM matching the top three address bits actually puts data on the bus.

 

According to Thierry Nouspikel, up to 256 bases should work, BTW, but anything you want in the TI menu needs to be in the first 16. There are no other restrictions I'm aware of.

 

 

 

(I mean, I understood it was an outgrowth of your MPD project, but not that it was primarily for new software development).

 

Sort of the other way... MPD was the first use of the tech. (Well, actually the very first was my Linux interface cart, which used it to run a dumb terminal and used the AVR's serial port to talk to an embedded Linux board in a cart. ). UberGROM just came out first because I'd been sitting on it for so long and mentioned to our hardware folks that I had it working.

[brain]

And since console GROMs see all bases, and since, as you surmised, all GROMs respond to a read-address request, if you implement chips on the GROM bus that don't track the same address as the console GROMs you are asking for bus contention.

I agree. Since putting a TI GROM at a different base address would have created such a conflict, I can see an unwritten "rule" that states: All GROM implementations at all base addresses on 98xx *MUST* share the same counter. Since a TI based GROM IC could not have done that (they were not as sophisticated as your AVR code), the rule implies that different base addresses on the TI cart port were not supported (during the original lifecycle of the platform).

 

Sort of the other way... MPD was the first use of the tech. (Well, actually the very first was my Linux interface cart, which used it to run a dumb terminal and used the AVR's serial port to talk to an embedded Linux board in a cart. ). UberGROM just came out first because I'd been sitting on it for so long and mentioned to our hardware folks that I had it working.

Why have not released it yet? I saw the demo. Looks nice.

 

My interest is in the HW side of things. I guess I need to find a SW person to help me with my cart idea, as my ability to write TMS code is non existent. I did, though, lay out a PCB for a test I need to send off to the fab.

 

Jim

 

 

[Tursi]

I agree. Since putting a TI GROM at a different base address would have created such a conflict, I can see an unwritten "rule" that states: All GROM implementations at all base addresses on 98xx *MUST* share the same counter. Since a TI based GROM IC could not have done that (they were not as sophisticated as your AVR code), the rule implies that different base addresses on the TI cart port were not supported (during the original lifecycle of the platform).

 

Why have not released it yet? I saw the demo. Looks nice.

 

My interest is in the HW side of things. I guess I need to find a SW person to help me with my cart idea, as my ability to write TMS code is non existent. I did, though, lay out a PCB for a test I need to send off to the fab.

 

I suspect that the multiple bases was a deleted feature... if they hadn't left it in the console ROMs we probably wouldn't have thought of doing it. (Much like the 99/4 apparently released with console support for an analog joystick that never existed - MESS supports it.) As such it was never formally documented and as noted, TI themselves never used it.

 

I haven't finished MPD mostly because of other projects. Nobody's really pushing for it (or anything), and I have to keep fighting back feature creep every time I think about it. I am pleased with where it's at but I need to get the other personalities done. I do kind of still want one myself.

[+Ksarul]

I suspect more that multiple GROM bases were a feature that TI had reserved for internal use, as I don't think the feature would have survived all the way into the 99/8 code base if they didn't see some use for it. They reduced the number of bases scanned at the cartridge port--but from an electrical power consumption standpoint, the 20 GROM chips in four GROM bases scanned by the 99/8 would have already drawn more power than the cartridge port provided. . .so the limitation to four GROM bases there makes a bit of sense.

 

One does wonder what they were thinking to allow so many with the /4A. Thinking about it, the CEC 9914 devices for the sideport did use multiple GROM bases, so there was at least one TI device that actively used the feature out there. I now have the two Acadiel had, and so far as I've seen, they may have been the only ones to escape TI control.