• Please review our updated Terms and Rules here

The Official Nabu PC Floppy Disk Controller thread

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.

I think the file that I used was this one: https://vintagecomputer.ca/files/Nabu/disk_images/NABU_5.25_DSDD_CPM_User_Boot.hfe.

I wonder if there are some subtle differences between AS and the Kyroflux?

EDIT: Actually, it may have been the image in this archive: https://vintagecomputer.ca/files/Nabu/disk_images/NABUPC_Gotek_FlashFloppy_USB.zip
 
Last edited:
Once I quantify this a bit further I'll send working and non-working A2R files to John Morris and see if he can find any critical differences.
 
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.
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?
 
Anything is possible, but I tried three different units. Need to go back to square one and collect evidence methodically. One thing I need to check on the bench is the oscillator frequency and waveform on the FDC board.
 
Well, I went back to square one and re-checked all my assumptions. Turns out that two of the three floppy drives I connected to the NABU were off-speed and/or out of alignment. I finally found an ALPS 360K HH drive that booted the 525 'user' A2R from vintagecomputer.ca. This still doesn't explain why the corresponding HFE failed to work on my Gotek, so I'll go back over that next. Things are operational now so I'm a much happier camper.
 
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.
 
Looks like all the 3.5 images have bogus inner tracks as well. Not sure why it fails to cause the same problem, but it's incorrect on its face. If you watch the 5.25" drive during a successful boot there is a seek to the innermost tracks and an attempted step past that point. I suspect the BIOS is probing to see if the disk is > 40 tracks.
 
Another observation: The 'NABU_LEO2.hfe' image does appear to boot, but if you look at it under Applesauce flux analyzer there's something really off with the geometry. Looks almost like it was captured at double-speed (?).
 
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.

Thanks fror the files. I originally created many of these images before I knew the geometry of the drives and my Kryoflux, I think, defaults to 42 or 82 tracks when capturing RAW images. In soe cases, I may have used a 1.2MB drive but I thought I had removed all of those images. I didn't go back to change anything else as I didn't have any issues (or I eventually got these images to work). The NABU_LEO2.hfe was likely one of my original RAW to HFE conversions that didn't work.

I have replace the images I have up with yours and moved my originals to the "backup directory". The files are now here: https://vintagecomputer.ca/files/Nabu/disk_images/

Note, I removed the "_Fixed" part of the filename as there may be links to these files so these filenames should continue to work.

Thanks again for your efforts. If you've played with 22disk (or anyone else for that matter), I worked on but don't think I have proper 5.25" DSDD or 3.5" DSDD settings yet. Perhaps because I was working with my "funky" images. These would be useful if anyone has these settings.
 
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?
 
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 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 don't recall if it was @ldkraemer or @Chuck(G) but the 5.25" SSDD config was determined. I tried some of the other configs @ldkraemer came up with but I could not get them to work for other disk types.

I have had no issues working with the 5.25" SSDD on 22disk. You can copy files back and forth to a physical Nabu floppy disk and they just work. I don't believe it touches track 0 at all.
 
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
 
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
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.
 
Back
Top