People, people! This just isn't good enough.
AMOS Pro, and especially the AMOS Compiler, have to be correctly installed. It's not just a matter of copying files and chucking some assigns in:
- The editor config file has to be updated to add the compiler menu items into it.
- The interpreter config file has to be updated to tell AMOS where the APSystem directory is. With this info alone, AMOS does all those assigns for you!
- The compiler config file has to be updated.
- Important files have to be copied to the C:, LIBS: and FONTS: assigns.
The only problems with the original install disks is the reporting of available HDD space. There are two scenarios:
On a real Amiga, you'll need to install to a partition where the number_of_free_blocks multiplied by the block_size doesn't exceed an unsigned long. In numbers, that means a partition no larger than just under 4.3Gb for a block size of 512 bytes. 2.15Gb for a block size of 256 bytes, and so on.
If you're using WINUAE, the problem will only arise if you're using a directory as a 'soft' hard drive for your system drive, where your PC HDD may well be one or two terabytes or even more! To fix this follow these instructions:
- Add an *.hdf file of around 10 Mb to your installation.
- Using the *.adf images attached to this post in a zip, install AMOS Pro to that disk, NOT to your system disk. Then install the Compiler to that same *.hdf disk.
- You'll end up with a directory called AMOS_Pro on that drive. All the stuff for C:, LIBS: and FONTS: will end up on your system drive.
- Now copy the entire contents of that AMOS_Pro directory to a directory of the same name your system drive.
- You can now remove the *.hdf file as a drive.
- Before running AMOS, go into the AMOS_Pro/APSystem directory from workbench and find the Locate_APSystem icon and double-click it. This adds the necessary update to the interpreter config file.
- Job done! Works every time.
I'm currently putting together disk sets to do clean installs of both AMOS 2.0 and AMOS 2.1 beta without all this hassle. I hope I may be able to get those out before I have to go into hospital...
In the meantime, you may also be interested in a work around for the Dfree call that causes this problem. This will give free space in Mb for partitions up to a couple of terabytes (more or less depending on the block size you're using:
A5_BUFFER=$4F2
Screen Open 1,640,256,2,Hires
Palette $0,$EEE
Dir$="dh0:"
' Lazy way to get AMOS to do the dos call:
X=Dfree
A=Leek(Areg(5)+A5_BUFFER)
' The InfoData structure has to be longword aligned, so this
' matches what the Dfree call does to achieve that:
Add A,4
Ror.l 2,A
Rol.l 2,A : Rem A --> InfoData structure returned by Info() call
D_BLOCKS=Leek(A+12) : Rem Total Blocks
D_USED=Leek(A+16) : Rem Used Blocks
D_BSIZE=Leek(A+20) : Rem Block Size in Bytes
Locate 0,5
Print "Total Blocks: ";Hex$(D_BLOCKS,8),D_BLOCKS
Print " Used Blocks: ";Hex$(D_USED,8),D_USED
Print " Block Size: ";Hex$(D_BSIZE,8),D_BSIZE
D_DIV=$100000/D_BSIZE
D_FREE=(D_BLOCKS-D_USED)/D_DIV
Print Using " Mb Free: ###,###";D_FREE
Direct
Attached is a set of *.adf disk images of the original AMOS Pro and Compiler disks with correct names.