A1200 ShapeShifter MacOS Emulator

[drwhy]

Hi !

I´m trying to setup ShapeShifter MacOS Emulator on my A1200
but when i start the Emul i got a error-message about
"incorrect MAC-ROM checksum".

I´ve tried the ROM which comes with SS v3.0b and a
Macintosh Quadra650 ROM, both give me the same error !

Help please

[Mad-Matt]

I don't recall a rom ever coming with shapeshifter.

You are spoilt for choice with systems roms from here:-
https://archive.org/details/mac_rom_...s_of_8-19-2011

[drwhy]

hmmm ...
Thank You for that !
But I have downloaded the archive and tested every rom including
"LC, LCII, Quadra, Performa & PowerBook" every time i got the message:
"Macintosh ROM seems to be corrupted, checksum incorrect. Do you
wish to continue anyway ?" (or something like that, sorry for my bad translation ;-))

When i click on ok, it ends up in a grey, blank screen with only Amigas mouse pointer.
Then i have to reset the Amiga.

by the way: i use ShapeShifter 3.11 is there a newer version ?

[emufan]

try the MacRomTest tool to verify the integrity of the roms in the big archive.
tested "06684214 - Quadra 630.ROM" this boots until i get the disk symbol with question mark (no boot disk)
I have no shapeshiter setup, so this all i can test atm.

do you have one of the prepemul /rsrvkick tools at the top of your startup-sequence?

cannot say for sure, but 3.11 was latest i think.

[zipper]

http://www.oldos.org/Mac/68kEmulator.html
has a quadra650.rom link

[Pat the Cat]

If MaxTransfer is set too high on A1200, large files like ROM images would be corrupted when copying them.

OK, ANY Amiga drive needs a sensible Max Transfer value, not just A1200. 0X0000FFFF is safest if you only have chip RAM. If you have ROM shadowed into 32 bit fast RAM you get more margin of error.

Have seen same issue on PC only networks and very large video files, so not purely an Amiga issue either.

[Toni Wilen]

Not again... MaxTransfer problem is A600/A1200/A4000 IDE _only_. It has nothing to do with hardware, it is purely driver problem. It also has nothing to do with memory type.

[Pat the Cat]

Originally Posted by Toni Wilen

Not again... MaxTransfer problem is A600/A1200/A4000 IDE _only_. It has nothing to do with hardware, it is purely driver problem. It also has nothing to do with memory type.

As I understand it, part of it stems from the unbuffered nature of the A600/A1200 IDE port.

Another factor is how much lag is allowable between the OS handling the drive data stream. Obviously if the OS is running in chip RAM only, there will be more lag as ht other parts of the system impede access to and from Gayle.

The reason for my thinking is the higher transfer rate (not value, but rate of data flow) when running an A1200 with a 32 bit shadowed ROM... or have I been imagining that all along?

[Daedalus]

Nope, you simply don't understand what MaxTransfer is. MaxTransfer specifies the maximum size of any data transfer carried out by the relevant driver. It doesn't have anything to do with the buffering of the port, or the memory used, or the speed of the transfer, or the lag, or any shadowing of any ROM, or a 16 or 32-bit data bus.

Normally a device driver will automatically take care of the maximum transfer possible by splitting large requests into smaller chunks that can be safely handled without corruption, but the scsi.device used on the A600, A1200 and A4000 doesn't do this, which causes corruption if any transfers are carried out that are larger than ~128KB (0x1FE00). Setting the MaxTransfer to that value or lower simply tells the driver to manually split larger transfers into multiple operations instead of one, thus avoiding corruption.

[Toni Wilen]

Driver does split it correctly but it also does something unnecessarily complex and instead of just simply calculate start block of next transfer using driver's own internal state variables, it reads last access position from drive's registers and adds 1.

This method was valid in ATA-1, since ATA-2+ it is only valid if last read or write failed -> next transfer (and all following if it is really long transfer) starts from same LBA/CHS position as first transfer..

[Pat the Cat]

Originally Posted by Daedalus

Nope, you simply don't understand what MaxTransfer is. MaxTransfer specifies the maximum size of any data transfer carried out by the relevant driver. It doesn't have anything to do with the buffering of the port, or the memory used, or the speed of the transfer, or the lag, or any shadowing of any ROM, or a 16 or 32-bit data bus.

