EMUTos + AltRAM

[czietz]

Adding to my previous post: One can easily verify correct Alt-RAM detection (without having an Atari TT) with Hatari:

grab0019.png

grab0020.png

And here's a photo from back when I had by TT temporarily at 512 MiB TT-RAM:

emutos_512mb.jpg

I already pointed to EmuTOS's TT-RAM detection routine in my previous post. It goes through memory in 1 MiB steps and checks two things:
1. there is no bus error,
2. some test data can be written and read back.

If I had a PiStorm, I would check why tests apparently start to fail above 64 MiB. Perhaps there is some mirroring of memory?

[czietz]

If I had a PiStorm, I would check why tests apparently start to fail above 64 MiB. Perhaps there is some mirroring of memory?

To better explain what I mean: Purely as a hypothesis (I don't have a PiStorm and I wouldn't even know where to check) let's consider what might happen: EmuTOS checks for the 65th MiB of TT-RAM, which is located at 65+16 = 81 MiB. Now, the PiStorm's CPU emulator says "sorry, I can't handle that" because only 64 MiB of TT-RAM are mapped. If, however, this causes the request to be put onto the Atari's bus (which is only 24 bits), it will wrap around and look like an access to ST-RAM. Thus, the ST-RAM will "mirror" above the TT-RAM. This, obviously, causes the TT-RAM detection routine to fail to detect the correct amount.

Can you please make sure that directly above the mapped TT-RAM there is either a bus-error (preferred solution) or at least 1 MiB of memory that cannot be written to?

[dad664npc]

Many thanks for the feedback. So I have a bit of work then to find out what I've buggered up :)

[czietz]

I think I might have found something. Note though that this is my first look ever into the PiStorm/PiStorm-Atari codebase, so I might be wrong.

This function appears to handle byte-sized memory reads: https://github.com/gotaproblem/pistorm- ... tor.c#L652

However, if the read request cannot be handled internally (by platform_read_check), the function passes the request onto the bus, even if the high byte (A31-A24) of the address is not zero. Imho, this function should generate a bus-error instead. Or at least return 0, like the Amiga implementation https://github.com/captain-amygdala/pis ... tor.c#L945. The same thing applies to all other read and write functions.

(I can't explain, though, why this works for up to 32 MiB TT-RAM.)

[dad664npc]

Thanks for looking. Now resolved, not sure why this is needed - but hey-ho

if ( ( address & 0xFF000000 ) == 0xFF000000 )
address &= 0x00FFFFFF;

if (address & 0xFF000000)
return 0;

IMG_0111.jpg

[Cyprian]

Thanks for looking. Now resolved, not sure why this is needed - but hey-ho

if ( ( address & 0xFF000000 ) == 0xFF000000 )
address &= 0x00FFFFFF;

if (address & 0xFF000000)
return 0;


IMG_0111.jpg

CPU type isn't "68000"
Is it ok in your PiStorm case?

[dad664npc]

CPU type can be 68000 to 68040 on the PiStorm.
Are you asking if the PiStorm fits in an Atari ST or STe? That'll be a big fat NO :) But stormy has installed in an H5

[Cyprian]

CPU type can be 68000 to 68040 on the PiStorm.

ok

Are you asking if the PiStorm fits in an Atari ST or STe? That'll be a big fat NO :) But stormy has installed in an H5

no, just CPU type in PiSTorm

[thorsten.otto]

That was a physical hardware limitation of the 68000 chip. I don't think emulated 68000 need to have that limitation.

There are cases where that emulation is needed (Hatari for example has an option for it). For example, in TOS 1.04, the vector number is placed in the upper 8 bits for exceptions. And IIRC, early version of Tempus (a blazingly fast text editor) used those bits to store the length of text lines.

[Badwolf]

There are cases where that emulation is needed (Hatari for example has an option for it). For example, in TOS 1.04, the vector number is placed in the upper 8 bits for exceptions.

Wow. That's good to know. Thanks.

As an aside, ISTR early MacOS used the top 8 bits for something too.

BW