• Please review our updated Terms and Rules here

Bad disk image?

Very interesting. Thanks for looking more deeply into it @GeoffB17 While I focused on NABUPER1.IMD, NABUPER2.IMD is very similar. It is also a bootable disk as I get the same results when booting and no errors. If it was not bootable, I would get an on-screen error. I do have two CP/M diskettes coming from @LeoBinkowski hopefully late this week but if you have time, it might be worth checking out NABUPER2.IMD as well and soo if you see similar results.
 
I just compared the DPB's, and I believe you have a couple typo's in the Updated version.

Updated Version I downloaded from a previous posting attachment.
00000F00 XX XX 28 00 03 07 00 C2 00 3F 00 C0 00 10 00 01
00000F10 00 03 07 00 00 02 03 04 01 01 04 03 02 F3 C5 D5

28 00 03 07 00 C0 00 3F 00 C0 00 00 10 01
00 02 03 00 00 XX XX
The last two bytes I've highlighted are probably correct according to your updated posting.

Please Double check the DPB bytes.

Larry
So i think the embedded DPB is also not quite right. That first C0 should be the size of the disk in 1024 byte blocks excluding the the reserved tracks. This is a 40 track disk with 1 reserved track and 5 1024 byte sectors per track. So ((5*1024*39)/1024) - 1 = 194 (C2), C0 would come out to be only 38.6 tracks long. As for the next bytes those are the checksum vector size and according to the cpm3 manual are calculated as (DRM/4)+1, since the DRM here is 63 (3F), that indeed equals 0x10, but this is a 16 bit value so instead of 00 10 it should be 10 00 I think. I've actually tried the original version of both anyways and it made no difference as far as I can see.

The last two bytes do make a differnce if they are not 03 07 we end up trying to read sectors that don't exist on the disk since it thinks the sector size is 512 instead of 1024.
 
I patched the DPB on NABUPER2.IMD and yeah it gets the same error after reading the 15 sectors containing CPM3.SYS.
 
I made my nabu-exp sd adapter emulate the floppy and i get the same results bootsectors load and runs the goes to load the other sectors and dies.
 
snuci,

I've done the same thing regarding the PER2 disk.

With a quick look, I see some similar oddities here as well.

The numbers are the file offset in the image file

In file 1 see the block ending 47FF which ends with GG. The next bytes 4800 go EASE 4.3 ... which has the start cut off.
Then at the end of the block which ends at 48FF, the last bit is NABU REL but the start of the next block from 4900 is something else. Seems to me that the real code should have 48FF continue with 4800.

Something similar in PER2, see the transition between blocks at 5FFF -> 6000 and 63FF -> 6400

In both of these cases, the visible problem is on one of the images, but not the other.

Of course, there could be other problems, the examples quoted are visible because they happen at the point of readable text.

Geoff
 
Thank you @GeoffB17. I think we are getting close to declaring we can't work with these disk images and either it's a disk image problem (we need a good original diskette) or it's a firmware problem.

I say this because I cannot format a diskette in the NABU, read and write it out to another floppy with ImageDisk and still have the disk be read as a NABU diskette. It will always show that it's an Osborne disk. The disk image, when checked is only E5s through the whole diskette image. In fact, my B: drive is temperamental in the NABU but will always read diskettes. When formatting a floppy in that drive, it will sometimes show as a NABU diskette and sometimes it shows as an Osborne disk. This is very strange behavior. It does not do this with my A: drive as this always formats NABU identified diskettes. I can swap the drive and the issue follows the B: drive. Further to this, I've even removed my A: drive and used it to image a disk with ImageDisk, write it to another floppy with the same drive and read it on the NABU with the same drive and it shows up as an Osborne diskette. I can't make any sense of this.

Anyway, there are two possibilities. 1. I get the CP/M diskettes from Leo and they are good (they are on their way already) or 2. There is another firmware that works with the NABU RetroNet/Network adapter simulator) software. Leo sent one of his NABU PCs with a floppy controller to someone and I have asked for a copy of that firmware.

Let's hope one of these two are a final solution to being able to boot up CP/M from a NABU CP/M Plus diskette.
 
Yes, this is really wierd. I'm not sure what scenario has done this. The disks APPEAR to be readable, but logically they are not valid.

