• Please review our updated Terms and Rules here

Bad disk image?

GeoffB17 said:
I downloaded and unpacked Larry's files, and as far as the .IMG (the RAW/BIN) file is concerned, there are a lot of differences. There's now about twice as much code showing in Tr.1, there seemed to be a lot of padding before.

The code in Tr.1 seems to be two parts, there's the initial boot code, about 1 sector only, which will have almost no OS at all, and will simple load the rest of the track (somewhat more sophisticated, incl a simple OS) that will now need to access Tr.2 onwards incl find and load CPM3.SYS. By now, the code will need to lnow how to work with the interleave. The image now has a large dummy file (I think just random text) and also the HELP file has moved, so it's not easy to compare with previous images.

Why Osborne? Somewhere there will be a list of some disk parameters, each named. At some point, the software will check that list and find a match. Which parameters are defined in the list may be somewhat arbitrary. It would however be interesting to access that list, and see what the differences are between the NABU type and the Osborne - the difference may be a pointer as to where the problem still is. Which prog was saying the disk was Osb - I think you did get it to be NABU previously?

Regarding the 22DISK error, what params are you using? If you're using data from an earlier posting, just note the message #

Geoff
Click to expand...
So I looked at these disk images and i don't think the are correct. The issue here is that the skew seems to be done at the CPM level not at a hardware level. The sectors on disk are still the same if CPM request sector 2 for instance it will still get the same data as the original. You woulld need to uninterleave the actual sector data not interleave the disk sectors in order for things to work.
 
@brijohn

Is ddt safe to use with CPM 3? Or might there be probs only with banked versions, maybe the NABU is not 'banked'?

I understand that ddt is now superceeded by SID. The CP/M 3 system that was supplied with my Amstrad PCW came with SID, so I assume the latter IS safe to use with banked CP/M 3.

Geoff
 
Look at this.

So once CPM3.SYS was actually started i had to place a breakpoint at the seldsk routine in the bios and then edit in the sector translation table in memory and fix up a few issues with the DPB (3 reserved sectors instead of 1??), but after that when i hit continue on the debugger i actually have a command prompt and can list the directory.

emulated.png
 
GeoffB17 said:
@brijohn

Is ddt safe to use with CPM 3? Or might there be probs only with banked versions, maybe the NABU is not 'banked'?

I understand that ddt is now superceeded by SID. The CP/M 3 system that was supplied with my Amstrad PCW came with SID, so I assume the latter IS safe to use with banked CP/M 3.

Geoff
Click to expand...
Yeah DDT should be fine on cpm 3. But also NABU is not banked. It only has 64k of memory in the first place, so there should be no issues.
 
@brijohn What type of files are you working with? I've been working with Applesauce and I have been able to successfully write an a2r flux image (in my disk_images directory) using that so we have two flux solutions. Are you using sector data images like IMD or IMG?
 
snuci said:
@brijohn What type of files are you working with? I've been working with Applesauce and I have been able to successfully write an a2r flux image (in my disk_images directory) using that so we have two flux solutions. Are you using sector data images like IMD or IMG?
Click to expand...
I'm working with your two kryoflux streams and using fluxengine to convert them to a raw sector image file (IMG). Theses are the easiest to work with since i can just edit the sectors directly. Looking at the DPB after CPM3.SYS boots i noticed it was also wrong but the interesting bit was that the reserved sectors were 3 instead of 1. This would make the directory start at 3C00 instead of 1400, which is the same place as the osborne1 DD disks place their directory. So maybe the OS is for some reason deciding this is an osborne disk and loading the wrong DPB.
 
snuci said:
Ya, this is the crux of the problem. The NABU PC thinks these disks are Osborne disks unless they are flux imaged. At least that's the working theory right now.
Click to expand...
Yeah i should probably dump out the seldsk routines both from the cpmldr in the boot track and the one running after cpm3.sys is loaded and see if we can't figure out what they are doing.
 
With the help of Disk Blitz on the Applesauce Discord, I've been able to write out HFE files via the Applesauce disk imager. I believe there are two HFE files in the disk_images directory. Those work natively on the HxC2001 and I could write them to floppy that then booted fine.

I think the issue is with sector data files as there is not enough information in them to make a proper diskette.
 
Ok, I believe that I have the solution to the mystery of why written disks are being mis-identified as being Osborne. The Nabu CP/M disks contain an out-of-band sequence on track 0, located between the index and sector 1.

Screen Shot 2022-12-17 at 11.29.10 AM.png

The sequence starts with 2x A1 MFM markers (4489). These are the sequences from the 2 disks I have looked at:

A1A14E4E4E4E4E4E4E4E4E4E4E4E190F2D1A002800030700C2005F00E0000018010003074E
A1A14E4E4E4E4E4E4E4E4E4E4E4E0E0D2F00002800030700C2005F00E0000018010003074E

If this sequence exists, the disk is identified as Nabu, and if not then it is declared Osborne. Probably due to the fact that the sequence contains the CP/M DPB (Disk Parameter Block) and is laid out like this:

A1 A1 <4e x 12> <4 bytes that are maybe volume/disk id> 00 <DPB>

The DPB translates to this:

spt = 40 ;Number of 128-byte records per track
bsh = 3 ;Block shift. 3 => 1k, 4 => 2k, 5 => 4k....
blm = 7 ;Block mask. 7 => 1k, 0Fh => 2k, 1Fh => 4k...
exm = 0 ;Extent mask, see later
dsm = 194 ;(no. of blocks on the disc)-1
drm = 95 ;(no. of directory entries)-1
al0 = 224 ;Directory allocation bitmap, first byte
al1 = 0 ;Directory allocation bitmap, second byte
cks = 1800h ;Checksum vector size, 0 or 8000h for a fixed disc.
off = 1 ;Offset, number of reserved tracks
psh = 3 ;Physical sector shift, 0 => 128-byte sectors
phm = 7 ;Physical sector mask, 0 => 128-byte sectors

