snuci
Veteran Member
Interesting. Now that you have that, you can always connect the 5.25" and Gotek and make a real diskette via the Nabu from Gotek to floppy drive.
I am guessing the 5.25" image you are using is the same as this one? https://vintagecomputer.ca/files/Nabu/disk_images/NABU_5.25_DSDD_CPM_User_Boot.a2r
Any chance you have a Kryoflux? You could also try this one: https://vintagecomputer.ca/files/Nabu/disk_images/NABU_5.25_DSDD_CPM_User_BootKryoflux_RAW.zip
That would rule out image issues as I have used these, made the images, wrote them out and re-tested them.
Yes, that worked fine. The diskette I created boots and verifies. No hangs. However, when I do a flux image of that diskette on the Applesauce it's unable to read valid MFM data from a couple of the inner tracks. I did notice that the 5.25 images had two extra cylinders (4 tracks) on them - but those were not the ones with the read issues. Some timing oddness, perhaps?Interesting. Now that you have that, you can always connect the 5.25" and Gotek and make a real diskette via the Nabu from Gotek to floppy drive.
For whatever reason, all the 5.25" flux capture files have two extra tracks of garbage at the end. I believe this is responsible for some of the issues I've experienced. If I read the original HFE into the Applesauce application and write it back out with the extra tracks trimmed it boots just fine. I have prepared the 5.25" HFE, A2R and RAW images without the bogus tracks in case anyone else gets bit. Unfortunately (and, as usual) they are too large to upload here. I'll send them privately to @snuci and he is welcome to make them available to others.
This can be done but it takes a bit of effort, basically you first need to convert the flux/hfe to a sector image add the files with cpmtools. Then convert the sector image back to a kryoflux stream and copy the track 0 files from the original kryoflux stream into your converted stream. Now you can take that and convert it to hfe and it should have the correct data on track 0 to recognize the disk type.I thought I saw a posting from Larry Kraemer regarding proper cpmtools diskdef (?). That brings up a catch-22, though. Since cpmtools works only against sector data images, how can one use it to add files to an image that will then be properly recognized by the NABU?
This is pretty neat. Back when we were trying to figure out how the heck NABU disk images worked i had manually patched a few of sector based disk images to overwrite the default (osborne) DPB that was used if no out-of-band information was found and was able to get them working that way. But this is definitely a more automatic and nicer way to go about doing this. I always wondered why NABU didn't just store this in the boot sector like this to begin with. Perhaps it was felt that it would be harder to accidentally trash your disk's geometry info if it was stored out of band.Hi all --
I realize that NABU activity has died down a little, so this is a minor resurrection I was revisiting my NABU a while ago, having built the repro FDC (thank you all for that work!) and using a gotek, and the track 0 out-of-band DPB issue forcing the use of .hfe images was bugging me. So I very cleverly found (by accident) a complete legend of an individual in the UK who, after a little description of the issue, ran with it and built a complete patch script to allow the use of the native NABU CPM disk images as raw IMG files, simplifying getting stuff on and off them (eg using cpmtools).
Anyway, it works a treat! I've used it to adapt native 80-column images (obtained through the github tn_vdp project) so now I have true 80-column cpm on raw images booting locally. DIR has never looked so good lol.
He has posted the results of the investigation as well as the image patching script here:
https://github.com/simonowen/patch_cpm3