Dragon OS9 with drivewire support

[pser1]

Here's the relevant bit from one of the offending disks:
0000100: 0005 a012 00b4 0001 0000 1200 00ff add9 ................
0000110: 0300 1200 0000 0000 0000 5806 0c11 0a50 ..........X....P

These are the values found in the 'last version' of NitrOS-9 v3.3.0 for Dragon64:
. . . . . . . . . . FILENAME . . . . . . . . . . . . Bytes 0-2. . . .Byte 3 . . .Byte 7 . . . . . .Byte 16. . .
nos96809l1v030300d64_40s_1.dsk . . . . . . $0002D0 . . . . . 12 . . . . . . 01 . . . . . . . . . 02 . . . . So Total = $12 * 40 *(01) * (1 + 02.bit0) = 720 => $02D0
nos96809l1v030300d64_40d_1.dsk . . . . . . $0005A0 . . . . . 12 . . . . . . 01 . . . . . . . . . 03 . . . . . . . . . . = $12 * 40 *(01) * (1 + 03.bit0) = 1,440 => $05A0
nos96809l1v030300d64_80d.dsk . . . . . . . $000B40 . . . . . .12 . . . . . . 02 . . . . . . . . . 03 . . . . . . . . . . = $12 * 40 *(02) * (1 + 03.bit0) = 2,880 => $0B40

So, I can see that the info is absolutely consistent (as is in your disk too):
The number of total sectors (bytes 0-1-2) equals the result of the formula that simply doubles the default 720 number of sectors if byte_16.bit0 is set
and doubles again if byte_7 equals 2 (number of sectors per cluster, maybe number of sides(?))

So I don't see any reason for that disk to fail when copying from a floppy to a VDK file unless it had a damaged sector (?)
Both dweebs do only accept offsets 0-1-2 if they are one of the three above mentioned values, else an error message is sent and the program ends.
If it's OK, then it uses $C026 to read floppy sectors passing the 'absolute' sector number in register Y (no worry about track-sector numbers)
If there were an error, it should be caught ... if the DOS had signaled it by setting register B to something different than 0.

cheers
pere

Ps. I have downloaded the file you added to your last message and will look at it to see what could be used in these dweebs.

[fridgemagnet]

The "problem" with the $[C026] read sector call is that in order to compute the LSN, it needs to know the number of tracks per sector (effectively 18 for single sided or 36 for double sided). Normally it gets that from the DragonDOS directory structure but with an OS9 disk, that figure will default to 18, or whatever the format of the last DragonDOS disk that was in the drive. In that code I posted, you can (hopefully) see me setting this figure in the drive descriptor table based on that read from the OS9 disk (hardcoded to drive 0, offset 1703 - see the DOSPlus manual for details). This works for DOSPlus 4.9 but I don't know if this is the same layout for all the DOS variants out there.

Leaving it with a default of 18 would definitely explain the effect being seen - so I can probably try a quick test here (this evening hopefully) and manually prod 36 into this location and see if it fixes the problem.

[pser1]

Hi Jon,
first of all, thanks a lot for sharing this wonderful piece of code.
It is really very inspiring. I am sure that this would be the base to create a new dweeb to copy a single file from a VDK file into a floppy disk
I have the Grosvenor DOS programmer's guide but had never used these special functions you used.

Now to our FLO2V problem.
I get what you have done in this OS-9 file copy. The only difference is that my dweebs put in $6A6+DriveNumber #18 if the total number of sector is 720
else it puts #36 instead. This is the same as doubling 18 if bit0 at offset $10 is set, so I cannot spot any difference, sorry

I made copies from floppy (DOS) to VDK all sizes (180-360-720) and then the other way round, no problem at all.
I don't remember the tests I did with OS-9 but I have some floppies with OS-9 and NitrOS-9 that work flawlessly, all of them were copied from file images from my PC.

