8GB drive works fine on FS_UAE but has problems on real A1200

[Quaxo76]

Hello,
So, I have a real A1200 with quite a few "upgrades", that has had a 4GB CF card installed for a long time; but I needed to go a bit bigger, so I created a 8GB image to use on FS_UAE. I installed WB from scratch on it, and configured it just like I wanted it. I upgraded the filesystem and drivers to recognize and use the large drive. It has a 512MB system partition, and a 7.5GB data partition. On FS_UAE, everything works just right; so now, after many months of tweaking, I decided to move it to the real Amiga.
Since I remembered that a 8GB image won't fit on a 8GB card, I bought a 16GB card, and flashed the image on it (obviously the second half of the card remains empty).
I installed the card on the real Amiga and... it does boot WB, but has major issues: most programs just crash, or show file transfer problems. Even Directory Opus crashes. But a few games, on the Data partition, do work.
I'm attaching a few pictures taken from the real Amiga, showing the system's configuration and some errors.
I'm honestly at a loss, I'm a bit "out of the loop" and I also forgot exactly what I did to prepre the image (I foolishly did not document all I did, thinking I would remember, but I don't).
Could anyone maybe help me troubleshoot / diagnose the problem?
The Amiga hardware is fine, since the 4GB card works perfectly.


Thank you in advance for any help,
Cristian

[Orionis5]

Can you provide detail on Amiga - kickstart and OS versions ?
CF interfaced used ?
After you transferred data to 16gb drive, did you test it back on WinUae ?

[thomas]

Sounds like the typical MaxTransfer symptoms.

[Quaxo76]

Originally Posted by Orionis5

Can you provide detail on Amiga - kickstart and OS versions ?
CF interfaced used ?
After you transferred data to 16gb drive, did you test it back on WinUae ?

Sorry, I forgot to add these details.
Kickstart v40.68 (read from SysInfo)

OS Scalos 39.222


I also have an Indivision VGA adapter, a Blizzard accelerator with a 68030 and 48MB of memory. FS_UAE has been configured with the same accelerator board and memory.



The card has been verified in two ways:

1) I re-read the card on the PC, making a new image file from it; and the md5 checksum of the original image, and of the new one, match perfectly;
2) I attached the new image from the CF card to FS_UAE, and it works.

[Quaxo76]

Originally Posted by Boing-Ball

Like Thomas as suggested. What are your partition settings?

I'm not sure what information you need, but HDInstTools, on the drive page, shows:

 Cylinders 1019; Blocks per track 63; Heads 255; Blocl size 512;
Drive size: 8,169,052 KBytes = 7,977 MBytes


File system:
DOSType: SFS\2; Version 1.84; Size 60,456; Name/type = Custom Filesystem


Partitions:
Partition 1 (Sys8G)
KBytes 538,112
Cylinders 67
Start cyl 2
End cyl 68
Reserved 2
Pre Alloc 0
File System: custom
DOSType: SFS\2
Mask 0x7FFFFFFE
MaxTransfer 0x00FFFFFF
BlockSize 512
Automount YES
Bootable YES
Priority 0
Bootblocks 0
Buffers 512


Partition 2 (DATA)
kBytes 7,630,848
Cylinders 950
Start cyl 69
End cyl 1018
Reserved 2
PreAlloc 0
FileSystem Custom
DosType SFS\2
Mask 0x7FFFFFFE
MaxTransfer 0x00FFFFFF
Block size 512
Automount YES
Bootable NO
Priority (grayed out)
Bootblocks (grayed out)
Buffers 512

Kickstart 3.0 appears to also being used. SCSI.device may also be a culprit here. Which version are you using?

The output of

version scsi.device

is

scsi.device 40.5

What settings did you use in the emulation environment? Did they truly match what the real Amiga is?

Actually I just double-checked and it's not completely exactly the same. Here's the output from the hardware A1200's showconfig command:

PROCESSOR: CPU 68030/68882fpu/68030mmu
CUSTOM CHIPS: AA PAL Alice (id=$0023), AA Lisa (id=$00F8)
VERS: Kickstart version 40.68, Exec version 40.10, Disk version 40.42

RAM: Node type $A, Attributes $5 (FAST), at $D000000-$FFFFFF (48.0 meg)
     Node type $A, Attributes $703 (CHIP), at $400-$1FFFFF (2.0 meg)
BOARDS:
  Board + ROM (HD?) (unidentified):   Prod=8512/11(%2140/$B) (@$EA0000 128K)

The same command from FS_UAE:

