Bad disk image?

[snuci]

@guidol You are correct. We can definitely share software easily for the NABU PC on Osborne formatted diskettes. The NABU disk utilities will work with both NABU and Osborne formats. I use the "show" command in the Disk Utilities to see what type of diskette I am working with. This translates to the "nabushow" command if you boot from CP/M at the command prompt. I definitely know what BASIC works with NABU formatted diskettes because that was all I had at the time when I did the demo in one of my videos. Through the Disk Utilities in NABU RetroNet, I formatted a diskette and used it with BASIC and the Writer software (don't recall the name). I also know that both of those can use Osborne format because that was how I added files to a diskette that NABU thought was Osborne format.

I haven't tried other Osborne formats but if it's 40 tracks, 5 sectors x 1024 bytes per track, it will be fine. The trouble starts when talking about bootable diskettes. We focused on bootable diskettes in this thread but thank you for pointing out, for those who may be casually visiting this thread, that Osborne diskettes can be used for software on the NABU and those can be created with sector data imaging tools like ImageDisk and others.

 

[snuci]

Sorry for the delay brijohn. I had some pictures yesterday but I was missing one and I decided it was best to take pictures of every step so that if I misstepped, you can tell me where I went wrong.

When starting ddt, first d0 a d0 at the prompt this should dump memory addresses starting at 0, you want to look at the second and third byte, those two make up a little endian word that should be your bios address. To get the real start subtract 3 from it, ie. if it was F003, then the bios starts at F000.

Okay, so we get "D903" - 3 = D900

Once you have that enter the following program.

-a100
0100  mvi c,0
0102  mvi e,0
0104  call  <bios address + 0x1b>
0107  rst 7
0108  <press enter>

Now you can run the code you just assembled at address 100, by enter g100 at your prompt. It should return back to the prompt and if you type x it will list the register contents.

H register is E7DF

The H register should have an address in it that points to the current DPH. you can dump that memory by using d<HL value>.

The pointer to the translation table if it exists is at offset 0 (the first two bytes), you should use the dump command to dump the memory there if the pointer is not 0,

E99E right?

The second pointer for the DPB is at offset 12 in the DPH and you should dump that as well.

This is where I get a little confused. This is offset 12 of 2 screens up? You have to side scroll a little...



but it's 0020 if that is correct.



Let me know if this is correct or if not, where I went wrong and I'll try again.

 

[labomb]

You're close with the screenshots... unfortunately, because of the screen mode you need to use the right arrow on the keyboard to see the rest of each snapshot (each line of the DDT output is cut off). It should be two screenshots per DDT command.... 1) enter the DDT command, 2) take a screenshot, 3) hit right arrow, 4) take another screenshot.

As for the commands, you start correctly with the -de7df. The first two bytes of the result gives the address of the translation table (e99e) to dump next. Before doing that, scroll to the right to see what address is at offset 12 (this points to the DPB, which you should dump as well). My guess is that you will see address E7F9 at offset 12.

So -de7df (scroll right), -de99e (scroll right), and (I believe) -de7f9 (scroll right).

 

[GeoffB17]

@snuci

So, I note various comments. I understand that you need the special marker/format on the disk to boot, but without this the disk is - in effect - an Osborne disk, but you can read/write normally with that.

Looking at the dir on the disk we've been looking at, I see that there are two significant progs, FORMAT and COPYSYS.

FORMAT would usually prepare a disk for use, but what does FORMAT do for you? Does it help make a disk that can be booted from? I'd assume it creates just an empty disk, hence the COPYSYS which I would expect will copy the first (system) track from an existing bootable disk to a new formatted disk. Is this so. Have you tried FORMAT, and checked the result, and then tried COPYSYS and see if the resultant disk will boot. I suppose that it MIGHT turn out that you cannot normally create a boot disk, and that you will need the 'flux' facilities. Maybe the plan back in the day was that anyone would need to buy the special boot (able) disks (OK, I understand that disks are NOT part of the standard system, but seems they were a possibility).

However, you need to be able to receive/share software etc. If you can do so using one of the Osborne formats, that is a help. If the NABU will use this format natively, then that's a big help. I assume this refers to the SS, 40t format, is this the ONLY option. This is supported by 22DISK, so you can move files back and forth with your PC (the machine you use with 22DISK).

I still use my Amstrad PCW, this uses for the A: drive (boot) a SS 3" disk, which has a 40t @ 9 512 byte sectors. The system will also support a number of variants. The CP/M 3 system has been 'tweaked' by Amstrad using an XDPB, which includes the system checking the first 16 bytes on the disk which contains certain DPB type info about the disk format so that the system can immed update the DPB to suit the disk used. I need to check this process and see if this process will sipport 5 @ 1k sectors rather than 9 @ 512 bytes. I know the process will support an extra sector, there are working variants using 128 byte sectors, so maybe it will, just no-one bothered to do it? I could certainly create a suitable floppy using 22DISK, my PCW has a 5.25" drive as well as the standard 3" drive (so I've always been able to get software/data easily onto my PCW.

Geoff

 

[brijohn]

So last night i managed to get the on disk structures, that are used for non nabu disks all edited to use the nabu structures allowing the image to boot properly.

However today I now have the custom nabu disk format special handling sector 0. In essence when its building the track data for track 0 it will insert the necessary bytes into the Index Gap, this now allows booting a raw sector image of the CPM disks, without any modifications. Once I finish cleaning up the code I'll update mt git repository. I can still post the edited image if there is any interest but this seems a better way of handling it.

 

[snuci]

So -de7df (scroll right), -de99e (scroll right), and (I believe) -de7f9 (scroll right).

E7DF Left then right. Note: the last column of single digits in the left picture is shown in the first column of the right picture:



E99E left and right



E7F9 Left then right



Hope that helps.

 

[labomb]

E7DF Left then right. Note: the last column of single digits in the left picture is shown in the first column of the right picture:

Perfect... thanks so much for taking the time to do that!

 

[snuci]

@snuci

FORMAT would usually prepare a disk for use, but what does FORMAT do for you? Does it help make a disk that can be booted from?

Format creates an empty diskette. However, saying that, there is a "backup" command that I use to make bootable disk copies because it copies diskettes from one drive to the other by track copy. If I start with a formatted Osborne diskette (that I formatted via 22Disk and not on the NABU) and I do just a "backup", it will NOT boot. However, if I format the diskette in the NABU pc and then do a "backup" the diskette will boot on the NABU.

I'd assume it creates just an empty disk, hence the COPYSYS which I would expect will copy the first (system) track from an existing bootable disk to a new formatted disk. Is this so. Have you tried FORMAT, and checked the result, and then tried COPYSYS and see if the resultant disk will boot. I suppose that it MIGHT turn out that you cannot normally create a boot disk, and that you will need the 'flux' facilities. Maybe the plan back in the day was that anyone would need to buy the special boot (able) disks (OK, I understand that disks are NOT part of the standard system, but seems they were a possibility).

As above, I can make disk copies but I have not used COPYSYS much because I don't really have to. I did do an experiment with an Osborne diskette (formatted with 22disk on a PC) then did a "copysys", then tried to copy all of the files and there were issues with it running out of room. There are some issues there. So I tried an Osborne disk, just CPM3.SYS and CCP.COM and that just exhibited the usual non-boot.

However, you need to be able to receive/share software etc. If you can do so using one of the Osborne formats, that is a help. If the NABU will use this format natively, then that's a big help. I assume this refers to the SS, 40t format, is this the ONLY option. This is supported by 22DISK, so you can move files back and forth with your PC (the machine you use with 22DISK).

That is correct but I have used a double-sided disk drive in the NABU before. I have not tried booting, however, as this was before we had good boot disks. I will try a normal double sided drive when I get the FDC boards in the next day or two to test out the floppy disk controller reproduction. This might give us more room. I may also be able to do create bootable double-sided diskettes? The NABU format support double-sided diskettes.

I still use my Amstrad PCW, this uses for the A: drive (boot) a SS 3" disk, which has a 40t @ 9 512 byte sectors. The system will also support a number of variants. The CP/M 3 system has been 'tweaked' by Amstrad using an XDPB, which includes the system checking the first 16 bytes on the disk which contains certain DPB type info about the disk format so that the system can immed update the DPB to suit the disk used. I need to check this process and see if this process will sipport 5 @ 1k sectors rather than 9 @ 512 bytes. I know the process will support an extra sector, there are working variants using 128 byte sectors, so maybe it will, just no-one bothered to do it? I could certainly create a suitable floppy using 22DISK, my PCW has a 5.25" drive as well as the standard 3" drive (so I've always been able to get software/data easily onto my PCW.

Geoff

Looks like @brijohn has a nice work-around to only being able to flux diskettes for imaging. I am anxious to try that.

 

[snuci]

I can still post the edited image if there is any interest but this seems a better way of handling it.

I'm happy to try it on real hardware.

In my discussion with @diskblitz, he offered to modify the Applesauce handling of IMD files but being that it is not universal and the Applesauce does flux imaging and writing anyway, I didn't see a point. I did mention my preference was for sector data imaging so anyone with an old PC and floppy drive (with the right configuration) could make bootable NABU floppies.

 

[brijohn]

I'm happy to try it on real hardware.

In my discussion with @diskblitz, he offered to modify the Applesauce handling of IMD files but being that it is not universal and the Applesauce does flux imaging and writing anyway, I didn't see a point. I did mention my preference was for sector data imaging so anyone with an old PC and floppy drive (with the right configuration) could make bootable NABU floppies.

Ok Here is a edited copy of the LEO1 disk then.

 

[Klyball]

Where is the check for Nabu vs Osborne done . is that in rom?

 

[brijohn]

Where is the check for Nabu vs Osborne done . is that in rom?

No the nabu disks have a bunch of out of band data in the Index Gap of track 0. This contains a marker and then the actual DPB for a nabu formatted disk. During the seldsk CP/M bios routine it will read track 0 and scan for this out of band data if it finds it then its a nabu disk and it will use the encoded DPB, otherwise its an Osborne disk and it uses the default on disk DPB.

 

[Klyball]

is the out of band data needed or is it just a check , can the cpm/bios be hacked to just jump it?

 

[brijohn]

is the out of band data needed or is it just a check , can the cpm/bios be hacked to just jump it?

Its not just a check, the correct DPB is encoded there as well. That being said you can edit the on disk DPB, which is the one used if you don't have a nabu formatted disk and get it to boot. I posted an edited version of the "Leo 1" disk a few posts up, where i did just that. The downside is that the edited version of the disk won't support Osborne style disks anymore.

 

[snuci]

Ok Here is a edited copy of the LEO1 disk then.

Works wonderfully. I converted to IMD and wrote it out. Would it be okay to post in my disk-images directory? If you could do Leo2, that would be great as well.

Very impressive work.

 

[brijohn]

Works wonderfully. I converted to IMD and wrote it out. Would it be okay to post in my disk-images directory? If you could do Leo2, that would be great as well.

Very impressive work.

Yeah thats fine, I'll edit leo 2 when i have some time.

 

[snuci]

Yeah thats fine, I'll edit leo 2 when i have some time.

Don't forget to remove the profile.sub file. Otherwise it will try to redirect output to the R232 card (we don't have) and there is no A prompt as a result.

 

[brijohn]

Don't forget to remove the profile.sub file. Otherwise it will try to redirect output to the R232 card (we don't have) and there is no A prompt as a result.

Ok here is the patched leo2.img file, i renamed the profile.sub to rs232.sub, so its still there but won't execute on startup.

Also it includes a better version of leo1.img as well. The original one i posted had more edits then were actually needed, this one reduces the changes to the disk.

 

[labomb]

Ok here is the patched leo2.img file, i renamed the profile.sub to rs232.sub, so its still there but won't execute on startup.

Works great! I see where you put the XLT pointer and eventually I figured out why .

The only comment I have is that the DPB checksum vector size technically should be 18h versus 1800h. I know that the out of band DPB uses 1800h, but I think that was an error, the value really should be dir entries/4. It works fine regardless, apparently the value isn't utilized in this case.

Thanks for fixing these up.

 

[brijohn]

Here is a patched version of NABUPER2. I haven't bothered to patch NABUPER1 and NABUPER3 as they are basically the same as the existing leo1 and leo2 images. This one has a bunch of developer tools, assembler, linker, debugger, etc, that are not found on the other images.