WhichAmiga with ACA accelerator support

[modrobert]

I modified Piru's WhichAmiga v1.3.3 assembler source (from aminet) to support ACA accelerators by "uncommenting" a conditional getmhz test routine, and then compiled it using 'vasm'.

Works with my ACA-1232 now on AmigaOS 3.1.

WhichAmiga 1.3.3 with getmhz check enabled to support ACA accelerators.
Written by Harry "Piru" Sintonen. Copyright © 1995-1999 PitPlane Productions.

Evaluating system...
Central Processing Unit: MC68030 33.4 MHz
    Floating Point Unit: not available
 Memory Management Unit: 68030mmu not active
   Custom graphics chip: AGA Lisa 4203 (rev 0)
  Custom animation chip: AGA PAL Alice 8374, rev 3-4
   Other custom chip(s): Paula 8364 (rev 0), Gayle (rev 13)
        Graphics system: Amiga AGA  display bandwidth: 4x
         Hardware Clock: clock found
 Max. Chipmem available: 2048 K
 Max. Fastmem available: 130048 K
       ROM chip version: 40.68 (Kickstart 3.1)
      Workbench version: 40.42 (Workbench 3.1)
       SetPatch version: 43.6

 Your computer is an Amiga 1200.

Before fix it showed '5.3 MHz' (slower than stock A500). I also tried to use the newer v1.3.25 Beta (WhichAmiga_beta.lha) but that just froze the A1200.

I compiled it on the A1200 like this:

vasm WhichAmiga.ASM -Fhunkexe -nosym -o whichamiga -m68020up -devpac -IDevpac:Include3.0/Include

Perhaps the support for old Amigas (Kickstart 1.1) is broken now, not sure, but had to use -m68020up since the code includes MMU and FPU opcodes, and I couldn't compile it with Devpac because that compiler seems to require FPU installed on the Amiga you do the compile on when enabling support for FPU under "options", so you can't support FPU users without having one installed it seems, hehe. First pass in Devpac ends in "Error: maths co-processor required at line 4790 in file WhichAmiga.ASM" (even with FPU enabled in compiler, also tried 68060, no luck).

EDIT: Confirmed working on 68000 and Kickstart 1.3 (thanks phx).

If you have time to test this compile on old Amiga with 1.2/1.3 or other ACA boards I would be happy to get your feedback. Hopefully it's not too broken.

[mfilos]

I always used WhichAmiga 1.3.25 which froze my A600 using an ACA630.
I found out that the only way to have WhichAmiga run just fine in my system was to enable MMU.

For example:
SYS:System/MuTools/MuLockLib >NIL:

Enabling MMU kinda screws up ACATune's way of recognizing the accelerator so another one declaration and we're set:
SYS:System/MuTools/MuSetCacheMode Address=$b8f000 SIZE=4000 WRITETHROUGH VALID NOCACHE >NIL:

I made a script with these 2 command, naming it StartMMU and running it at will.

Will give a spin on your version as well though.

Cheers

[modrobert]

Originally Posted by mfilos

I always used WhichAmiga 1.3.25 which froze my A600 using an ACA630.
I found out that the only way to have WhichAmiga run just fine in my system was to enable MMU.

For example:
SYS:System/MuTools/MuLockLib >NIL:

Enabling MMU kinda screws up ACATune's way of recognizing the accelerator so another one declaration and we're set:
SYS:System/MuTools/MuSetCacheMode Address=$b8f000 SIZE=4000 WRITETHROUGH VALID NOCACHE >NIL:

I made a script with these 2 command, naming it StartMMU and running it at will.

Will give a spin on your version as well though.

Cheers

Yes, I meant that WhichAmiga v1.3.25 (the newer beta) froze for me, missed a digit in the version number, edited the first post now.

Thanks for the MMU explanation and solution, been wondering why 'acatune' gives wrong info (some other board) when loading mmu.library resident in Startup-Seqeunce.

BTW: Is the 'acatune' source code available somewhere?

[phx]

Originally Posted by modrobert