PROCESSOR: CPU 68030/68030mmu
CUSTOM CHIPS: AA PAL Alice (id=$0023), AA Lisa (id=$00F8)
VERS: Kickstart version 40.63, Exec version 40.10, Disk version 40.42
RAM:  Node type $A, Attributes $5 (FAST), at $68000000-$69FFFFFF (32.0 meg)
     Node type $A, Attributes $605 (FAST), at $200000-$9FFFFF (8.0 meg)
     Node type $A, Atributes $705 (FAST), at $C00000-$CFFFFF (1.0 meg)
     Node type $A, Attributes $703 (CHIP), at $400-$1FFFFF (2.0 meg)


BOARDS: 

    Board + ROM (HD?) (unidentified): Prod=8512/17($2140/$11) (@$EA0000 128K)
    RAM (unidentified):  Prod=2011/81 ($7DB/$51) (@$200000 8meg Mem)
    Board + ROM (HD?) (unidentified): Prod=2011/82($7DB/$52) (@$E90000 64K)
    Board (unidentified): Prod=2011/4 ($7DB/$4) (@$EF0000 64K)

So, the Kickstart at least is different, though i don't know if that would make a difference.
If needed I can burn new kickstart versions for my A1200, or maybe I could use the MapROM function of the Blizzard?


EDIT:
I tried copying the SCSI 43.45 device from the "Large HD" folder into the Devs folder, renaming to scsi.device, but upon reboot I would get stuck into a reboot/GURU loop.


Cristian

[thomas]

Your MaxTransfer setting is too high. Check out the sticky threads in the hardware section of EAB. There is one specifically about MaxTransfer and there is also a CF card FAQ which has a section about MaxTransfer.

