GAMECART, a hidden register in the STE

[czietz]

Hello,

while looking at the address decoding in the STE GSTMCU ASIC schematic that I found a while ago [1], I noticed an undocumented register at $FF9000 (byte access). Only the LSB is used here, for a function called GAMECART. Writing a '1' to this register will remap the cartridge address range to $D80000 - $DFFFFF. I have confirmed on my 1040STE that this really works!

Usually, as you might know, the cartridge port uses addresses $FA0000 - $FBFFFF, where $FAxxxx is decoded to select signal ROM4 and $FBxxxx is decoded to ROM3. With the GAMECART bit set, $D80000 - $DBFFFF will map to ROM4 and $DC0000 - $DFFFFF to ROM3. Access to $FA0000 to $FBFFFF will then cause a bus error. Unfortunately this expanded address range (512 kB instead of 128 kB) cannot be used without HW mod, because only address lines up to A15 are present at the cartridge port, only allowing one to directly address 2*64 kB.

Yet, this is a curious find that to my knowledge hasn't been documented before. The name suggests that Atari might have been thinking about using the STE hardware (incl. GSTMCU) as base for a cartridge based gaming system.

[1] Read the full story: http://www.chzsoft.de/asic-web/

[Cyprian]

awesome finding

[Greenious]

Truly impressive!

[Frank B]

Now that's seriously awesome

[MiggyMog]

Cool stuff!

[AtariZoll]

Interesting discovery. But for me, sadly, it is just another proof that something was wrong in Atari in those years (when STE was developed).
I mean, who will even thinking seriously about doing some 512K cartridge when there are not all necessary lines present on connector.
+ 512K is still not good enough.
Worse, it conflicts with 14MB RAM address space - yes, unsupported by factory HW, but they could just place it to area $E80000 $EFFFFF . Still 512K space for TOS.
As it is easy to be smart after battle is finished, I take my chance :
Cart port with some 4MB address space - yes, in 'expanded RAM' area - because who needs both at once. For instance $800000-$BFFFFF range. Doing wider connector, with added needed extra lines at one side - and there should be write support too, of course. In way, that older cartridges can still be used and placed without problem. What means that cartridges with expanded size should have notch at end of old pins area, and after that new pins.

[czietz]

Keep in mind that the GSTMCU has many more chip select lines for ROM. Most of them are left unconnected in the STE. The complete mapping is:

D00000 - D3FFFF: ROM6
D40000 - D7FFFF: ROM5
D80000 - DBFFFF: ROM4, if GameCart bit is set, otherwise used for FAxxxx
DC0000 - DFFFFF: ROM3, if GameCart bit is set, otherwise used for FBxxxx
E00000 - E3FFFF: ROM2, used for TOS ROM in the STE
E40000 - E7FFFF: ROM1
E80000 - EBFFFF: ROM0

So if Atari wanted to use the GSTMCU in a cartridge based system (like a game console, not the STE), they could easily have had 1,75 MiB address space for ROMs.

[1st1]

I think, don't imagine that as an STE. Like Chistian wrote in the german forum, imagine more an STE Gaming System, similar like XE-GS.

It would not need:
- DMA and FDD controller#
- Yamaha sound and parallel port
- 6850 for Midi and Keyboard/Mouse/Joystick
- full TOS

It would be
- 68000-8
- 1-4 MB RAM
- GSTMCU (including MMU, STE-Shifter, Blitter)
- STE DMA Sound
- STE Joysticks
- Some starter-ROM to initialize the hardware, 16 kB or so might be enough
- Cardridge port up to 1,75 MB, maybe that cardridge port could include all necessary signals to insert a STE mode cardridge which adds support for all abobe listet which is not needed for gaming console.

The outside case design might be similar to XE-GS or C64GS. Imagine also how tiny the ST-Book mainboard is, this one even could be more tiny.

[czietz]

- GSTMCU (including MMU, STE-Shifter, Blitter)

You're confusing things here, I'm afraid. The GSTMCU does not include Shifter or Blitter. The Blitter was later merged with the GSTMCU into a chip codenamed Combo. The Shifter (called GST Shifter) is always separate.

[1st1]

Sorry if I am wrong, I am far away from my books and so, 12 hours by plane... And it's already quite late and still hot here... But I think basically you know what I mean.

