Xroar and .dsk images - bye bye header?

A place to discuss everything Dragon related that doesn't fall into the other categories.
Post Reply
bluearcus
Posts: 147
Joined: Wed Sep 07, 2016 4:45 pm

Xroar and .dsk images - bye bye header?

Post by bluearcus »

Hi all,

I've been doing quite a lot of switching between using Xroar with the inbuilt disk emulation and with drivewire and have noticed something a bit odd.

In order to use VDK images in Drivewire, I've been butchering the headers down to 8 bytes or so and making DSK versions, in line with the info in the 'Preservation' wiki page.

However, if I then use the DSK version in Xroar, and enable writeback, then the header gets removed and a headerless DSK file (effectively a raw disk image) is produced.

Anyone see this as a problem? With the Os9 tinkering I'm doing at the moment I often leave disks open in both DW and Xroar native (I know, lazy) and I wonder if it could result in unexpected corruption?

Would it be worth making the Xroar DSK writeback preserve the header segment where one exists?

Cheers,

Mike
pser1
Posts: 1665
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Re: Xroar and .dsk images - bye bye header?

Post by pser1 »

Hi Mike,
I see you are suffering the same nightmare we suffered some time ago when beginning
to work with drivewire.
As drivewire was thought to wotk in CoCo machines, it acceptes ONLY files that have a lentgh multiple
of 256 bytes (sector oriented server). This means that our VDKs with a header of variable length had
to be changed ... to a whole sector length: 256 bytes. That way drivewire recognizes the disk ... but it
must be guided in order to skip the first sector (header) and because of that, we must always ask for
sector N+1 when we want sector N.
That is why I wrote the DosPlus50 extender, to work as an intermediate step between the DOS
commands and the Drivewire server. It was a painful project because some commands had to be
intercepted and worked on the extender like the DSKINIT that issues track commands to the
WD2797 and DW cannot support that!
Then I added to the pack a set of tools to manage the contents of the nice module CoCo-SDC and so
making it possible for the Dragon users to benefit that hardware and put inside their own disk images

At the beginning, we were forced to 'cut' the header and so convert our VDKs into DSKs, but as
this worked, most of us accepted this forced 'double' collection.
I talked to Darren Atkinson and he kindly agreed to modify the firmware of the CoCo-SDC to give
support for VDK images with any header length between 0 and 256.
And now we are happy having a single copy of our disks in VDK format, that can be used in XRoar too!

If you can 'live' working in the realm of DosPlus5.0 then I recommend you to try my DosPlus extender.
You can download it from here and you can even have a look at the project history ...
viewtopic.php?f=5&t=5363&start=50#p14945

The link points the the end of the thread so that you can access immediately the file to be downloaded
If I could be of any help, just let me know ...

cheers
pere
pser1
Posts: 1665
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Re: Xroar and .dsk images - bye bye header?

Post by pser1 »

bluearcus wrote:Hi all,
Would it be worth making the Xroar DSK writeback preserve the header segment where one exists?
Mike
I use XRoar with writeback enabled and it has always preserved the headers.
In fact it changes the signature (byte) that indicates the program that has created the image.
Most of my images have headers 256 bytes long, but the very old ones are still the old style with 12 bytes length I believe.

cheers
pere
sixxie
Posts: 1348
Joined: Fri Jul 18, 2008 8:36 am
Location: Hertfordshire
Contact:

Re: Xroar and .dsk images - bye bye header?

Post by sixxie »

FWIW XRoar should write out only as much header as required. So if it's an 18 sector single-sided 256-byte disk, it'll write it with no header at all, as those are the defaults. Should probably make it note the values on initial read and rewrite the header if they've not changed...
Post Reply