I'm trying to get the Dragon Beta OS-9 disks from the archive running in MAME, are they known to be good and have they been tested in any way?
These are all DMK images and according to the specification the maximum track size is 0x2940 but all images are actually 0x2980. MAME doesn't yet support single density DMK required for the boot track so that's my first task. The only DMK specification I've found is at http://www.classiccmp.org/cpmarchives/t ... -DMK-disks but the Beta disks don't seem to conform to this as unused IDAM pointers are 0x0080 instead of 0x0000. Am I misinterpreting this or is there another specification I should be adhering to?
Dragon Beta OS-9 disks
Re: Dragon Beta OS-9 disks
Whilst on the subject of floppy images I noticed there's a couple of VDK's in the archive that are single density:
- Dynafast v1.5 (1984)(Compusense Ltd)[!][FLEX]
- Forth Compiler (1985)(NDUG)[!][DELTA]
How can these be supported when the VDK format assumes 18 sector tracks?
- Dynafast v1.5 (1984)(Compusense Ltd)[!][FLEX]
- Forth Compiler (1985)(NDUG)[!][DELTA]
How can these be supported when the VDK format assumes 18 sector tracks?
Re: Dragon Beta OS-9 disks
You're right, the vdk header states that there are 40 tracks and one side but that doesn't match the amount of data stored.
Re: Dragon Beta OS-9 disks
I created the images from copies of the real disks made by Richard Harding. They *USED* to work in MESS at the point that I made the images but as normal with MAME / MESS someone in the intervening time has broken the compatibilityPernod70 wrote:I'm trying to get the Dragon Beta OS-9 disks from the archive running in MAME, are they known to be good and have they been tested in any way?
These are all DMK images and according to the specification the maximum track size is 0x2940 but all images are actually 0x2980. MAME doesn't yet support single density DMK required for the boot track so that's my first task. The only DMK specification I've found is at http://www.classiccmp.org/cpmarchives/t ... -DMK-disks but the Beta disks don't seem to conform to this as unused IDAM pointers are 0x0080 instead of 0x0000. Am I misinterpreting this or is there another specification I should be adhering to?
The way I actually made the images if I remember correctly was to use Sydex Anadisk to make an image that contained the data & sector headers and then use a DMK library that I downloaded (plus some of my own code) to read the anadisk files in and spit out the DMK disks. So it's possible that something either in the DMK library or my code was slightly buggy, sorry if it was my code
Update: here's the code : There are two folders one is the DMK lib I used, the other is the actual anadisk to DMK converter.
Cheers.
Phill.
Re: Dragon Beta OS-9 disks
I think that we should update the vdk spec so that the number of sectors per track and sector size are included in the header.
It would be the easiest way to handle that kind of images. I’ve always found dmk to be quite difficult to generate and work with, having always to use some obscure library which usually don’t work very well either.
That’s my 2 cents.
It would be the easiest way to handle that kind of images. I’ve always found dmk to be quite difficult to generate and work with, having always to use some obscure library which usually don’t work very well either.
That’s my 2 cents.
Re: Dragon Beta OS-9 disks
That would've been when the whole floppy system was rewritten years ago. The Dragon Beta driver looks intact it's just the DMK format that's not been fully re-implemented, I'm on it.prime wrote:I created the images from copies of the real disks made by Richard Harding. They *USED* to work in MESS at the point that I made the images but as normal with MAME / MESS someone in the intervening time has broken the compatibility
If the VDK spec gets updated then I can easily add support for it. But in the meantime I can determine sectors per track from the size of the image: spt = (size - header) / tracks / 256 / sides. Obviously this still assumes sector size is 256.robcfg wrote:I think that we should update the vdk spec so that the number of sectors per track and sector size are included in the header.
Last edited by Pernod70 on Sun Jan 07, 2018 12:59 am, edited 1 time in total.
Re: Dragon Beta OS-9 disks
From the notes in MAME:
So which is the boot track that is supposed to be single density? A quick scan of the OS-9 DMK doesn't have any tracks marked as single density.
Code: Select all
Fixed density setting on WD2797, so density of read data is now
correctly set as required by OS-9. This was the reason startup
script was not being executed as Beta disks have a single density
boot track, however the rest of the disk is double density.
Booted completely to OS-9, including running startup script.
Re: Dragon Beta OS-9 disks
Track 0 head 0 IIRC. Rest of disk is standard 18x256.Pernod70 wrote:From the notes in MAME:So which is the boot track that is supposed to be single density? A quick scan of the OS-9 DMK doesn't have any tracks marked as single density.Code: Select all
Fixed density setting on WD2797, so density of read data is now correctly set as required by OS-9. This was the reason startup script was not being executed as Beta disks have a single density boot track, however the rest of the disk is double density. Booted completely to OS-9, including running startup script.
Cheers.
Phill.
Re: Dragon Beta OS-9 disks
Who actually has these Beta OS-9 floppies? Could they be re-imaged in a more suitable format such as HFE?