24bit Addressing

[Seiya]

just a curiosity to know if change something in compatibility or performance with 68000 emulation with 24bit addressing false or true. is it better emulation with it enabled or not change nothing if i set disabled?

[Samurai_Crow]

AmigaBasic stuffs 8 bit variables in the most significant byte of pointers. It won't run on anything with 32 bit addressing.

[a/b]

Originally Posted by Samurai_Crow

AmigaBasic stuffs 8 bit variables in the most significant byte of pointers. It won't run on anything with 32 bit addressing.

Hah, I really didn't know that.
Another brilliant idea by everyone's favorite m$... Who needs more than 640kb for anything, let alone measly 512kb.

[Thorham]

Originally Posted by a/b

Another brilliant idea by everyone's favorite m$... Who needs more than 640kb for anything, let alone measly 512kb.

Just like Commodore with it's stupid 31 bit Amiga OS pointers, because who needs more than 2GB

[jotd]

some games deliberately or mistakingly use the most signficant byte in jump tables (Xenon 2). With 32 bit mode it crashes.

Masking the MSB has some overhead, though. I remember removing this masking from a musashi fork and gained 5% CPU performance

[Seiya]

ok, thank you.

[Thomas Richter]

Originally Posted by Samurai_Crow

AmigaBasic stuffs 8 bit variables in the most significant byte of pointers. It won't run on anything with 32 bit addressing.

This was inherited from the MS Basic port to MacOs. Back then, MacOs used the topmost 8 bits of each pointer for its own memory management, to indicate the state of a handle. MS ported its Basic to Mac, and used the same idea. Then, they took the MacOs port, and ported it and its memory management to Amiga.

[pipper]

Can the MMU be used to basically emulate 24bit addressing?

[Samurai_Crow]

Originally Posted by pipper

Can the MMU be used to basically emulate 24bit addressing?

You'd have to duplicate the same address space 256 times in memory. I don't think conventional MMUs can do that.

[SpaceAce]

Originally Posted by Thomas Richter

This was inherited from the MS Basic port to MacOs. Back then, MacOs used the topmost 8 bits of each pointer for its own memory management, to indicate the state of a handle. MS ported its Basic to Mac, and used the same idea. Then, they took the MacOs port, and ported it and its memory management to Amiga.

Oh, i remember it well. LOTS of old 24 bit Mac software used to crash when Apple introduced 32bit MacOs.

[Thomas Richter]

Originally Posted by Samurai_Crow

You'd have to duplicate the same address space 256 times in memory. I don't think conventional MMUs can do that.

Yes, of course they can. The problem is only that the 24 bit address space is rather tiny, i.e. maximum of 8MB fast RAM.

[BastyCDGS]

Hi Thomas!

Originally Posted by Thomas Richter

Yes, of course they can. The problem is only that the 24 bit address space is rather tiny, i.e. maximum of 8MB fast RAM.

Is there an application on Aminet or similar which does this? It would be useful for me for using GFABasic on my emulated 32-bit OS3.9 machine.

[Thomas Richter]

No, but there is example code on Aminet how to program the MMU, see MuManual.lha. The problem is not so much reprogrammig the MMU. The problem is that if you have 32bit Mem in your system, many Os data structures are beyond the 24-bit boundary. If you would just reprogram the MMU, you wouldn't be able to reach these structures anymore, so you cannot do this at run time. You would have to do that very early during the bootstrap process, and that is the hairy part.

Anyhow. If your target is GFABasic, then the good news is that GFABasic is 32-bit clean, so there are no such problems that would require MMU tricks. The bad news is that GFABasic has a lot of *other* problems all around, such as self-modifying code, and other bad programming practise. I recall that it used the screen buffer as temporary storage for its "PRINT USING" statement, just to name one. You should be able to get GFABasic into a "somewhat working" stage with your average degrader tools - but hands off this software in general.

Back then, I wasted a lot of time writing letters of bug reports to GFA, most of them remained unaddressed. On the bright side, I have now a huge collection of GFABasic disk versions. One buggier than the other...

[mark_k]

Originally Posted by BastyCDGS

Is there an application on Aminet or similar which does this? It would be useful for me for using GFABasic on my emulated 32-bit OS3.9 machine.

I think SetCPU can be used for that. Just make sure your system does not have any RAM outside the lowest 16MB address space.

[BastyCDGS]

Thank you very much for your reply, Thomas!

Originally Posted by Thomas Richter

No, but there is example code on Aminet how to program the MMU, see MuManual.lha. The problem is not so much reprogrammig the MMU. The problem is that if you have 32bit Mem in your system, many Os data structures are beyond the 24-bit boundary. If you would just reprogram the MMU, you wouldn't be able to reach these structures anymore, so you cannot do this at run time. You would have to do that very early during the bootstrap process, and that is the hairy part.

Idea: ColdCapture vector which gives 24-bit (Zorro II) fast mem highest priority. Basically 24BitFastMemFirst. Does this put everything in 24-bit range?

Anyhow. If your target is GFABasic, then the good news is that GFABasic is 32-bit clean, so there are no such problems that would require MMU tricks.

It has been quite a long time when I ran MonAm on GFABasic, but if my memory does not fail on that, it clearly uses upper 8 bits of pointers for data, so there is a problem with 32-bit memory. I also vaguely remember trying 68EC020 vs. 68020 in WinUAE: First works, second crashes GFA badly.

Maybe you are mixing this with compiled GFABasic programs, which indeed work fine with 32-bit memory (and OS3.9 BTW, if you take care of certain things)?

My current solution is using an 68EC020 with OS1.3 for developing with GFABasic. But that is quite slow, so I want to use JIT...

The bad news is that GFABasic has a lot of *other* problems all around, such as self-modifying code, and other bad programming practise. I recall that it used the screen buffer as temporary storage for its "PRINT USING" statement, just to name one. You should be able to get GFABasic into a "somewhat working" stage with your average degrader tools - but hands off this software in general.

Yeah, there are some quirks I remember very clearly. One thing is that SETCOLOR i|,col& doesn't work correctly on OS3.0+, you have to use SETCOLOR i|,r|,g|,b| instead, otherwise you get wrong colors.

[Thomas Richter]

Originally Posted by BastyCDGS

Idea: ColdCapture vector which gives 24-bit (Zorro II) fast mem highest priority. Basically 24BitFastMemFirst. Does this put everything in 24-bit range?

Not necessarily. What board-specific logic does remains open. In worst case, you are left with chip mem only.

Originally Posted by BastyCDGS

Maybe you are mixing this with compiled GFABasic programs, which indeed work fine with 32-bit memory (and OS3.9 BTW, if you take care of certain things)?

No, certainly not. GFABasic is broken, but not in this regard. At least not the 3.5 release series. It still starts here, though it has other problems.

[BastyCDGS]

Hi Thomas!

No, certainly not. GFABasic is broken, but not in this regard. At least not the 3.5 release series. It still starts here, though it has other problems.

I just rechecked this with my OS1.3 config. My game written in GFABasic runs when using 68EC020, but as soon as I switch to 68020 (32-bit), it just hangs. Tried this multiple times.

How do you explain this if it is not an 32-bit issue?

EDIT: Is there a way to convert GFABasic listings to BlitzBasic or C?

BTW: I am using GFABasic 3.52D.