Minimig core crushes Workbench 3.1 Install Disk

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create empty hardfile and mount it
2. Boot MiST from Workbench 3.1 (Install) Disk
3. Partition hard drive with HDToolbox
4. Reboot the virtual Amiga after partitioning
5. Amiga throws checksum error at around block 885 of Workbench Install Disk

What is the expected output? What do you see instead?
Simulated Amiga reboots fine and doesn't throw an error on Workbench Disk 1. I 
tested the same empty hard file and the same ADFs on the latest WinUAE - no 
problems at all.

What version of the product are you using? On what operating system?
Latest Firmware and core
Kickstart v3.1 r40.63
Workbench 3.1 (tested with Commodore and ESCOM disk sets)
HDF created by latest WinUAE and a zeroed file

Please provide any additional information below.
I attached the working ADFs and the ADFs after using them in MiST. Maybe 
someone might find out what went wrong. My SD-Card is working, I checked it 
using h2testw. Saving on floppy images generally works, I could save and load a 
game on it's save disk.

Original issue reported on code.google.com by LSerraM...@gmail.com on 17 Apr 2015 at 5:36

Attachments:

• [Workbench v3.1 rev 40.42 (ESCOM)(Install)[after using in MiST].adf](https://storage.googleapis.com/google-code-attachments/mist-board/issue-32/comment-0/Workbench v3.1 rev 40.42 %28ESCOM%29%28Install%29[after using in MiST].adf)

[GoogleCodeExporter]

Addition to "What is the expected output? What do you see instead?"

What I see: After the forced reboot after partitioning and booting from the 
Workbench Install Disk again, I get an error message regarding checksum errors 
in Blocks 882-890. The Disk boots fine, but it's directory is empty. The 
partitions in the hard file can be formatted, no problem on that side. I 
checked the exact same disk images on WinUAE doing the exact same steps, even 
using the same labes for Disk manufacturer etc. The error does not show up on 
WinUAE.

Original comment by LSerraM...@gmail.com on 17 Apr 2015 at 5:45

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

It seems that the MiST is somewhat unreliable when writing to the disks. My 
Cloanto images worked first, but after copying a few files to the image, it 
started to throw checksum errors again (block 1100 and up).

I tested with another SD card from a differend brand, same issue.

Original comment by LSerraM...@gmail.com on 17 Apr 2015 at 9:05

[GoogleCodeExporter]

I could recreate this problem on my MiST. Also did get the CRC Problems after 
using this ESCOM Install 3.1 Disk. After pressing Cancel some times the MiST 
did freeze and after an additinal reset the MiST blinks red and the Filesystem 
of the SD-Card is totally corrupted :( On the PC the SD seems then to be 
unformated.

Original comment by guido.le...@gmail.com on 17 Apr 2015 at 4:59

Attachments:

• WB31_Install_CRC_Block_882.jpg

[GoogleCodeExporter]

Somewhat good news: I tried to copy the floppy image using Xcopy via the 
BAMCOPY+ method. According to DMS-Workshop, both files have the same CRC32 - so 
the writing engine is not generally broken.

However, still no clue why it seems that the MiST overwrites some parts of the 
disk instead of stopping when the disk is full. 

It also seems that MiST is not that accurate in the emulation of the floppy 
disk speed. I tested the MiST with the "Ami..Alignment System" test disk and 
get an average 320RPM instead of the 300RPM the drive should have according to 
Wikipedia. WinUAE averages at 303-305RPM. Read and write speeds also differ: 

MiST: 6631 bytes/s write, 19944 bytes/s read
WinUAE: 4922 bytes/s write, 13900 bytes/s read

MiST and WinUAE use the same configuration and run on the same Kickstart 
versions. Of course I set WinUAE to highest accuracy and disabled the drive 
turbo in MiST. I'm emulating a PAL OCS A500.

I know that WinUAE is not a proper way to get reference measurements for 
hardware specific stuff, but I think we can see that there's quite a difference 
between the emulator and MiST.

Original comment by LSerraM...@gmail.com on 19 Apr 2015 at 8:02

[GoogleCodeExporter]

Bug also appears on minimig AGA beta core.

Original comment by LSerraM...@gmail.com on 20 Apr 2015 at 5:11

[GoogleCodeExporter]

Hi, any updates?

Original comment by LSerraM...@gmail.com on 23 May 2015 at 7:33

[GoogleCodeExporter]

Can't reproduce this bug.

Make sure you are following this steps:

- create a new, empty file and copy it to sd card
- in the OSD settings -> hard disk settings, set master to hardfile (disk img), 
select your disk image, AND disable the slave (must read 'Disabled')
- apply changes and reboot as instructed by OSD
- insert your workbench install disk
- start HDToolbox
- make sure only ONE device is seen, otherwise you did something wrong
- make sure to use Change Drive Type -> Define New -> Read Configuration and 
save before continuing
- partition your drive as you wish
- reboot
- install Workbench

If you follow this steps, everything works OK. You probably either used wrong 
disk geometry (didn't use 'Change Drive Type' and 'Read Configuration') or you 
tried to install on the whole SD card (which I believe is the default option 
for slave, which, like I said, should be disabled!)

Original comment by rok.kra...@gmail.com on 28 May 2015 at 10:32

[GoogleCodeExporter]

Also, as is recommended anyway for any Amiga, use fast format option.

Original comment by rok.kra...@gmail.com on 28 May 2015 at 10:37

[GoogleCodeExporter]

Another thing:

I hope you are aware that minimig, like any real Amiga with IDE drives, needs 
to have MaxTransfer set to 0x1fe00, otherwise you will have problems.

HDToolBox -> Partition Drive -> Advanced Options -> Change -> MaxTranfer and 
set it to 0x1fe00 for every partition (and confirm by pressing Enter key after 
entering the number)

Original comment by rok.kra...@gmail.com on 28 May 2015 at 10:47

[GoogleCodeExporter]

Original comment by rok.kra...@gmail.com on 28 May 2015 at 7:41

[GoogleCodeExporter]

I followed all steps you mentioned.

The problems don't occur on the emulated Hard Drive, but on the Workbench 
Install Floppy Disk *itself*. The Floppy Disk is corrupted after partitioning, 
I think exactly at the moment HDToolbox writes the new hard disk type on the 
floppy.

Original comment by LSerraM...@gmail.com on 9 Jun 2015 at 8:52

[GoogleCodeExporter]

I'm sorry, I can't reproduce this.

Please check all steps mentioned here, together with using fast format and 
setting the Maxtransfer to 0x1fe00.

The only thing that I know that could cause this is if you accidentally 
installed on the whole sd card, instead of into a hdf disk image, or using a 
wrong geometry for the disk.

Can you attach your disk image here - one after formatting and one after trying 
to install workbench?

Original comment by rok.kra...@gmail.com on 10 Jun 2015 at 7:09

[GoogleCodeExporter]

Hello,

I attached the floppy images I used for the installation before and after the 
partitioning process. The "original" image is the one before partitioning, the 
image labeled "after using in MiST" is the one that "crunshes" during the 
partitioning progress. Try to boot from that floppy image, you will get a 
checksum error on the floppy disk. I'll attach the HDF later.

The floppy image that crashes on the MiST works flawlessly on WinUAE.

Have you checked the speed of the emulated floppy drive I mentioned above? The 
speed seems to be a bit to fast compared to a real drive or a drive emulated by 
winuae.

I will check the whole thing again with the very latest firmware and core.

Best regards
Lothar

Original comment by LSerraM...@gmail.com on 11 Jun 2015 at 4:32

[GoogleCodeExporter]

Yes, I used your floppy images when testing this. I didn't have the same 
problem as you, other than the second floppy reporting checksum error.

The floppy speed might be off a little bit, but I don't think that is 
problematic, unless we come across some software that actually doesn't work 
because of the floppy speed. Not very likely though, at least for normal ADFs, 
which is the only floppy image currently supported by minimig.

There were no changes to floppy / hard disk handling in minimig lately, I'd 
even say the code that handles floppies and harddisks is the same as used on 
the original minimig, and I know of no reports of this kind on any other 
minimig variants.

Original comment by rok.kra...@gmail.com on 11 Jun 2015 at 8:37

[GoogleCodeExporter]

https://www.youtube.com/watch?v=jjECSltd4c8&feature=youtu.be

This is a short and shaky video summary of issue #32 at the MiST bugtracker. 

You can see the MiST "destroying" the Workbench ADF while partitioning a 200MB 
hard file configured as "Master". 

I suspect that there is something wrong while writing the new device type back 
to the floppy image. No problems at all when performing the same steps on 
WinUAE. You can also reproduce the bug using the floppy images distributed and 
sold by Cloanto, but you have to fill up the Cloanto floppy image with random 
files to about 99%. I suspect that the floppy emulation in the Minimig core has 
problems recognizing when the floppy disk is full and then overwriting some of 
the files.

I need to find someone with an original Minimig to verify this bug. No changes 
if I use the "old" Minimig core or the newer one with AGA support.

I attached a 7z archive containing the empty hard file I used to perform this 
test. Obviously, I cannot attach the Cloanto image due to copyright reasons.

Original comment by LSerraM...@gmail.com on 17 Jun 2015 at 6:39

[GoogleCodeExporter]

I'm sorry, I still can't reproduce this bug.

I tried it again, even recorded a video, but I get no corruption of the SD 
card, the floppy image or the harddisk image.

I have an original minimig, I will try it there also over the weekend.

See here and look if I did anything different:

https://www.youtube.com/watch?v=ThCpeKefQic

Original comment by rok.kra...@gmail.com on 17 Jun 2015 at 8:00

[GoogleCodeExporter]

Thanks for testing.

This is so weird... Only difference I notice is that I renamed the Device from 
ADH0 to DH0. And I think you used the "save changes" function one time more 
than I did. Also, the device list was EMPTY when I recorded the video.

Can you copy the files from the floppy image to the ram disk to see if the 
corruption occurred somewhere in another file?

Which brand and model is your SD card?

I have no clue what to do.

Original comment by LSerraM...@gmail.com on 18 Jun 2015 at 2:39

[GoogleCodeExporter]

I didn't use the Save Changes function, only saved on request when it was 
necessary, not manually before the actual partitioning step.

Is it possible that the Floppy turbo is somehow affecting this? 

Original comment by LSerraM...@gmail.com on 18 Jun 2015 at 2:47

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I don't think it's a core or a hardware problem anymore, because then, more 
users would report such bugs.

I'll test again with another different SD card, maybe with a smaller size and 
report back.

Original comment by LSerraM...@gmail.com on 9 Jul 2015 at 3:01

[GoogleCodeExporter]

Some users are reporting similar problems, but in those cases the problem seems 
to be with the particular SD card they are using, so maybe switching the SD 
card (possibly to a smaller one) could fix this.

Oh, I tested this on the original minimig board, no problems there for me 
either.

Original comment by rok.kra...@gmail.com on 9 Jul 2015 at 8:28