vasm WhichAmiga.ASM -Fhunkexe -nosym -o whichamiga -m68020up -devpac -IDevpac:Include3.0/Include

Perhaps the support for old Amigas (Kickstart 1.1) is broken now, not sure, but had to use -m68020up since the code includes MMU and FPU opcodes,

Still works on 68000 and Kickstart 1.3.

The -m68020up is mostly harmless as long as you don't enable optimizations, which could generate instructions which only exist for 68020 or higher (e.g. TST label optimized to TST label(PC)). You specified -devpac compatibility, which has optimizations disabled by default.

I saw there are also some places marked with "** NO PC REL!" in the source. Here you would also run into problems with optimizations turned on. To avoid PC-optimization you can attach an ".l" extension to the label, which forces 32-bit absolute addressing mode.

couldn't compile it with Devpac because that compiler seems to require FPU installed on the Amiga you do the compile on when enabling support for FPU under "options"

Strange. I didn't know that. Perhaps the assembler uses the FPU directly, when parsing float constants in the source?

[modrobert]

Originally Posted by phx

Still works on 68000 and Kickstart 1.3.

The -m68020up is mostly harmless as long as you don't enable optimizations, which could generate instructions which only exist for 68020 or higher (e.g. TST label optimized to TST label(PC)). You specified -devpac compatibility, which has optimizations disabled by default.

I saw there are also some places marked with "** NO PC REL!" in the source. Here you would also run into problems with optimizations turned on. To avoid PC-optimization you can attach an ".l" extension to the label, which forces 32-bit absolute addressing mode.

Thanks for testing and feedback!

I have a question regarding 'vasm': If you compile using -Fvobj and then link manually using amigahunk file format, does that change Amiga backwards compatibility compared to -Fhunkexe?

Originally Posted by phx

Strange. I didn't know that. Perhaps the assembler uses the FPU directly, when parsing float constants in the source?

Yes, or maybe some obscure Devpac (genam) setting solves this, but I haven't found any that works. Perhaps the concept of "cross compile" wasn't even in their mindset back then, not even to support additional hardware like FPU within the same architecture.

I prefer 'vasm', it's great. However, in this case the source was originally developed with Devpac, so thought that it would be a good idea to try that first since the WhichAmiga code is pretty "hairy" by design to determine the hardware (as opposed to bad coding in general, hehe).

[phx]

Originally Posted by modrobert

I have a question regarding 'vasm': If you compile using -Fvobj and then link manually using amigahunk file format, does that change Amiga backwards compatibility compared to -Fhunkexe?

I guess you refer to linking the object file with vlink? Yes, that should work fine.

Only be careful with code- and data-sections, which end with a number of zero-words. vlink will remove trailing zero-words automatically and stores their size in the header to save space. This method, called "DataBss" sections, doesn't work correctly under Kickstart 1.x, because the Bss-part of the section is not cleared by LoadSeg().
EDIT: Forget this paragraph! The danger does not exist. Only when you tell vlink to merge data and bss sections in small-data mode (-sd option). It's long ago since I did serious work on the vlink source...

BTW, there is no reason to use VOBJ as object file format. Just create hunk format objects (-Fhunk) with vasm, so you stay compatible to other tools.

WhichAmiga code is pretty "hairy" by design to determine the hardware (as opposed to bad coding in general, hehe).

Indeed. With the changes mentioned in my last posting I got it to work with full optimization, but then the measured clock speed is wrong (too slow).

[modrobert]

Originally Posted by phx

I guess you refer to linking the object file with vlink? Yes, that should work fine.

BTW, there is no reason to use VOBJ as object file format. Just create hunk format objects (-Fhunk) with vasm, so you stay compatible to other tools.

Thanks again, good to know. I have some project ideas which will be faster to develop using both C and assembler.

[jurassicman]

Sorry for resurrecting this old post.

I've found the beta version and the aca version (on this thread) of whichamiga and on aminet there is still the old version.

Is there somewhere any new versions of this nice program?
Thanks in advance!

[kolla]

CD32 detection could be better too.