Unfortunately, this does mean that using tools like imagedisk are not going to work for imaging these disks. And there are no sector-based disk image formats that will accommodate these either.
 
Last edited:
brijohn said:
So once CPM3.SYS was actually started i had to place a breakpoint at the seldsk routine in the bios and then edit in the sector translation table in memory and fix up a few issues with the DPB (3 reserved sectors instead of 1??), but after that when i hit continue on the debugger i actually have a command prompt and can list the directory.
Click to expand...

I've spent a bit of time with the mame debugger poking around, and determined that the DPH resides at E7DF, and that in turn points to the DPB at E7F9. I suspect that the DPB at disk image offset 0x0F02 is used only during the boot process (part of the CPMLDR), and after things are up and running what is used is what is defined in the BIOS. Either way, as you note, the total blocks and reserved values don't make much sense to me. I also noted that the translation table pointer in the DPH is reset to 0x0000 in memory, regardless of how it is configured at disk image offset 0x0EE8.

I haven't been able to get past the 'No CCP.COM' error by making changes after the SELDSK breakpoint. The XLT table does indeed stay at 0C13, but changing the DPH just before the SELDSK routine exits doesn't seem to be enough. May I ask what specifically you adjusted in the DPB to get to the CP/M prompt?
 
Yeah, so the memory edits i did are:

I put a copy of the XLT table at address E824 and then put that address as the XLT pointer in the DPH return in HL by the seldsk routine. A also update the E7F9 DPB with a copy of the edited version on disk. Then I was able to boot CPM and get to the prompt. The issue is that that is not permanent, next time seldsk is called the changes have to b done again so this is not a final solution.

Also as has been said during seldsk a copy of track 0 is read, there is information that tells if the disk is a nabu disk or not encodiing in the out of band index gap on the disk, this is how it determines what DPH/DPB to load in seldsk as far as i can tell. This information only exists in the flux which is why the current non flux disk images are not working correctly. To fix this the cpm3.sys file would need to be edited so it always assumes the disk is a nabu disk, though that would mean osborne disks would not work. Osborne style is what things like basic and writer use.
 
Yes, I was going to edit the disk image DPB at 44D4, and the DPH at 465F... presumably the BIOS part of CPM3.SYS. Thanks for the detail.
 
So, is it the hfe format alone that can retain the required bits, or is the hfe format coupled with hardware (be it the HxC, or presumably a Gotek device) required? If the former, can hfe file support be added to the nabupc module in mame (I belive there are other emulated systems in mame that do support hfe)?
 
labomb said:
So, is it the hfe format alone that can retain the required bits, or is the hfe format coupled with hardware (be it the HxC, or presumably a Gotek device) required? If the former, can hfe file support be added to the nabupc module in mame (I belive there are other emulated systems in mame that do support hfe)?
Click to expand...

I was able to write out an HFE file to disk with the Applesauce disk imaging solution and it worked fine. I also have Kryoflux RAW and the Applesauce A2R native flux format that can be written but at this point you need an Applesauce or Kryoflux. All images are at https://vintagecomputer.ca/files/Nabu/disk_images/
 
labomb said:
So, is it the hfe format alone that can retain the required bits, or is the hfe format coupled with hardware (be it the HxC, or presumably a Gotek device) required? If the former, can hfe file support be added to the nabupc module in mame (I belive there are other emulated systems in mame that do support hfe)?
Click to expand...
I think hfe supports it, however only with gotek or HxC, I could not get it working. MAME takes all disc images and converts the mage to its own internal format, which loses the necessary out of band information.

That being said i now have a hacked disk image that always loads the correct tables, you lose out on the ability to work with osborne style disks, but it does boot without any fiddling around on the users part. In theory you should be able to imag this image and boot on real hardware as well. I'm post it sometime tomorrow when i have a chance.

To be honest i'm relatively impressed the NABU CPM system disks are about the last place i expected to find what amounts to obscure copy protection by fiddling around with the disk in non standard ways. :sneaky:
 
I dont know much about all these special internal parameters of disk-images and it may be not something new to you, but I hadnt read it in this thread here:
I had downloaded the NABU_LEO2.hfe image and converted it with the HxC Software v2.5.6.6 to .IMG (RAW) and renamed it to .DSK
This .DSK (attached here as .zip) can be listed fine with the cpmtools-defs nab1 from post 69:
root@npi-neo2-24:~# cpmls -f nab1 /NABU/leo2_hfe.dsk 0: backup.com ccp.com check.com clean.com copysys.com cpm3.sys date.com device.com dir.com erase.com format.com get.com help.com help.hlp junk nabushow.com patch.com pip.com profile.sub put.com rename.com save.com set.com setdef.com show.com submit.com type.com

but if we format the floppy inside the disk-utilities then the .dsk-file can be accessed with the osborne1 format of the cpmtools.

# 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 # Osborne 1 diskdef osborne1 seclen 1024 tracks 40 sectrk 5 blocksize 1024 maxdir 64 boottrk 3 os 2.2 end

So it seems that BASIC and the Disk-Utilities defaults to the Osborne-Setting and not autmatically recognize the Nab1 format :(
 

Attachments

  • leo2_hfe.zip
    93.1 KB · Views: 3
You must log in or register to reply here.
Back
Top