Bad disk image?

[GeoffB17]

Trying to make sense of all this.

I've got the images, seem OK, but I've not tried writing a disk as there doesn't seem to be any point.

The boot/load process sounds like it might be OK with the disk, but it's looking for a file (on the netwrok ?) that's not there. Do you have the full name/path of the missing file? Something .PAK? What is a .PAK file

What happens if you create such a file? Anything in the file that will do something, i.e. not introduce a new problem, so that the process can move on to the next step? If it will do this, then may prove that the disk is OK.

Geoff

 

[snuci]

It is confusing. I will make a short video tomorrow to explain as it is much easier to demonstrate than to explain on paper.

 

[GeoffB17]

snuci,

I've now used IMDU to create a binary dump of the first disk, and I've had a look at the code/data there. I've not gone so far as to try any disassembly, but this is possible.

The disk seems to be a normal CP/M boot/system disk, and the first track does seem to be discrete, and there is a 'message' in there regarding Boot Fail - do you get this message. The code is part only of the first track, there is a lot of padding data, so I don't think this is any more than a boot sector(s). There is no sign of anything regarding a .PAK file, so this must be referenced elsewhere, however the boot code could be doing the same as a standard PC, i.e. looking for the first file on the first device regardless of the actual filename/path.

If your attempt to boot is failing at this point, it could still be nothing to do with the disk.

By the way, note the new post in this thread where someone in Canada is offering replacement ROMs for this machine - maybe more a 'how-to' regarding creating a new ROM. This might help your endeavours?

The rest of the floppy up to the directory area seems to be a BIOS (and/or BDOS) and there is a reference to it seeking the CPM3.SYS file (which IS one of the files in the DIR) and I assume loading /running this. I assume you've never got to the point of this.

The DIR seems normal, but clearly smaller than usual. On this disk there is one deleted file, and (I think) three unused entries.

The rest of the disk is the file area, I certainly see the data for the HELP file.

Geoff

 

[brijohn]

@GeoffB17
So i've not tried on real hardware but currently it seems that running it under my mame emulation core is producing the same results. In both cases the the visible result is that that system hangs while displaying "Loading from floppy disk" and the motor is left turned on.

A little bit of using mame's i could see that we are calling the BDOS command to open a file (CPM3.SYS) but instead of returning from the BDOS call we end up stuck in a loop across addresses 0x507-0x51B. Since this is running CPM, the source for CPM3's cpmldr.asm is available online, i was able to map those addresses to seek1 label in the source file. Though i haven't tried to do much beyond that to figure out why we get stuck.

 

[GeoffB17]

Thanks for the further info.

A lot of the previous discussion was about the suggestion that the disk image, and/or the process to write the image to a real disk, was causing the problem. But this was not certain. It was also possible that the problem was a missing (or not in the right place) file on the network that the NABU was connecting to.

You're now giving a slightly different story, i.e. suggesting that the handling of the boot disk is getting somewhat further (i.e. the boot disk is less the problem), the second part of the system tracks on the boot disk is loading and running, but the problem is when that software tries to load/run CPM3.SYS. That file IS on the disk, but I've not checked if the file seems valid - I should check that. The file might be damaged, or maybe the process of the file does not match the hardware.

Geoff

 

[brijohn]

Thanks for the further info.

A lot of the previous discussion was about the suggestion that the disk image, and/or the process to write the image to a real disk, was causing the problem. But this was not certain. It was also possible that the problem was a missing (or not in the right place) file on the network that the NABU was connecting to.

You're now giving a slightly different story, i.e. suggesting that the handling of the boot disk is getting somewhat further (i.e. the boot disk is less the problem), the second part of the system tracks on the boot disk is loading and running, but the problem is when that software tries to load/run CPM3.SYS. That file IS on the disk, but I've not checked if the file seems valid - I should check that. The file might be damaged, or maybe the process of the file does not match the hardware.

Geoff

So I i took another look an it seems only two actual disk related BIOS functions are being called before we get stuck in our infinite loop. The two being called are the seldsk function and the home (return to track 0) function, the interesting one is the seldsk function which returns a pointer to the "Disk Parameter Header" (DPH). This structure has a bunch of pointers to other data areas, but the one we are interested in is the "Disk Parameter Block" (DPB). The DPB should be filled with a bunch of information about the disk (records per track, directory entries, etc), however in this case it seems to be pointing to a 17 byte block of zeros. This seems decided wrong, so the question is why the seldsk BIOS call seems to be returning incorrect information.