What I think, what would be interesting, is if these ROM5/6 signals could be used in sensefull way for us, to extend the hardware. This is already a full adress decoding hardware which is there. Compare Commodore 264 series.

(There was a planned 364 machine with voice output. That voice chip was controlled by a single chip select signal from TED, no additional external adress decoding was required. So as this was never realized, but the chip select signal in TED was already there, peoples used that chip select to simple add additiuonal CIA/VIA/PIA chips into C16, C116, +4 for IO control of external hardware, beside existing userport. I have such a modified C16 with additional 6820 IO chip.)

Maybe these signals could be used to directly adress additional IDE, SCSI, LAN, USB, ... chip?

[Maeke]

- GSTMCU (including MMU, STE-Shifter, Blitter)

You're confusing things here, I'm afraid. The GSTMCU does not include Shifter or Blitter. The Blitter was later merged with the GSTMCU into a chip codenamed Combo. The Shifter (called GST Shifter) is always separate.

In the ste indead, but i think here he is describing the unreleased Panther.

[czietz]

In the ste indead, but i think here he is describing the unreleased Panther.

But the Panther wouldn't have used the GSTMCU anyway, so it doesn't explain why the GSTMCU has this GAMECART register.
Also, the Panther still would have had a separate Shifter (called Linebuffer in the schematic), while the functionality of Glue & MCU would have been inside the Object Processor.

[czietz]

Maybe these signals could be used to directly adress additional IDE, SCSI, LAN, USB, ... chip?

Note that these are ROM chipselects. They will only be asserted during a read access, not during a write, just like for the regular cartridge port.

[1st1]

Ok, that's a point. But there are some tricks to write while reading, see many existing omport cardridges like scanner, midi interfaces, etc. ...

[AtariZoll]

Ok, that's a point. But there are some tricks to write while reading, see many existing omport cardridges like scanner, midi interfaces, etc. ...

Yes, there are tricks, but only because HW designers were forced on it. Myself designed EPROM programmer for cart port somewhere in 1988, and of course writing went in special way. Much later did fastest IDE adapter for STE, on card port, but that needed really tricky way in HW and in SW too.
Such things usually mean that it is not compatible with anything other attached on port. Much better is when there is WR signal. Especially in case of some Atari ST(E) what missing CPU bus expansion port.

[krupkaj]

If not Panther what about mysterious Mirai?

[Greenious]

Ok, that's a point. But there are some tricks to write while reading, see many existing omport cardridges like scanner, midi interfaces, etc. ...

Yes, but since you need to get inside the computer and solder to use these extra rom select lines, you can just aswell solder a few extra lines and do a proper solution that doesn't need tricks to work. It's just bad engineering to build something based on a flawed feature if you don't have to or have a really good reason to do so.

The point with the cartridgeport is that you can add things without soldering, (always appreciated by the end user), so it makes sense and worth the effort to use these tricks in a cartridge.

Anyway, it's still a really cool find, which may come useful for something in the future, but right now I consider it a curiousity rather than something useful.

[czietz]

I also noticed that this register is mentioned in TT MCU Functional Description, with a setting called "game mode", so it should be present in the TT as well: https://archive.org/stream/TT_MCU_rev_B ... 3/mode/2up



And since the TT has the same restricted number of address lines on the cartridge port, its still not really useful. I wonder why it was carried over to TT at all. Surely Atari would not have planned game cartridge support for the TT.

[1st1]

But maybe a TT/68030 based gamingconsole for VGA monitor?

[Frank B]

Maybe TOS upgrades on a cart?

[arf]

But maybe a TT/68030 based gamingconsole for VGA monitor?

When the TT was designed? 68030-based game console in 1989? Quite expensive …

[1st1]

Maybe they expected the price falling with next generation CPU (68040) for 030.

[shoggoth]

... or, it's just left over "nice to have" stuff. Not that uncommon.

[czietz]

I also noticed that this register is mentioned in TT MCU Functional Description, with a setting called "game mode", so it should be present in the TT as well

BTW: In the meantime it has been confirmed that said register indeed exists in the TT and that it behaves just like in the STE. Not that it would be any more useful on the TT; so this is like something Atari didn't bother enough to remove.

[BlankVector]

Incredible find