STE machine type differentation via _MCH cookie

[simonsunnyboy]

Considering the following from the tos.hyp (https://freemint.github.io/tos.hyp/en/b ... _2C_20_MCH):

3.7.2.603 Cookie, _MCH
Machine type

The upper WORD describes the computer family, the lower serves for finer distinctions.

High Low Type
0x0000 0x0000 Atari ST (260 ST,520 ST,1040 ST,Mega ST,...)
0x0000 0x4D34 Medusa T40 without SCSI
0x0001 0x0000 Atari STE (1040 STE, ST Book, STylus/STPad)
0x0001 0x0010 Mega STE
0x0001 0x0100 Sparrow (Falcon pre-production machine)
0x0002 0x0000 Atari TT or Hades
0x0002 0x4D34 Medusa T40 with SCSI
0x0003 0x0000 Atari-Falcon030
0x0004 0x0000 Milan
0x0005 0x0000 ARAnyM >=v0.8.5beta
The lower WORD serves for finer distinctions, and is defined only for the STE models at present. This can be:

0x001 = ST Book or STylus
0x002 = ST Book
0x003 = STylus
0x008 = STE with IDE hardware

If the value is -1, then it's a case of non-ST-compatible hardware. In that case all hardware accesses should be avoided.

What I want to achieve: differentiate between STE in 1040 case and Mega STE to detect if the Enhanced Joystick Ports are present to use Jagpads.

In the past I only checked for the cookie of 0x00010000 (or 0x00030000 for Falcon) which didn't lead to further bug reports.

I now wonder

a) if I need to check for the 0x00010008 (STE with IDE hardware) too? Is this value really present in TOS 1.6 and up as well as EmuTOS?

b) Do common IDE implementations affect this or is it detected and configured on the fly?

c) How would the value look for ST Book etc with IDE Interface (I am even not aware if this is actually physically possible)

I would like to avoid to install trap handlers to probe hardware ports if possible.

Thank you for a serious discussion!

[Arne]

Just checked on my 1040STE with IDE:





As you can see 2.06 knows about IDE by default while 1.62 (1.06) do not.

BTW: I find it strange that the ST-Book disguises itself as a STE. IIRC it does not have the 4096 colour palette, nor DMA sound nor enhanced joystick ports.

[czietz]

c) How would the value look for ST Book etc with IDE Interface (I am even not aware if this is actually physically possible)

The ST Book always has an IDE interface anyway: https://www.atarimuseum.de/nst.htm#str.

[czietz]

By the way, it's a coincidence of sorts that STEs with third-party IDE interface (Monster(bo) etc.) get a different _MCH cookie from TOS 2.06 and are therefore not recognized as STE anymore by some software. TOS source code makes it clear...

Code: Select all

	_MCH:
*		00000000 or nonexistent is ST or Mega ST.
*		00010000 	STe (none of the below variants)
*		    0001	STBOOK/STylus (.if STPAD)
*		    0008	STe/AT (if IDE bus exists)
*		    0010	Mega STe (if SCU exists)

... that Atari had planned for 0x0001_0008 to the cookie for the "STe/AT" (likely this machine: https://www.atari-forum.com/viewtopic.p ... 25#p311325), but chose the presence of the IDE bus to detect this "STe/AT".

[simonsunnyboy]

Thank you.

That reduces my question to: is 0x00010008 really a planned and sofar never used value?

[czietz]

That reduces my question to: is 0x00010008 really a planned and sofar never used value?

What do you mean by "never used"? As Arne has already shown to you, a STE with IDE interface does have _MCH = 0x00010008 under TOS 2.06.

[joska]

As with Arne's STE - the _MCH cookie in my 2.06 STE with IDE is 0x00010008.

So in your case you check that the upper word is 1 (STE) and bit 4 of the lower word is 0 to determine if this is an STE and not an MSTE.

[Arne]

I would like to avoid to install trap handlers to probe hardware ports if possible.

If I am not mistaken then Glue (ST) and GSTMCU (STE) always DTACK the address range $FFxxxx. So there shouldn't be a bus error when you probe the analog joystick ports at $FF92xx.

[simonsunnyboy]

As with Arne's STE - the _MCH cookie in my 2.06 STE with IDE is 0x00010008.

So in your case you check that the upper word is 1 (STE) and bit 4 of the lower word is 0 to determine if this is an STE and not an MSTE.

Sorry seems I mixed the screenshots up. Yes, Question answered.