DPH @ BE8
XLT:      0000
DW:       0000 0000 0000 0000
DB:       00
MEDIA:    00
DPB:      0C02
CVS:      7FB5
ALV:      7FE6
DIRBCB:   BD0
DTABCB:   BDC
HASH:     FFFF
HBANK:    00

DPB @ C02
SPT:      0000
BSH:      00
BLM:      00
EXM:      00
DSM:      0000
DRM:      0000
AL0:      00
AL1:      00
CKS:      0000
OFF:      0000
PSH:      00
PHM:      00

 

[snuci]

So I i took another look an it seems only two actual disk related BIOS functions are being called before we get stuck in our infinite loop. The two being called are the seldsk function and the home (return to track 0) function, the interesting one is the seldsk function which returns a pointer to the "Disk Parameter Header" (DPH). This structure has a bunch of pointers to other data areas, but the one we are interested in is the "Disk Parameter Block" (DPB). The DPB should be filled with a bunch of information about the disk (records per track, directory entries, etc), however in this case it seems to be pointing to a 17 byte block of zeros. This seems decided wrong, so the question is why the seldsk BIOS call seems to be returning incorrect information.

I can confirm that the home function is executing after a boot attempt. I connected an HxC2001 to the NABU because it has a display that shows the current track/sector and side. Here is a very brief video that I will remove at some point. You can see that after a boot attempt, the floppy drive ends up at the home position after attempting to boot. Pay special atttention to the sounds the drive and HxC make. You can hear the head moving tracks in both cases as the HxC emulates the sound for track movement.

Can we simply edit the DPB and put the right information in for the drive? I was suspecting this was a possible issue.

 

[brijohn]

I can confirm that the home function is executing after a boot attempt. I connected an HxC2001 to the NABU because it has a display that shows the current track/sector and side. Here is a very brief video that I will remove at some point. You can see that after a boot attempt, the floppy drive ends up at the home position after attempting to boot. Pay special atttention to the sounds the drive and HxC make. You can hear the head moving tracks in both cases as the HxC emulates the sound for track movement.

Can we simply edit the DPB and put the right information in for the drive? I was suspecting this was a possible issue.

Yes i think that would be possible I converted the imd disk image to a raw sector image and if I look at i can see the DPH starting at offset EE8 (BE8 in memory) and following that starting at F02 (C02 in memory) you can see the 17 zero's the should make up the DPB. If we can reconstruct what the DPB should be then we can likely edit those and recreate an IMD from the raw sector image with the fixed DPB.

 

[ldkraemer]

The Definitions I have for the NABU are as Follows:

BEGIN NAB1  Nabu PC - SSDD 5.25" 48 tpi - 1024 x 5
DENSITY MFM, LOW
CYLINDERS 40 SIDES 1 SECTORS 5,1024
SIDE1 0 1,3,5,2,4
BSH 3 BLM 7 EXM 0 DSM 194 DRM 95 AL0 0E0H AL1 0 OFS 1
END

#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

#libdsk definition
[nab1]
description = NAB1  Nabu PC - SSDD 5.25" 48 tpi - 1024 x 5
cylinders = 40
heads = 1
secsize = 1024
sectors = 5
secbase = 1
datarate = DD

#Flashfloppy/GOTEK definition
[nab1]
cyls = 40
heads = 1
secs = 5
interleave = 2
bps = 1024
id = 1
#rpm = 360
rpm = 300
rate = 250
mode = mfm
iam = no

The directory is located at 0x1400 = 5120 Decimal = Start of Track #1 and appears Valid
03,04,05,06 Tells us 8 Bit values vs 16 Bit values for the Allocation units.