Something like this? The disks were created on one machine, and were OK then. They were passed to someone else, who created the images, but the second machine was not using correct disk parameters, but not too far out, so disks seemed to read OK, or this second user did not check that the disk they had were reading correctly - anyway, images were created on this second machine. data now appears mixed up.

I assume that all the tracks on the disk are similarly mixed up, but NOT to the level of complete 1k sectors/alloc blocks, seems to go below that level (to 128 byte sectors ?). If no other solution (i.e. the disks on the way to you) might be worth trying to unravel the data on a track-by-track / sector-by-sector basis. May be able to find enough tracks with enough bits of text in to give enough clues? No worse than a jigsaw puzzle?

Note, do not need to recover everything on the disk. Need the system - NABU - stuff only, the rest will be CP/M3 generic and can be replaced easily.

Geoff
 
So just to simplify it ,when you make a disk with the nabu it is fine , but if you archive and restore it with imd it becomes bad. so if the original disks were archived with imd then they are bad.
is this correct,
 
Has anyone dumped a disk with a flux level reader to see if the physical sectors change encoding or length?
There is an issue with imd not being capable of representing tracks with mixed encodings
 
I have copied all 5 unique NABU ROMs I have and sent them to Santo. Hopefully he can put them somewhere you can all download for analysis. The package contains 6, but that's because 2 appear the same.

I leave them in your capable hands, people.
 
I have copied all 5 unique NABU ROMs I have and sent them to Santo. Hopefully he can put them somewhere you can all download for analysis. The package contains 6, but that's because 2 appear the same.

I leave them in your capable hands, people.

Thank you Leo. They are available here: https://vintagecomputer.ca/files/Nabu/firmware/ I renamed them slightly to follow the naming convention. Your number 5 was blank. You might want to make a copy of another to replace that one.

Note: With Version 29 (Leo 1) I can now see the boot menu for the floppy AND run the NABU Network adapter and NABU RetroNET software. This, I believe is the latest and probably the one to use.

Has anyone dumped a disk with a flux level reader to see if the physical sectors change encoding or length?
There is an issue with imd not being capable of representing tracks with mixed encodings

With Leo's new firmware, I went through a number of tests.
1. I still see the same issue with ImageDisk where a copy of an imaged NABU diskette comes up as an Osborne diskette on the NABU.
2. I can flux image with the Applesauce but I don't think you can still write yet?
3. I used Applesauce to create and write and imaged NABU diskette. Same issue as 1.
4. Kryoflux WORKS! but I cannot work with the files to modify the image.

I sort of knew Kryoflux would work. I could pull out a GraseWeazle too but it will have the same effect as 4.

Next was to try to convert the Kryoflux image with the HxC2001 software to IMD and then back to Kryoflux and see if I can successfully write?

The goal is to modify a NABU diskette and write a boot track and retain the NABU format Maybe I can fudge something. More testing is needed.

I also have diskettes coming from Leo so there is hope on another front.

Thank you again Leo.
 
Sounds liek there might be multiple issues with the disk images.
Thank you Leo. They are available here: https://vintagecomputer.ca/files/Nabu/firmware/ I renamed them slightly to follow the naming convention. Your number 5 was blank. You might want to make a copy of another to replace that one.

Note: With Version 29 (Leo 1) I can now see the boot menu for the floppy AND run the NABU Network adapter and NABU RetroNET software. This, I believe is the latest and probably the one to use.



With Leo's new firmware, I went through a number of tests.
1. I still see the same issue with ImageDisk where a copy of an imaged NABU diskette comes up as an Osborne diskette on the NABU.
2. I can flux image with the Applesauce but I don't think you can still write yet?
3. I used Applesauce to create and write and imaged NABU diskette. Same issue as 1.
4. Kryoflux WORKS! but I cannot work with the files to modify the image.

I sort of knew Kryoflux would work. I could pull out a GraseWeazle too but it will have the same effect as 4.

Next was to try to convert the Kryoflux image with the HxC2001 software to IMD and then back to Kryoflux and see if I can successfully write?

The goal is to modify a NABU diskette and write a boot track and retain the NABU format Maybe I can fudge something. More testing is needed.

I also have diskettes coming from Leo so there is hope on another front.

Thank you again Leo.
@snuci
I'm curious what if you image it with kryoflux. and then convert that to an IMD and write that back to the disk, does that work or not? What if you go kryoflux stream to IMD to kryoflux stream?
 
