MiSTer FPGA Forum

The latest ao486 core release seems to have messed up disk access. Half the time, I am getting this error on boot:

FATAL: ata-detect: Failed to detect ATA device

And also half the time, when I attempt to start Windows 3.1, it will give an error: General error reading from C, abort, retry, fail. Selecting 'retry' always works and Windows is able to start, but it is kind of unnerving to be getting these messages.

I reverted to Release 20220326 and confirmed that the problems aren't there in that release. It's definitely something new in the September release causing it.

I just had the same issue today after updating, and this is the only thing I could find about it. So just in case I will leave this in here for the next one:

The solution was to Ctrl+Alt+Del within ao486 for it to work.

You should ensure you are not running preset at unstable speed option.
Could you reset configuration and try again?

You should then share a screenshot of actual values so the core author is more aware of why and when happened

I'm having issues too. Sometimes DOS struggles to read my 120gb eXoDOS VHD. Sometimes it's fine but lately it struggles to read it. When I try to view thew contents of the drive with the DIR command I see the list of files but then DOS freezes when it gets to the bottom of the list and attempts to print the available disk space information

sacredbanana wrote: ↑Sat Jan 21, 2023 3:12 pm

I'm having issues too. Sometimes DOS struggles to read my 120gb eXoDOS VHD. Sometimes it's fine but lately it struggles to read it. When I try to view thew contents of the drive with the DIR command I see the list of files but then DOS freezes when it gets to the bottom of the list and attempts to print the available disk space information

120 gb is a lot and will take a while for the DIR command to complete the first time it runs. The larger the disk the longer this takes. How long have you waited? You can use the FreeSP or FreeSPT util from here https://github.com/ChartreuseK/FREESP adding it to your autoexec.bat and it will fix the DIR command from trying to calculate your freespace at the end. I have not tested this on a FAT32 disk so report back if you have issues.

It is a lot but that's just how big eXoDOS is. I waited several minutes for DIR to complete before I gave up. Sometimes Total DOS Launcher opens up instantaneously but other times it says "Inspecting file cache at E:\GAMES" and that takes like 5 minutes. Thanks for your suggestion but it says it's for FAT16 but this partition is FAT32.

Btw thanks for your eXoDOSConverter tutorial in YouTube. Was very helpful. Although turns out it doesn't work without creating a stub partition first which the tutorial doesn't mention

maybe Smartdrv.exe? Make sure you have it loaded. I have an exodos 120GB disk around somewhere. It has been ages since I set that up but don't remember having these issues.

Might be worth running a chkdsk on that drive. The FAT may have been damaged.

Thanks I'll try smartdrv and report back.

As for chkdsk I already tried that by attaching the VHD in Windows 11. It reported no errors.

Interestingly enough this seemed to start having issues when I executed the eXoDOSTop300Updater script (since I have that pack too) which updated the shared boot VHD which both use. Perhaps coincidence but maybe not?

Smartdrv just seems to freeze

You are pushing it with a 120G volume. No 486 ever had that size disk, nor did DOS ever really anticipate it. I would split the collection into smaller drives.

I know I am pushing it, but it did used to work perfectly until a couple of days ago. I'm trying to figure out why it was working fine before but not anymore

The Top 300 script is only designed to update the Top 300 VHD that is like 20GB or so. The directory structure will be difference as we changed the ExoDOSConverter mid stream (prior to fixes it would create dynamic games folders and would be some what random) post fix it uses static entries from a database. I don't know why that would cause disk issues though and shouldn't have done anything to this as the vhd name would have been wrong so it should have failed.

The absolute limit for the VHD size 137GB but I had corruption up at that limit (hard to miss as all the directories will be gibirish)

It did update the boot VHD though which I also use for my large eXoDOS VHD. Still, I dont think that is the issue because if I boot Windows 98, that now struggles to browse the disk now (it used to work fine before). It's a real mystery.

sacredbanana wrote: ↑Sun Jan 22, 2023 2:52 pm

It did update the boot VHD though which I also use for my large eXoDOS VHD. Still, I dont think that is the issue because if I boot Windows 98, that now struggles to browse the disk now (it used to work fine before). It's a real mystery.

Oh that should be fine to update the boot one yeah.

adding SmartDrv cache is the only thing left I can think of. Maybe I REM'ed it out between versions of the boot disk for some reason and it needs to be put back.

you could diff the autoexec and config between the release version or the one you have. Also, you could go to one of my packs on archive.org where I attached the actual boot.vhd and just go grab that one real quick and test. I think it is attached to all the data series packs, like 1980-1989 etc.

There may be many things wrong with the volume now. Did you run a filesystem repair utility over it yet? If so, which one and from which OS?

sacredbanana wrote: ↑Sun Jan 22, 2023 8:31 am

Thanks I'll try smartdrv and report back.

As for chkdsk I already tried that by attaching the VHD in Windows 11. It reported no errors.

Interestingly enough this seemed to start having issues when I executed the eXoDOSTop300Updater script (since I have that pack too) which updated the shared boot VHD which both use. Perhaps coincidence but maybe not?

When I last ran the updater, it corrupted my virtual drive severely. The maker of the images insists that no such thing could happen, but it blew up very badly for me. Running a FAT-version of chkdsk complained bitterly about not having enough FAT entries, and the filesystem was so corrupt that I couldn't even unmount it from Linux. I had to actually reboot the entire server to clear out the loopback mount.

I should finally be able to work with it some more in a few days. AO486 drive images are absolutely glacial running over the network to a ZFS filesystem, so I'm getting a bigger card sometime today that should let me use local images instead.