Not related, but you cannot use SFS2 with version 1.84. You need version 1.2xx to get SFS2 support (don't remember exactly which, the latest will do). It works because the older version does not care about the DosType. But once you upgrade (or add another correctly configured drive to the system) the partition will become unreadable.

[Quaxo76]

Originally Posted by thomas

Your MaxTransfer setting is too high. Check out the sticky threads in the hardware section of EAB. There is one specifically about MaxTransfer and there is also a CF card FAQ which has a section about MaxTransfer.

You're right, that's the issue. Thank you. I will read those documents right now, I hope I can understand them.
Now I have modified the MaxTransfer on the A1200, I set it at 0x1FE00 and everything appears to be working, even the programs that I'm sure used to crash.
Can I trust data integrity on that card, or should I make that change on the virtual image and re-flash the CF?
I'm a bit confused though on what was happening: was it that every file read from a file longer than 130560 bytes ($1FE00) would fail? And the same with writes? Is that why all the system components worked, and also some games too, because those files were shorter?
I suppose any attempt to write a large file would leave a truncated file, possibly overflowing to some unintended disk area, possibly corrupting other data? I don't think I attempted to write anything, but I can't be sure, so maybe it's best to just play it safe and reflash it anyway.

Not related, but you cannot use SFS2 with version 1.84. You need version 1.2xx to get SFS2 support (don't remember exactly which, the latest will do). It works because the older version does not care about the DosType. But once you upgrade (or add another correctly configured drive to the system) the partition will become unreadable.

OK, I'm not sure I'm following you here. SFS2 is the Dos Type, right? So 1.84 is the version of what exactly, the disk controller? And can I update it to be safe, without having to re-partition or re-format the drive? Sorry but I haven't done these things in many years, and I forgot most of it...

Thank you again for the MaxTransfer tip, that already brought my Amiga up and running again, for now.


Cristian

[thomas]

Originally Posted by Quaxo76

Can I trust data integrity on that card, or should I make that change on the virtual image and re-flash the CF?

If corruption only happened during reading, then everything is fine.

Only if you attempted to write files larger than 128K, then these files were corrupted on disk and still are.

I'm a bit confused though on what was happening: was it that every file read from a file longer than 130560 bytes ($1FE00) would fail? And the same with writes? Is that why all the system components worked, and also some games too, because those files were shorter?

Yes, yes and yes.

I suppose any attempt to write a large file would leave a truncated file, possibly overflowing to some unintended disk area, possibly corrupting other data?

No, only the files being written are affected, no other data. The driver wrote the first 256 sectors and expected the device to move the offset to the 257th sector, which it didn't do. So the next sectors were written to the same place as the first 256 sectors. No other area of the disk was affected.

SFS2 is the Dos Type, right?

No. SFS2 is a fork of SFS with enhanced features. It supports partitions larger than 128GB and files larger than 2GB. It was made by Joerg Strohmayer after he took over the SFS code from John Hendrikx.

At a later time Joerg merged the code for SFS2 back into SFS so that it supports both. The selection is made by DosType. The original SFS dostype is SFS\0 a.k.a. 0x53465300. The dostype for SFS2 is SFS\2 a.k.a. 0x53465302.

So 1.84 is the version of what exactly, the disk controller?

No, it's the version of Smart File System. You should know, you installed it.

Version 1.84 is the latest version made by John Hendrikx. It of course only supports SFS, not SFS2.

But you use the DosType for SFS2 with it anyway.

Now if you would upgrade the code of SFS to a version which supports SFS2, all your SFS partitions would become unreadable because they are not SFS2.

And can I update it to be safe, without having to re-partition or re-format the drive?

Yes, but you have to do it all at once. The DosType is the connector between file system and partition. You have to delete and re-add SFS with the correct DosType SFS\0 and at the same time change the DosType of all partitions to SFS\0. Then you can save changes and all should be fine.

If you make a mistake, you can correct it without data loss. But the mistaken partition will be unaccessible until the mistake is corrected. (Which might be a challenge if it is the boot partition )

[Quaxo76]

Originally Posted by thomas

No, it's the version of Smart File System. You should know, you installed it.

Right, sorry, it's that I prepared this image years ago, and didn't document exactly what I did, and now I forgot the details, and I can't find the tutorial or whatever that I followed. I like to experiment but I'm a little bit out of my depths here.

Version 1.84 is the latest version made by John Hendrikx. It of course only supports SFS, not SFS2.

But you use the DosType for SFS2 with it anyway.

Now if you would upgrade the code of SFS to a version which supports SFS2, all your SFS partitions would become unreadable because they are not SFS2.

So SFS is the "driver" that I installed, but I somehow "declared" the wrong type when partitioning it with HDInstTool or similar?

Yes, but you have to do it all at once. The DosType is the connector between file system and partition. You have to delete and re-add SFS with the correct DosType SFS\0 and at the same time change the DosType of all partitions to SFS\0. Then you can save changes and all should be fine.

If you make a mistake, you can correct it without data loss. But the mistaken partition will be unaccessible until the mistake is corrected. (Which might be a challenge if it is the boot partition )

OK, making mistakes does not scare me, because at this point I'm still working on the virtual image, and I keep a "snapshot" backup copy in a safe place, so it's very easy to start again if I mess it up.
So, to change the DosType of the partitions, I just use the partitioning software, right? By going to the partition details, leaving "File System" as "Custom", and manually typing SFS\0 in the DosType field?
But to "delete and re-add SFS" as you say, what should I do:
HDInstTools -> FileSystem -> Delete what is there now (which is SFS2 1.84) and add the new one (where to download it? I find lots of different versions floating around the net), and after doing this, change the DosType as described before?


Thanks again, this is being fun and every single successful step is highly satisfying...
And by the way, this time I'm logging what I'm doing, for future reference...


Cristian

EDIT: I tried, and it appears to have worked. I deleted SFS 1.84 and installed SFS 1.277; it wanted to use DOS\3 but I manually entered SFS\0; then on the partition details pages, I manually changed DosType to SFS\0 for both system and data partitions, and wrote changes to disk, and rebooted... it appears to have worked, upon reboot the SFS version reported is 1.277 and the partitions appear to be SFS\0. Does this mean it was successful?

[thomas]

Originally Posted by Quaxo76

EDIT: I tried, and it appears to have worked. I deleted SFS 1.84 and installed SFS 1.277; it wanted to use DOS\3 but I manually entered SFS\0; then on the partition details pages, I manually changed DosType to SFS\0 for both system and data partitions, and wrote changes to disk, and rebooted... it appears to have worked, upon reboot the SFS version reported is 1.277 and the partitions appear to be SFS\0. Does this mean it was successful?

Yes, that's perfect.

[Quaxo76]

Thank you so much again.
Now I wonder if you could help me with a problem that just popped out: after confirming that eveything is readable on the virtual image, I flashed it to the CF card to use on the real Amiga.
It boots, Workbench works perfectly, but the second (large) partition isn't visible on the desktop. HDInstTools sees it, recognizes the right size, right name, automount is checked, DosType is SFS\0, maxtransfer is 0x1FE00. It just doesn't show up on the desktop.
If I open the shell and type DATA: to change to it, I get a "not enough memory available" error, which is unrealistic since I have 2MB chip and 48MB fast ram. And by the way, FS_UAE is configured with the same amount of Ram...

EDIT: checking with Check4GB, the first partition reports:
Name Sys8g; Size 525M; Device scsi; Unit 0; Ver 40.12; Type SFS0; Ver 1.277; >4GB no; Check ok
The second partition (not accessible):
Name DATA; Size 7451M; Device scsi; Unit 0; Ver 40.12; Type SFS0; Ver 1.277; >4GB yes; Check * S