32-bit Chip RAM detection

[BlankVector]

I'm trying to detect WinUAE 32-bit Chip RAM from EmuTOS. As I understand, it doesn't use AUTOCONFIG.
What is the proper way to detect 32-bit Chip RAM? Start at $10000000 until there is no more RAM?

And for my own curiosity:
- Is there any real-world Amiga hardware supporting such 32-bit Chip RAM?
- How does AmigaOS detect it?

[Thomas Richter]

Originally Posted by BlankVector

What is the proper way to detect 32-bit Chip RAM? Start at $10000000 until there is no more RAM?

There is no "proper way" as there is no such RAM in real hardware. There is no function for such RAM detection in the Os either.

Originally Posted by BlankVector

- Is there any real-world Amiga hardware supporting such 32-bit Chip RAM?

Nope.

Originally Posted by BlankVector

- How does AmigaOS detect it?

It doesn't.

[Toni Wilen]

It is simply a hack that enables larger than 8M Chip RAM. 32-bit in name means addressing capability, not data bus width.

UAE Boot ROM adds the RAM to the system (because AmigaOS don't have any direct support), there is no sane way to detect the RAM without it. Don't attempt any weird hacks, they will break in future versions. Better ignore it unless you really really really need >8M Chip RAM.

It is basically similar RAM that some accelerator boards have, like Blizzards, RAM in some non-autoconfig space (that can change depending on SIMM sizes etc..) that boot ROM adds. Finding the RAM requires hardware specific detection code.

[BlankVector]

Ah, OK. The UAE boot ROM, which knows where the 32-bit Chip RAM is located, registers itself that RAM to the OS by using system calls.
As EmuTOS does not call the UAE boot ROM, and does not provide the required AmigaOS system calls, that can't work.

Anyway, this doesn't matter. If I need big amounts of RAM, 1 GB of Z3 Fast should be enough

[BlankVector]

I found the "getchipmemsize" trap at offset 0xFF80 in the UAE Boot ROM. It reveals the location of WinUAE's 32-bit Chip RAM. I used it in EmuTOS, it works like charm.
WinUAE + EmuTOS provide more RAM than all Atari clones

[Toni Wilen]

Originally Posted by BlankVector

I found the "getchipmemsize" trap at offset 0xFF80 in the UAE Boot ROM. It reveals the location of WinUAE's 32-bit Chip RAM. I used it in EmuTOS, it works like charm.
WinUAE + EmuTOS provide more RAM than all Atari clones

If you use this trap using address $f0ff80, make sure to also support "new" boot rom type (full autoconfig, no hardwired location. ROM panel = 64k or 128k new), if autoconfig board 6502/1 is found, base+$48 has long word absolute address that points to start of boot rom (or zero if not available).

[BlankVector]

After spending a few hours...

Originally Posted by Toni Wilen

If you use this trap using address $f0ff80, make sure to also support "new" boot rom type (full autoconfig, no hardwired location. ROM panel = 64k or 128k new), if autoconfig board 6502/1 is found, base+$48 has long word absolute address that points to start of boot rom (or zero if not available).

Seen in expansion.cpp, function add_rtarea_pointer():

        if (aci->prefs->uaeboard > 1) {
            addr = aci->start + 0x10000;

For obscure reason, the address stored there is 64 KB farther


And after fixing that, when I call uaelib_demux function 86 to display debug info as usual, I just see "A-Trap A00E at 00EAFF60 -> 00FC5BE0"


So for now, I will just stick to hardcoded 0xf00000, that's enough for my needs.

[Toni Wilen]

eaff60 != ebff60.

I think you must have misunderstood, it is working as designed.

- Find the board
- Read long word from board+$48
- Value is base address of UAE boot ROM (replaces old $f00000, in your case it is $eb0000 but of course can change if there are other boards)

The rest works the same:

Add $ff60 to ROM base. (In your case it is $ebff60) This MUST be calculated, do not use hardcoded values. There is no guarantee it is base+64k in the future. Do not also assume it is always Z2 board.

$f00000 ROM is obsolete (and not very Amiga like), it will go away in the future.

[BlankVector]

(FYI I have reimplemented AUTOCONFIG in EmuTOS. This works fine, I will push that later to official sources).

I don't know where, but for sure there is confusion here.
I followed your algorithm, I understood well the first time.
And I can check the values by using the MEM1 tab of the WinUAE debugger.

In WinUAE configuration, I select:
Settings > Hardware > ROM > Board type: New UAE (128k, ROM, Direct)

In WinUAE debug log, I can see:

Card 02: 'UAE Boot ROM'
  d2.01.40.00.19.66.00.00.02.03.00.80.00.00.00.00
  MID 6502 (1966) PID 1 (01) SER 00000203
  Z2 0x00ea0000 0x00ea0000  128K ROM 0

Note the board adddress: 0x00ea0000.
MID and PID are the ones you told me.

I'm unsure why WinUAE displays "Card 02: 'UAE Boot ROM'", I would have expected "UAE Board" here... But this is not a problem

Then after AUTOCONFIG, WinUAE displays:
00E90000 64K/1 = 64K -- F32 UAE Board
00EA0000 64K/1 = 64K -- F32 UAE Boot ROM

Then EmuTOS finds the 6502/1 board at address 0x00E90000. As I understand, until now this is correct.

Then at 0x00E90048 I see the long value 0x00EB0000.

But at 0x00EB0000, there is nothing. WinUAE debugger displays stars. So there is a problem here, this value is invalid.

Then look at the WinUAE code I quoted:

        if (aci->prefs->uaeboard > 1) {
            addr = aci->start + 0x10000;

What is that 0x10000 for ??

I have a big suspicion of bug here, because if I subtract that strange 0x10000 value to 0x00EB0000 (the long value at offset 0x48), result is 0x00EA0000 and I *do* find the UAE Boot ROM there, with usual traps, etc.

As you see, I precisely followed your algorithm. But it doesn't give the right address.

[Toni Wilen]

It is wrong if 128k board is located at e90000. Autoconfig specs require boards in aligned addresses. 64k can be in any address, 128k can be only located at ea0000, ec0000 or ee0000 and so on.

This also causes interesting side-effect, any following 64k board can still take free e90000 64k slot even if ea0000 is already taken.

Z3 boards also have same alignment requirement.

[BlankVector]

Ah! I missed the fact that the first slot at 0x00e90000 wasn't itself properly aligned for all boards. I fixed that in EmuTOS and... now it works fine!

Many thanks for the hint, Toni