I should have to do some tests again specially from VDK to floppy with NitrOS-9 files, because they MUST be VDK so the DSK plus a 256 byte header with the geometry data.
I will need some time to search among my old files to find out how I did those tests.

cheers
pere

[pser1]

Hello Jon,
I made the tests I promised.
To be able to copy the original DSK files of the last NitrOS-9 version, I have added to them a 256 bytes VDK header
with the geometry according to the VDK header rules, so that they are readable by DW4.
Then I have copied the five disks (2x180k, 2x360k and 1x720k) to physical floppies in my Dragon64 via Drivewire
using the V2FLO dweeb. No problem at all, they have been copied OK
Then I have booted my Dragon with the three versions (180, 360 and 720) and read the other disks on Drive2, everything OK
Next I have created 5 'dummy' files 256 bytes long on the PC to overwrite them by copying back the 5 disks from the Dragon
using the FLO2V dweeb. Again no problem at all, everything went alright
Finally I have started XRoar and used these copied disks (VDK) to start NitrOS-9 and they worked flawlessly.

So, as far as the data in the floppy is consistent, they are copied OK
The same applies to the VDKs from the PC, the header must contain data consistent with the capacity of the original DSK

cheers
pere

[robcfg]

Just out of curiosity, why do you need a 256 byte VDK header? Aren't the usual 12 bytes enough?

[fridgemagnet]

Hi Jon,

[...]

Now to our FLO2V problem.
I get what you have done in this OS-9 file copy. The only difference is that my dweebs put in $6A6+DriveNumber #18 if the total number of sector is 720
else it puts #36 instead. This is the same as doubling 18 if bit0 at offset $10 is set, so I cannot spot any difference, sorry

I confess I hadn't looked too deeply into your code to see what it was doing, I just saw the [$C026] sector call and assumed you may not be taking something into account but on closer inspection it looks ok...

All I can add at this point is to say that I've given it another go and had a look at $6A9 (drive 3) after the failure and it's come back with 18. So that would explain the failure I'm seeing but we're no further as to why...

[fridgemagnet]

Some more results.... Having looked at the state data you are storing - total sectors, that sort of thing and what gets written to the VDK header, this all looks ok, so I think your code is fine. However as I said in my earlier post, when the problem arises and I look in the sectors/track location, it's coming back with 18 not the expected 36.

So I think this maybe a DOSPlus 4 thing - of particular note is in my OS9copy code, the main copy loop starts off like this:

950 @READLOOP LEAX @BUFFER,PCR
960 LDY @SECTOR,PCR
970 LDA @DSKTYPE,PCR:STA 1703
980 LDA #1:STA $EB
990 JSR [$C026]

that line 970 is where the sectors/track variable gets updated and I wonder why I had the need to do this every time around the loop - quite possibly because I found that DOS was resetting it back after each call. This is after all a bit of a fudge since these variables are normally managed by the underlying DOS based on a DragonDOS disk - what you (and indeed I!) should be really doing is using the $C004 call for this sort of thing.

Have you tried running your code under XRoar with a DOSPLUS ROM - just to see if indeed you start seeing the same thing I am?

One more observation (although it doesn't affect me because I don't have any disks in this format), your logic for setting the sectors/track to 36 on detection of a disk with 1440 sectors isn't correct for an 80T/SS disk.

[fridgemagnet]

Just out of curiosity, why do you need a 256 byte VDK header? Aren't the usual 12 bytes enough?

Drivewire needs everything aligned to a 256 byte boundary. The disk images themselves will of course meet that criteria but an additional 12 bytes throws it out. Hence the need to pad it out.

[robcfg]

Ok, thanks for the explanation!

[pser1]

Just out of curiosity, why do you need a 256 byte VDK header? Aren't the usual 12 bytes enough?

Hi Roberto,

I have three bat files to create VDKs that could be used with Drivewire, in this case the header length must be 256 bytes.
But I have another three bats that simply add the 12 bytes header you say. That's good enough for Xroar

cheers
pere