@snuci
I'm curious what if you image it with kryoflux. and then convert that to an IMD and write that back to the disk, does that work or not? What if you go kryoflux stream to IMD to kryoflux stream?

Those are the exact scenarios I will be trying using the HxC2001 software. If there are other utilities, let me know. If you'd like a try, you can download my Kryoflux image here: https://vintagecomputer.ca/files/Nabu/disk_images/NABU_CPMfiles_NoBoot_Kryoflux.zip

This disk is a NABU formatted diskette with the CP/M files from NABUPER1.IMD but no boot track.
 
Those are the exact scenarios I will be trying using the HxC2001 software. If there are other utilities, let me know. If you'd like a try, you can download my Kryoflux image here: https://vintagecomputer.ca/files/Nabu/disk_images/NABU_CPMfiles_NoBoot_Kryoflux.zip

This disk is a NABU formatted diskette with the CP/M files from NABUPER1.IMD but no boot track.
So a quick convert to imd from your flux stream has it showing as an osborne disk with no files under mame.

The new roms are interesting though, the two 4k ones actually support not just floppy booting, but hard drive booting as well.

The one labeled CPM, might be a bad dump though, it does not seem to be be runable z80 code from what I could tell, nor are they any ascii strings in it at all. So i'm not sure what the deal with it is.
 
The Osborne disk behavior is what I am trying to fix. Even though the NABU thinks it's an Osborne disk, the files are all still there. If you save a file to that floppy via the NABU, it will put the directory for that one file in a different location than the NABU disk directory is. I should try to take a NABU disk, image it with ImageDisk, convert it to Kryoflux and then write it with the Kryoflux and see if that works. It might help prove if the problem is imaging the disk or writing it out (or both).
 
I've downloaded the Streamed *.RAW files, and tried to process them under Ver 2.20 DTC software.
That didn't go very well, so I've installed Version 3.0 DTC Software.

I used the floppy parameters associated with this CP/M definition, assuming the floppy was a
5.25" Floppy spinning at 300 RPM with 40 Tracks of Data on one side.

Code:
#cpmtools definition
# NAB1  Nabu PC - SSDD 5.25" 48 tpi - 1024 x 5
diskdef nab1
  seclen 1024
  tracks 40
  sectrk 5
  blocksize 1024
  maxdir 96
  skew 2
  boottrk 1
  os 3
end

I used the uploaded *.RAW files to playback the streamed the data, and create a *.IMG file named NABU.img


