Dragon OS9 with drivewire support

[pser1]

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.

You are right, but I haven't used /tried any of this kind of disks.
This 'special case' should come as total sectors = $5A0 (offset 0-1-2), sectors/track = $12 (offset 3), $2 for just one side (offset 16)
And to compensate, offset 7 must be $2 or we will not get to 1440 sectors anyway.

What my dweeb does in this case is create a VDK that is double sided instead of double track density, the same amount of sectors ... I will format a disk like that
DSKINIT1,1,80 and copy there some files.
Then I will transfer it to a VDK file to see how it has been created ... will let you know

cheers
pere

[pser1]

Hi Jon,

last tests I have done were quite a nightmare!
I did format a disk in my Dragon: DSKINIT1,1,80 and it created a 360K disk.
When I sent it to DW4, I got a VDK that once opened with XRoar showed to be 360K too, great.
But it had in the header the values $28,$02 (40 tracks, 2 sides) mainly because this is what my dweeb sends
I had copied files before copying the disk through Drivewire and the copied disk was working perfect despite this 'changes'.
As soon as I changed those bytes to $50,$01 (80 tracks, 1 side) as I assumed it was the original, when I made DIR
I just got an IV ERROR message!
Further, if I create a new disk in XRoar and try to do DSKINIT1,1,80 it creates a 180k disk, but the created file is 368.652 bytes (as a normal 360k disk)
I close Xroar, open it again and load that disk, then write DIR just to get again 175104 bytes free
This was done with DDOS11C and/or DDOS12A
When initializing the disk with DOS4.1 (Eurohard) then I get a formatted disk with ... 359424 bytes!!
So it seems a DOS problem.
My disk controller is one of Lafumat's so it has Eurohard DOS inside ... that's why it creates a correct disk with DSKINIT1,1,80
So I have looped back to the beginning ... I sould have to do some more tests but using the Eurohard DOS version on XRoar to see how those 1,1,80 disks will work

cheers
pere

Ps I am thinking of forgetting about that 'strange' format 360K on one side (SS-DD), as th normally used one is (DS-SD)

[fridgemagnet]

Hi Pere,

It's always fun(?) when you make a minor tweak and everything collapses in a big heap.. Anyway here's my thoughts on what I think it is you are seeing:

I did format a disk in my Dragon: DSKINIT1,1,80 and it created a 360K disk.
When I sent it to DW4, I got a VDK that once opened with XRoar showed to be 360K too, great.

Now if this this was in a standard 80T/DS drive then AND the disk in question had already been formatted in the normal (ie. 80T/DS) manner then the other side will remain valid -from a magnetic media perspective anyway. So if you then copied this using your existing DWEEB which I don't think takes into account this, then I think you will have actually copied only the first 40 tracks but side 1 and 2 - you can in fact check this by doing examining the track register in the WD2797 after the copy (think it's $FF41), you would expect it to be 79 but I bet you'll get 39.

So from a directory perspective, that will still look ok because the directory is on track 20, side 1 so it would have appeared to copied correctly.

As soon as I changed those bytes to $50,$01 (80 tracks, 1 side) as I assumed it was the original, when I made DIR
I just got an IV ERROR message!

That would make sense because you've totally changed the geometry, what you've copied is 40T/2 sides not 80T/1.

Further, if I create a new disk in XRoar and try to do DSKINIT1,1,80 it creates a 180k disk, but the created file is 368.652 bytes (as a normal 360k disk)

That as you say sounds like a DOS issue.

Ps I am thinking of forgetting about that 'strange' format 360K on one side (SS-DD), as th normally used one is (DS-SD)

I'm with you on this one, maybe worth parking as a "future enhancement" thing.

For me, it'd be useful to get the double sided issue sorted with DOSPlus, I'm happy to mod it myself if you want but I think I'll need the original DREAM assembler file (I'm assuming you are using that?) to work with as I don't think (or I've probably forgotten!) you can load a pure ASCII file into the tool, .drm files are formatted somewhat differently.

I think it just needs the sector count specified each time round the copy loop - as per my os9copy program.

Rgs,

Jon.

[pser1]

Hi Jon,
I could simply say yes ... to all of your notes.

Certainly my dweeb does tweek the geometry of that ugly format and sends it out wrongly. That's a point to change in the future ...

Concerning the DOS, I have only the ascii files I attached the other day.
I am not willing to use DREAM any more, I feel very comfortable with ASM6809 (Ciaran's compiler) it is really very fast and you can work
with ASCII files. Once compiled it is easy to load into XRoar and if needed saved to disk.

About DosPlus4, I will have a look at my source code (yes, it was Dream originally) and will add in the read sectors loop the sentences
that will assure the geometry is updated before every read order.
Let me a bit of time ... as soon as I have something I will upload it here so that you could have a peek at it before publishing the new versions
of both dweebs

Thanks a lot once again

cheers
pere

[fridgemagnet]

Hi Pere,

No rush at all.. I need to start having a play with some of the cross compilation/assembler tools, I can imagine it makes life significantly easier than being restricted to the fairly basic editing capabilities available on the old machine itself.

Cheers,

Jon.

[fridgemagnet]

On this point raised earlier by Pere:

I have the file "nos9v303_d64COHR_becker.dsk" mounted as Disk0 in DriveWire
Then I start XRoar without DDOS or with DDOS11C
When I enter
DLOAD"DOS"
The screen shows the message "NITROS9 BOOT"
But nothing happens on the screen, it simply hangs the computer.
But ... if I do that with HDB-DOS installed in XRoar, it starts perfectly with both sentences:
DOS or
DLOAD"DOS"
So, what am I doing wrong?
I don't know why 'must' I have HDB-DOS installed to start NitrOS-9 ...

Ken told me on another thread that the DW variants of Nitros OS-9 for the D64 are very much based on the CoCo2 fit (hence why they include the CoCo floppy controller module not the Dragon's). I can't add much more to this other than to say I've encountered the same issue (that it only seemingly only works if HDB-DOS is loaded) but also that I get a similar effect if I attempt to remove the CoCo disk controller from the OS9 boot modules. This leads me to think that it is not so much that you need HDB-DOS for it to work but rather that XRoar must provide the emulation capabilities for the CoCo's floppy controller and that there is something lurking in the boot modules which needs this.

I've semi-proven this - my xroar config for Dragon with HDB-DOS support looks like this:

-default-machine dragon64
-becker
-becker-ip 192.168.0.201
-becker-port 65504
-cart dgnrs
-cart-type rsdos
-cart-becker
-machine-cart dgnrs
-kbd-translate
-cart-rom hdbdw3dgn64becker.rom
-romlist d64_1=d64-dwload-becker.rom

Now if I remove the 'cart-rom' line from the configuration ie. take HDB-DOS out of the equation but leave the controller present in the emulator, I can now successfully boot into OS9 using DWLOAD "DOS".

[tormod]

The default address for the Becker port is FF41/FF42. This clashes with the Dragon DOS controllers. Therefore XRoar moves the Becker port to FF49/FF4A if it believes you are using a Dragon DOS ROM. I think this is what happens here. I will send Ciaran a patch to display the Becker port address when enabled to make it easier to catch such issues.

[fridgemagnet]

The Becker port address was the other thought that cross my mind during this process because it's not entirely clear to me how all this is managed. I thought the default address was $FF41, which moved to $FF50 when a DOS cartridge was enabled however obviously the software has to know about this as well hence the switches in the DW assembler code and there is a mismatch between the settings between DOS & the NitrosOS9 sources.