Normally a device driver will automatically take care of the maximum transfer possible by splitting large requests into smaller chunks that can be safely handled without corruption, but the scsi.device used on the A600, A1200 and A4000 doesn't do this, which causes corruption if any transfers are carried out that are larger than ~128KB (0x1FE00). Setting the MaxTransfer to that value or lower simply tells the driver to manually split larger transfers into multiple operations instead5 of one, thus avoiding corruption.

So the MaxTransfer value (the setting, not the rate as I had already posted) can indeed mangle large files like ROM dumps, and if the OP sets a lower value of Max Transfer on the drive (as I have suggested) and recopies the files to the drive, that might resolve the issue.

If it was purely a software issue, you would think it would have been sorted after 25 years, and if you think it's just a software issue, feel free to rewrite scsi.device to fix it.

[Daedalus]

Originally Posted by Pat the Cat

So the MaxTransfer value (the setting, not the rate as I had already posted) can indeed mangle large files like ROM dumps, and if the OP sets a lower value of Max Transfer on the drive (as I have suggested) and recopies the files to the drive, that might resolve the issue.

The driver mangles the file, the MaxTransfer setting prevents the driver from reaching a state where the mangling can happen. The rate has nothing to do with it. While your suggestion of lowering the value was sound, your explanations for that suggestion were totally wrong.

If it was purely a software issue, you would think it would have been sorted after 25 years, and if you think it's just a software issue, feel free to rewrite scsi.device to fix it.

No need on both counts when there's a perfectly good, easy to implement and very well documented work-around (specifying a suitable MaxTransfer value). And there are already a number of replacement drivers and patches that people have already written that solve the issue, and most likely did a better job than I would too. No sense reinventing the wheel...

Originally Posted by Toni Wilen

Driver does split it correctly but it also does something unnecessarily complex and instead of just simply calculate start block of next transfer using driver's own internal state variables, it reads last access position from drive's registers and adds 1.

This method was valid in ATA-1, since ATA-2+ it is only valid if last read or write failed -> next transfer (and all following if it is really long transfer) starts from same LBA/CHS position as first transfer..

Indeed.

[Pat the Cat]

If setting Max Transfer to a lower level and recopying the files does not resolve the issue, what else could corrupt relatively large files on an Amiga hard disk?

[emufan]

Originally Posted by Pat the Cat

If setting Max Transfer to a lower level and recopying the files does not resolve the issue, what else could corrupt relatively large files on an Amiga hard disk?

thats what i thought too, but drwhy has to post some details of his setup.
maybe a network shared folder? or bad transfer over network, ftp in ascii mode, instead of binary transfer of the rom files.

drwhy, any details about your setup?

[drwhy]

Hi ! Thank You for answering !

Mine is: A1200 1D4, Phase 1230 IV 128MB, OS3.9, Colanto-ROM 3.X, 8GB CF-Card.

No network-connection on the Amiga, Data-Transer with 4GB CF-Card
or RS232 for smaller files (ROM-Archive was transferred with CF-Card).

First i´ve extracted the ROM-Archive on PC and thought this was the issue,
but meanwhile i tried extracting on Amiga and its still always the same.

I´ve tried MacRomTest & quadra650.rom, it says its OK, but ShapeShifter does not ?!?!

[ptyerman]

As has already been said, double check your MaxTransfer setting for all drives is set at 0x1FE00. If it is set greater than this it will cause corruption to files written to the drive.

[zipper]

I did a fast test on Amikit - installed Shapeshifter 3.11 and that quadra650.rom up there - Shapeshifter at least started without errors but my filedisk wasn't ok, must do some fixing. I have lost all my old installs with a HDD crash and partly when Amikit installed over an older install and wiped everything I installed earlier.

[zipper]

after a little tinkering MacOS 7.6.1 is working, so far 256 colors. Must find Cammy's utilities disks or something like next.

[nogginthenog]

Originally Posted by zipper

after a little tinkering MacOS 7.6.1 is working, so far 256 colors.

A tip for you. If you have an AGA Amiga with a MMU then install the MMU accelerated ShapeShifter video driver (sorry, I forget the name). It makes ShapeShifter *fly* in 256 colour mode.

[daxb]

Maybe yuo mean MuEVD.