Dragon OS9 with drivewire support

[fridgemagnet]

That was (kind of) my original intention to use your FLO2V app to copy a couple of OS9 5.25" disks across as VDKs. The trouble is I'm not sure whether they are 180K or 360K disks and I'm assuming that I need to tell your app somehow which size to create. Hence my plan to boot into OS9 and check them out there - all my existing OS9 boot disks have dependencies on customised hardware which is no longer fitted hence the need to start again. I was also considering maybe copying them across file by file under OS9 to a new VDK (since they don't have to be retained as complete disk images).

[robcfg]

As far as I know, software released on disk should be 180kb, as standard disk drives for the Dragon were single side, single density.

[pser1]

Hello,
I have some disks bigger than 180k that work perfect with XRoar-Becker and with the real Dragon-DW4:
NitrOS-9 L1 v3.3.0 for Dragon 64 (6809) --- 720K
NitrOS-9 L1 v3.3.0 for Dragon 64 (6809) --- 360K (the very same in a smaller disk)
They both boot up without problems, so it seems that OS-9, NitrOS-9 as the standard DOS are able to work with any disk type that suits the controller
So 180, 360 and 720 are acceptable for these systems.

By now I have worked with XRoar mounting 4 disks (different length) and they are accesible:
DIR for the slot0
DIR /X1 for the slot1
DIR /X2 for the slot2
DIR /X3 for the slot3
Don't know why but - DIR /Dn (being 0<=n<=3) always hangs the XRoar session.

With my Dragon64-DW4 it works the same way and have not succeeded trying to access the 'real' floppies

cheers
pere

[fridgemagnet]

Hi Pere,

Seems I was worrying unduly, your FLO2V detects the size of the source disk being copied so I don't have to into OS9 to figure out what format they are (although I did find an old working boot disk & did just that) - done a couple of 40T/SS and it seems work flawlessly.

However... There seems to be a problem when I come to copy to 40T/DS disks, when FLO2V crosses the 720 sector mark, the floppy drive heads make that classic "retry" noise then it fails out with an I/O Error. This is consistent, even though I have verified the disk is ok. I think I know what the problem is though, looking in the last track register at $ff41 after the error, it shows a value of 40 (when it should be 0-39 for a 40 track disk) so I think there is an assumption being made that this is 80T/SS rather than 40T/DS.

jon.

[pser1]

Hi Jon,

I know there is a difference between double sided single density (360K) and single sided double density (360K too)
but apparently they are treated right.
The FLO2V dweeb knows the DOS disks and works with the OS9 ones looking to a few bytes.
I will look at the source code and will copy here the info it searches for to decipher what kind of OS-9 disk it is working with.

cheers
pere

[pser1]

Hi Jon,
first surprise, my NitrOS-9 DSK files have all of them these three initial bytes:
$00 $48 $00
Whilst the 2 DSK I have (180k) that BOOT NitrOS-9, have these data:
$00 $02 $D0

$02D0 means 720 sectors, so it is a single side single density disk (40 tracks x 18 sectors each)
But $4800 equals 18,432 sectors, this an incredible amount!
I am sure that my V2FLO will fail with such a sector number

I'm sorry I cannot verify any other physical disks because I have attached two 3.5" drives to my Dragon
and unfortunately I have NO OS-9 disks for that kind of drive.
Coud you tell me what info is in these three first bytes of the OS-9 or NitrOS-9 disks you have?
thanks beforehand

cheers
pere

[pser1]

I have perused my PC folders in wich there are quite some OS-9 disks.
All of the disks that are made to be used with a real Dragon or in XRoar, are DSK files that contain in offset 1-2 the number of sectors of the disk.
But ... the ones ready to work with DW or with Becker (so, on the server side) have another format (in the first sector) and these two bytes are always: $4800
So, it doesn't seem a good idea to copy these DSK files to physical floppies (in fact they are not intended for that purpose)
But the ones that are to be used with a Dragon, should have at offset 1-2 the number of sectors of the disk and it should be:
$02D0 (720), $05A0 (1440) or $B40 (2880)
This is the info that my dweeb searches and uses to decide the disk format (must be one out of these three, exactly)

cheers
pere

EDIT: According to Graham Kinns notes, the THREE first bytes denote the number of sectors that the disk contains, so the numbers in the DW and Becker versions
seem too high to be true: $00, $48, $00 => $004800
Could anybody explain the reason why these values are there instead of the standard ones?

[fridgemagnet]

You are correct in that bytes 0-3 are the total number of sectors on the media however OS9 utilises the same disk layout for any type of disk media - floppy drives, hard drives etc. & drivewire I suspect let's you format an image to any size you'd like. This indeed appears to be the case where the DW images are $4800 sectors long so a total maximum disk size of ~4.5MB. Probably the intent being is that people will then add to this so why restrict it to the size of a floppy.

This from the OS9 System Programmers Manual:

Offset ORG 0
$00 DD.TOT RMB 3 Total number of sectors on media
$03 DD.TKS RMB 1 Number of sectors per track
$04 DD.MAP RMB 2 Number of bytes in allocation map
$06 DD.BIT RMB 2 Number of sectors per cluster
$08 DD.DIR RMB 3 Starting sector of root directory
$0B DD.OWN RMB 2 Owner’s user number
$0D DD.ATT RMB 1 Disk attributes
$05 DD.DSK RMB 2 Disk identification
$10 DD.FMT RMB 1 Disk format: density, number of sides
$11 DD.SPT RMB 2 Number of sectors per track
$13 DD.RES RMB 2 Reserved for future use
DD.SIZ EQU .

So I think you need to also need to take DD.TKS into the equation and DD.FMT (offset $10) which is decoded as:

DD.FMT DISK FORMAT:
BIT B0 - SIDE
0 = SINGLE SIDED
1 = DOUBLE SIDED
BIT B1 - DENSITY
0 = SINGLE DENSITY
1 = DOUBLE DENSITY
BIT B2 - TRACK DENSITY
0 = SINGLE (48 TPI)
1= DOUBLE (96 TPI)

Hope that helps,

Jon.

[pser1]

thanks Jon,
I will use this info for my V2FLO dweeb, but I am pretty sure that the physical disks must have right values in the three firts bytes because they cannot change of size!
So if we have right now a problem with a floppy, probably there is something wrong in these three first bytes.
I will try to add a control on these bits you have mentioned anyway in order to double check the geometry of the floppies too (FLO2V).

By the way, have you taken a look at those bits and bytes on the disk that tried to read past the end?

cheers
pere

[fridgemagnet]

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

so we have a sector count of $05a0, which is 1440 so is an acceptable figure. However offset $10 has bits 0 & 1 set indicating DS/DD.

I think in terms of your V2FLO program, you don't need to worry about sanitising the sector counts since you can create a VDK of any dimension you choose and realistically they are always going to be a floppy disk size. It's going the other way you'd want to have the checks in place for - to only accept those figures that are valid for floppy disks (and of course taking into account the no of sides).