00001400 00 48 45 4C 50 20 20 20 20 48 4C 50 00 00 00 80 .HELP HLP....
00001410 03 04 05 06 20 21 22 23 24 25 26 27 28 29 2A 2B .... !"#$%&'()*+
00001420 00 43 50 4D 33 20 20 20 20 53 59 53 00 00 00 78 .CPM3 SYS...x
00001430 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 00 ................
00001440 00 42 41 43 4B 55 50 20 20 43 4F 4D 00 00 00 20 .BACKUP COM...
00001450 16 17 18 19 00 00 00 00 00 00 00 00 00 00 00 00 ................
00001460 00 46 4F 52 4D 41 54 20 20 43 4F 4D 00 00 00 22 .FORMAT COM..."
00001470 1A 1B 1C 45 46 00 00 00 00 00 00 00 00 00 00 00 ...EF...........
00001480 00 43 4F 50 59 53 59 53 20 43 4F 4D 00 00 00 11 .COPYSYS COM....
00001490 1D 1E 1F 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000014A0 00 48 45 4C 50 20 20 20 20 48 4C 50 01 00 00 80 .HELP HLP....
000014B0 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B ,-./0123456789:;
000014C0 00 48 45 4C 50 20 20 20 20 48 4C 50 02 00 00 45 .HELP HLP...E
000014D0 3C 3D 3E 3F 40 41 42 43 44 00 00 00 00 00 00 00 <=>?@ABCD.......
000014E0 00 43 48 45 43 4B 20 20 20 43 4F 4D 00 00 00 13 .CHECK COM....
000014F0 47 48 49 00 00 00 00 00 00 00 00 00 00 00 00 00 GHI.............
00001500 00 53 45 54 20 20 20 20 20 43 4F 4D 00 00 00 53 .SET COM...S
00001510 4F 50 51 52 53 54 BA BB BC BD BE 00 00 00 00 00 OPQRST..........
00001520 00 48 45 4C 50 20 20 20 20 43 4F 4D 00 00 00 38 .HELP COM...8
00001530 55 56 57 58 59 5A 5B 00 00 00 00 00 00 00 00 00 UVWXYZ[.........



The DPB information is stored in the Image as follows:

The Disk Parameter Block (DPB) for each drive is:

+-----+------+-------+-------+-------+-------+------+------+------+-----+
 |SPT.|BSH...|BLM....|EXM....|DSM...,|DRM....|AL0...|AL1...|CKS...|OFF..|
+-----+------+-------+-------+-------+-------+------+------+------+-----+
  16B  8B      8B       8B      16B     16B     8B      8B     16B    16B

EXAMPLE:
RPT = 0024 = The number of 128 byte records per track = 32
BSH = 04 = The block shift count = 4
BLM = 0F = The block mask = 15
EXM = 01 = The extent mask
DSM = 0054 = Disk storage maximum (the largest block number).
DRM = 007F = Directory maximum (the largest directory entry).
DAB = C000= Directory Allocation Block AL0: = C0 & AL1: = 00
CKS = 0020 = Directory check size.
OFF = 0002 = Track offset (number of reserved tracks).

SPT: Number of sectors per track. May differ from RPT if physical sectors are other than
128 bytes in size.

SSZ: Sector size code:
0 = 128 bytes per sector
1 = 256 bytes per sector
2 = 512 bytes per sector
3 = 1024 bytes per sector

NTK: Number of tracks (35, 40, 77, or 80). The number of tracks can be determined by formatting
a Floppy, or with Anadisk. Anadisk will also tell you the sector size and SKEW.

The NABUPER1 Image has:

00003E80 XX XX XX XX XX XX XX XX 20 00 03 07 00 97 00 3F
00003E90 00 C0 00 00 10 01 00 02 03 00 00 28 00 03 07 00
00003EA0 C0 00 3F 00 C0 00 00 10 01 00 02 03 00 00 XX XX



00003E808 00 20 ??
03
07
00
00 97
00 3F
C0 00
00 10
00 01


00003E9B 00 28 Seems correct
03
07
00
00 C0
00 3F
C0 00
00 10
00 01

0x3E808
RPT = 0020 = The number of 128 byte records per track = 32 <--- Doesn't seem correct (1024 * 5) / 128 = 40
BSH = 03 = The block shift count = 3
BLM = 07 = The block mask = 7
EXM = 00 = The extent mask
DSM = 0097 = Disk storage maximum (the largest block number) = 151
DRM = 003F = Directory maximum (the largest directory entry) = 63
DAB = C000= Directory Allocation Block AL0: = C0 & AL1: = 00
CKS = 0010 = Directory check size.
OFF = 0001 = Track offset (number of reserved tracks).


ox3E9B
RPT = 0028 = The number of 128 byte records per track = 40 <---Seems correct (1024 * 5) / 128 = 40
BSH = 03 = The block shift count = 3
BLM = 07 = The block mask = 7
EXM = 00 = The extent mask
DSM = 00C0 = Disk storage maximum (the largest block number) = 192
DRM = 003F = Directory maximum (the largest directory entry) = 63
DAB = C000= Directory Allocation Block AL0: = CO & AL1: = 00
CKS = 0010 = Directory check size.
OFF = 0001 = Track offset (number of reserved tracks).



So, I checked the NABUPER1.IMD and NABUPER1.RAW Images with libdsk's dskid to see what it gives:

$ dskid -type imd NABUPER1.IMD
NABUPER1.IMD:
Driver: IMD file driver
Sidedness: Alt
Cylinders: 40
Heads: 1
Sectors: 5
First sector: 1
Sector size: 1024
Data rate: DD
Record mode: MFM
Complement: No
R/W gap: 0x2a
Format gap: 0x52

Drive status: 0x20
Comment: Nabu Personal Computer
Disk 1
CP/M User

larry@debian:~/IMDs/nabupc/nabupc$ dskid -type raw NABUPER1.RAW
NABUPER1.RAW:
Driver: Raw file driver (alternate sides)
Sidedness: Alt
Cylinders: 40
Heads: 1
Sectors: 5
First sector: 1
Sector size: 1024
Data rate: DD
Record mode: MFM
Complement: No
R/W gap: 0x2a
Format gap: 0x50

Drive status: 0x20

Filesystem parameters:
CP/M:BSH: 0x03
CP/M:BLM: 0x07
CP/M:EXM: 0x00
CP/M:DSM: 0x9b = 155
CP/M:DRM: 0x3f = 63
CP/M:AL0: 0xC0 = 192
CP/M:AL1: 0x00
CP/M:CKS: 0x10
CP/M:OFF: 0x01

Which doesn't exactly match what I manually decoded. So, which is correct so the Floppy Boots?

The directory listing appears sane.

$ cpmls -f nab1 -T raw,nab1 -D  NABUPER1.RAW
     Name    Bytes   Recs  Attr     update             create
------------ ------ ------ ---- -----------------  -----------------
BACKUP  .COM     4K     32  
CCP     .COM     4K     25  
CHECK   .COM     3K     19  
CLEAN   .COM     3K     18  
COPYSYS .COM     3K     17  
CPM3    .SYS    15K    120  
DATE    .COM     3K     22  
DEVICE  .COM     8K     58  
DIR     .COM    15K    114  
DUMP    .COM     1K      8  
ERASE   .COM     4K     29  
FORMAT  .COM     5K     34  
GET     .COM     7K     51  
HELP    .COM     7K     56  
HELP    .HLP    41K    325  
NABUSHOW.COM     3K     21  
PATCH   .COM     3K     19  
PIP     .COM     9K     68  
PUT     .COM     7K     55  
RENAME  .COM     3K     23  
SAVE    .COM     2K     14  
SET     .COM    11K     83  
SETDEF  .COM     4K     32  
SHOW    .COM     9K     66  
SUBMIT  .COM     6K     42  
TYPE    .COM     3K     24  
   26 Files occupying    183K,       9K Free.

Larry

 

[snuci]

I edited the NABUPER1 IMD file and added what I thought was appropriate bytes from @ldkraemer's post at the EE8 position in @brijohn's post and the boot process definitely got further. I may have mixed up some bytes in my interpretation. I put this on the HxC2001 floppy emulator so I could see where the boot process landed and I got as far as track 17, sector 040? Perhaps I am reading the display incorrectly but the NABU diskette only has 5 sectors per track.



We are definitely getting somewhere. The NABU screen just stays at "Loading from floppy disk" and is frozen there.

@ldkraemer

00003E80 XX XX XX XX XX XX XX XX 20 00 03 07 00 97 00 3F
00003E90 00 C0 00 00 10 01 00 02 03 00 00 28 00 03 07 00
00003EA0 C0 00 3F 00 C0 00 00 10 01 00 02 03 00 00 XX XX

Is the bold portion the right bits for a DPB entry for one of the drives with the correct 128 byte records per track = 40?

 

[GeoffB17]

The 'boot process' should not be reading more than the first couple of tracks, i.e. before the Directory, however I believe that the boot process (once finishes) should then proceed to load (and run?) the file CPM3.SYS. I'll need to do some calc to see if that would include T.17 - could be?

Yes, your monitor thing could be counting logical (or is this physical?) sectors of 128 bytes hence it might get up to 40. Did it count 1-40 for the previous part of the process?

Geoff

 

[snuci]

I have just determined that the "/040" on the HxC2001 is the number of tracks and not the sector number so that would read "Read Access on Track 17 of 40 on Side 0". I tried to write out the data the same for both drives and I an getting Track 6 now. Still playing with it but I was hoping the display might be a little more precise. It looks like it has tried to load something beyond the boot track.

 

[brijohn]

@snuci
The DPH is at offset EE8. You would want to edit F02, which is the DPB and on the NABUPER1 disk image is zeroed out.

So I went and updated the DPB on my image and ran it through MAME and it definitely gets further, for one it completes the BDOS open command now, which causes a read from track 1, sector 1. This would be expected since that is the first sector that contains the directory listing, with CPM3.SYS in it. After that it precedes to read the following tracks/sectors: t=2 s=3-5, t=3 s=1-5, t=4 s=1-5, t=5, s=1-2. Which are likely the CPM3.SYS data sectors, though i haven't verified that. However after that it ends up hitting a HALT statement at address 0x1A8. This is part of the the error: function in cpmldr.asm and the error halts on is "CPMLDR error: failed to read CPM3.SYS".

I've attached a log from MAME of the disk accesses made when trying to open/read CPM3.SYS

 

[brijohn]

Oh yeah @snuci the bolded section in your previous post is the correct DPB. Though you should extend it to cover the 02 03 values which are the shift and mask value for the physical sectors on the disk, and they are actually wrong, they should be 03 07 for a 1024 sector disk. 02 03 would be for a 512 sector disk.

 

[snuci]

Oh yeah @snuci the bolded section in your previous post is the correct DPB. Though you should extend it to cover the 02 03 values which are the shift and mask value for the physical sectors on the disk, and they are actually wrong, they should be 03 07 for a 1024 sector disk. 02 03 would be for a 512 sector disk.

Can you make your modified NABUPER1.IMD image available? I'd like to review the changes with mine and work from the same one if that's okay. Do you see this error on screen or is it logged?

 

[brijohn]

Here is a zip file containig both the raw sector image and the ImageDisk I recreated from it. The edits were done at offset F02 on the sector image. No I don't see the error on screen, I know thats the error cause the thats the string loaded into the DE register when the print string bdos function is called. I'm not sure why the string does not seem to show up on screen though, could be another issue with the disk maybe?

 

[brijohn]

Ok so the bios call for output character used by the bdos print string function is just a stub in cpmldr that simple returns, so no messages will be printed during boot.

 

[snuci]

With a quick test, I am also getting stuck on track 5 so we are seeing similar results. Do you have the dual boot to disk and cable running with the Rev 2 firmware? If so, see if you can successfully boot with cable. I cannot as I get an error trying to find a non-existent pak file.

 

[GeoffB17]

I was having a close study of the binary image created using IMDU /B from the original downloaded image 1

NB, connected with my use of the Amstrad PCW, I've spent quite a bit of time looking at image files, esp the .DSK type, where the image includes the interleave, although one of the benefits of the .DSK image is that each track has a header block, which clearly indicates the interleave.

When the IMDU process creates the binary/raw file, it is SUPPOSED to remove any interleave.

But I was trying to work out where the CPM3.SYS file was in the image, and there were clear signs of discontinuities within the data. For example, there was a place where an error message was abruptly terminated. Then, a little way further on, the rest of the message was clearly visible at the start of another block. However, the address difference between the two places was not consistent with the sector size, and was totally adrift from what the difference would have been due to interleave. BUT, the data in the first track seems to be OK, and the directory is complete. Looking at the directory, some of the files have a nicy tidy sequence of alloc block, others do not (suggesting that files have been deleted, others added later, etc. This latter may cause some discontinuities with the data in the image, but again by specific amounts tied to alloc/sector size (I note that the alloc unit is the same as the sector size here).

So maybe there IS something odd with the disk, as OP was originally suggesting? And not because of anything that OP was doing, the images I've got were freshly downloaded from the original web source.

Geoff

 

[ldkraemer]

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