Cannot Load .BIN file from SD card in EasyProg

[LameLefty]

EasyProg is the utility used to flash .BIN and .CRT files to the various “slots” in the EasyFlash 3 cartridge. EasyProg itself is a .PRG file and may be loaded from either the EasyFlash cartridge or from an external serial device such as the Pi1541. When EasyProg is running from either loading method, the user may select any serial device attached to the C64, navigate the directory structure and selected .CRT and .BIN files to flash. When navigating the directory structure, the OLED display on the Pi1541 changes to reflect the navigation going on in EasyProg. However, once the file .BIN or .CRT file is selected, things go awry. .BIN files appear to read and flash correctly to the EasyFlash 3 slot, but upon resetting the cartridge, the menu entry from the newly-flashed kernal ROM is grayed-out and inaccessible. When trying to flash .CRT files, things don’t even get that far - the device starts to read the file and then EasyProg indicates that the .CRT lacks the proper cartridge header.

However, if one first creates an empty .D64 or .D81 disk image and then moves the same .BIN file to it, then mounts that disk image in the Pi1541 (to enable full drive emulation rather than SD2IEC functionality), that same .BIN will load and flash to the EasyFlash 3 cartridge perfectly.

The .CRT files I wish to flash are much larger than a standard disk image so I have not yet figured out an on-disk workaround. However, .CRT files may be loaded to the device via USB from a modern computer in conjunction with EasyProg on the Commodore. This is not supported for .BIN kernal image files.

Ideally these workarounds would not be necessary - both .BIN and .CRT files would read properly from the SD card file system of the Pi1541 via EasyProg and flash correctly to the EasyFlash 3 cartridge.

[penfold42]

The SD2IEC functionality in browse mode is known to be quite limited and is really just there to support FB64.

[LameLefty]

Certainly. However, that doesn’t mean it can’t be improved. Having said that, I’m posting this issue and the workaround in as many places as possible because when I ran into it, it took a very long time to figure out why flashing the file to the EasyFlash 3 wasn’t working despite EasyProg saying it was successful. So clearly the SD2IEC functionality responded to the read requests with 8K of data as expected, but it was obviously not the CORRECT 8K of data, so EasyProg had no way of knowing anything was wrong. So clearly despite the limited SD2IEC functionality, this APPEARS to work correctly and thus the failure mode is non-obvious, especially to someone new to the Pi1541 (as I am).

My googling for a solution took quite a bit of time and the solution was only revealed scattered across about 3 posts several days apart buried 59 - 60 pages deep in a single forum thread on Lemon64. I’ve let Jim Brain know of my issue and workaround so he can better advise EasyFlash 3 customers from his Retro Innovations store, and I’m “telling” GitHub in this issue so as Pi1541 adoption in the community continues, people will be able to find a workaround if they run into it.

[penfold42]

Btw, I suspect this issue is caused by the same thing that stops SEQ file reading and jiffydos @$

[lutzbellmann]

I can confirm that issue from @LameLefty . My workaround with Easyflash3 is to actually use my old SD2IEC device. Here, no D64 or D81 image is necessary to contain the CRT or BIN file. Easyprog can directly access that file in the structure. It would be really nice if this functionality could be improved.

[Squirrel61]

I can confirm the issue and the workaround of @lutzbellmann.

When using Easyprog, the C64 hangs when trying to access a file straight from the file structure, which is necessary for large files that don't fit in any disk image. It helps a little when I switch off the built-in fastloader of Easyprog. The C64 doesn't hang anymore when opening the file, but it is still not capable of reading it (an error is produced).

I expect that this is not the only situation where it is clear that the SD2IEC implementation of the Pi1541 is only partly working and is causing problems. It would be nice if it can be fixed some time in the future.

[penfold42]

The SD2IEC functionality in browse mode is known to be quite limited and is really just there to support FB64.

A fuller implementation would be a massive distraction from core emulator functionality like burst mode, 1571 and 1581 support.

The best option would be to convince the sd2iec authors to relive we their code in a way that supports inclusion in a GPLv3 licensed project like this.

[lutzbellmann]

@penfold42 : can't judge the degree of distraction. System hang-ups should be avoided though. If the functionality can not be made available, at least the files not being mountable images or directories should be hidden from being displayed or made unselectable. Anyway: for me this feature would really be the killer for the SD2IEC ;-)

[penfold42]

It’s not about the file type - it’s about the software that’s trying to load it and the methods it uses so the Pi1541 can’t hide the files

The author has documented the limitations: https://cbm-pi1541.firebaseapp.com/

“I was going to remove SD2IEC support but others have convinced me to leave it in. Be warned though; the bare minimum functionality was implemented and was initially only used for testing. Going forwards I hope others will implement the full functionality”

I got part of the way through adding SEQ style reads - maybe one day I’ll get time to look into it again cos it would probably fix this issue

[danihibari]

Hi guys, IT IS POSSIBLE, with a workaround. Just encapsulate kernals in a .d64 image or a .d81 image (for multiple files or freezers CARTS for example) and with the pi1541 mount the image. Now start Easyprog and point to the image and do the writing. IMPORTANT: in Easyprog, first, disable FASTLOAD from the Option menu. IT WORKS! For flashing 1 MEG CARTS i use windows via USB (so no problem).