larry@debian:~/Downloads/kryoflux/kryoflux_3.00_linux/dtc/x86_64$ dtc -r5 -f./NABU/*.raw -i0 -fNABU.img -i4 -s0 -e79 -g0 -k1 -n+5 -z3 -m1

But, the floppy read should have been only 40 tracks, versus 80.

$ dtc -r5 -f./NABU/*.raw -i0 -fNABU.img -i4 -s0 -e39 -g0 -k1 -n+5 -z3 -m1


Stream file: ./NABU/track
Code:
00.0    : frev: 37872, drift: 0.549 us, tfer: 216927 B/s, rpm: 360.302
00.0    : base: 1.997 us [99.114%], band: 3.915 us, 5.990 us, 8.064 us?
00.0    : MFM: <mismatch>, *N
00.1    : frev: 62412, drift: 1.823 us, tfer: 356819 B/s, rpm: 360.284
00.1    : base: 1.966 us [91.869%], band: 1.851 us, 5.898 us
00.1    : MFM: <unformatted>
01.0    : frev: 44643, drift: 0.325 us, tfer: 255573 B/s, rpm: 360.272
01.0    : base: 1.007 us [96.451%], band: 1.782 us, 3.020 us, 4.082 us
01.0    : MFM: <unformatted>
01.1    : frev: 65012, drift: 0.283 us, tfer: 372997 B/s, rpm: 360.263
01.1    : base: 0.987 us [94.439%], band: 1.854 us, 2.960 us, 4.314 us
01.1    : MFM: <unformatted>
02.0    : frev: 38366, drift: 0.208 us, tfer: 219250 B/s, rpm: 360.285
02.0    : base: 2.001 us [99.593%], band: 3.959 us, 6.004 us, 7.972 us
02.0    : MFM: <mismatch>, *NT

The three errors I see immediately are:
1. rpm: 360.302 which should be 300 RPM
2. MFM: <mismatch>, *N is telling me it was a bad read
3. The output IMG file is zero bytes.
-rw-r--r-- 1 larry larry 0 Dec 15 07:19 NABU.img

Is it possible to get another streamed read of the floppy with ONLY tracks 0 to 39, Single Sided, with 1024 byte
sectors, and 5 sectors per track spinning at 300 RPM?

Larry
 
I've downloaded the Streamed *.RAW files, and tried to process them under Ver 2.20 DTC software.
That didn't go very well, so I've installed Version 3.0 DTC Software.

I used the floppy parameters associated with this CP/M definition, assuming the floppy was a
5.25" Floppy spinning at 300 RPM with 40 Tracks of Data on one side.

Code:
#cpmtools definition
# NAB1  Nabu PC - SSDD 5.25" 48 tpi - 1024 x 5
diskdef nab1
  seclen 1024
  tracks 40
  sectrk 5
  blocksize 1024
  maxdir 96
  skew 2
  boottrk 1
  os 3
end

I used the uploaded *.RAW files to playback the streamed the data, and create a *.IMG file named NABU.img


larry@debian:~/Downloads/kryoflux/kryoflux_3.00_linux/dtc/x86_64$ dtc -r5 -f./NABU/*.raw -i0 -fNABU.img -i4 -s0 -e79 -g0 -k1 -n+5 -z3 -m1

But, the floppy read should have been only 40 tracks, versus 80.

$ dtc -r5 -f./NABU/*.raw -i0 -fNABU.img -i4 -s0 -e39 -g0 -k1 -n+5 -z3 -m1


Stream file: ./NABU/track
Code:
00.0    : frev: 37872, drift: 0.549 us, tfer: 216927 B/s, rpm: 360.302
00.0    : base: 1.997 us [99.114%], band: 3.915 us, 5.990 us, 8.064 us?
00.0    : MFM: <mismatch>, *N
00.1    : frev: 62412, drift: 1.823 us, tfer: 356819 B/s, rpm: 360.284
00.1    : base: 1.966 us [91.869%], band: 1.851 us, 5.898 us
00.1    : MFM: <unformatted>
01.0    : frev: 44643, drift: 0.325 us, tfer: 255573 B/s, rpm: 360.272
01.0    : base: 1.007 us [96.451%], band: 1.782 us, 3.020 us, 4.082 us
01.0    : MFM: <unformatted>
01.1    : frev: 65012, drift: 0.283 us, tfer: 372997 B/s, rpm: 360.263
01.1    : base: 0.987 us [94.439%], band: 1.854 us, 2.960 us, 4.314 us
01.1    : MFM: <unformatted>
02.0    : frev: 38366, drift: 0.208 us, tfer: 219250 B/s, rpm: 360.285
02.0    : base: 2.001 us [99.593%], band: 3.959 us, 6.004 us, 7.972 us
02.0    : MFM: <mismatch>, *NT

The three errors I see immediately are:
1. rpm: 360.302 which should be 300 RPM
2. MFM: <mismatch>, *N is telling me it was a bad read
3. The output IMG file is zero bytes.
-rw-r--r-- 1 larry larry 0 Dec 15 07:19 NABU.img

Is it possible to get another streamed read of the floppy with ONLY tracks 0 to 39, Single Sided, with 1024 byte
sectors, and 5 sectors per track spinning at 300 RPM?

Larry
Yeah the dump was clearly taken using a HD drive rather then a DD drive. Though I have used hxcfloppyemulator to successfully convert these stream files to a raw sector image.

When using it before loading the the stream files you need to set the following parameters under Settings -> Internal Parameters
FLUX_RPMFIX = 360TO300RPM
KFRAWLOADER_DOUBLE_STEP = 1
KFRAWLOADER_SINGLE_SIDE = 1

After doing that you can click export and save a raw IMG file.
 
brijohn,
It's odd there is no information about these setting for the command line. That's good information
to know, and should also be supported by the command line switches.

Larry
 
My normal Kryoflux setup is with an IBM 4869 enclosure with a TEAC dual floppy (1.2MB & 1.44MB floppy in one unit). I swapped to a 360K floppy drive and now Kryoflux is making Osborne diskettes like ImageDisk.

Still working on getting the 360k drive working properly.
 
Back
Top