I thought I read where you are using the size of the .dsk file to determine
how many tracks or sides the disk file has. The emulator should not do
this, nor your FD502 driver. Let the software we run control this. If a
.dsk file is too small then make your FD502 driver report an error if OS-9
or DECB tries to read too far. Just point to an offset in the file based on
our track# * sectors_per_track * side#. It seems to me that would solve all
of your problems. Maybe I'm wrong. But the emulator itself should
definately not know how many tracks or sectors or sides a disk image has...
that's the operating system's job.
Also, I experimented with setting /d1 to typ=80 using DMode, and did a
"format." It warns of a hard disk format. The verify process works for a
while then reports error #247 continuously, even when your biggerdisk.dsk
file is mounted to /d1. Weird.
Anyway, keep up the good work. I'm looking forward to a fully-functional
6309 CoCo on my laptop.
---------------------------------------------------
Roger Taylor
---------------------------------------------------
Wrong.
The disk image handling code in MESS does need to know the geometry of the
disk. Since the JV1 disk image format doesn't contain internal hurestics, we
need some algorithim to determine the geometry.
If you started using DMK disk images, then there would be no guessing
involved. Too bad there are not better tools for the PC to do this.
--
tim lindner tlin...@ix.netcom.com
"Life. Don't talk to me about life." - Marvin, the android
Actually, my disk format allowed for "varied geometry" by way of an optional
header. Divide the virtual disk file size by 256. The remainder is the
header size. The first byte of the header tells you how many sectors per
track. If there is no header, 18 SPT is assumed.
AFAIK, the format others refer to as JV1 was my single density Model I
Emulator format (10 SPT) not the CoCo format (18 SPT).
- Jeff
Ok, that makes sense. I will get this tidbit into MESS. That means the
'BiggerDisk.zip' file I have on my web site is wrong.
Anybody out there that has a copy of "BiggerDisk.zip" should delete it.
Was there ever anything to determine the number of sides in a disk
image?
> AFAIK, the format others refer to as JV1 was my single density Model I
> Emulator format (10 SPT) not the CoCo format (18 SPT).
I did get that from Tim Mann's web site. I will use the long form from
now on.
:)
Each side was stored in a separate .DSK file.
Though FWIW, the header was designed with future expansion in mind even though
only one byte was ever defined. If there was ever a desire to do so I
probably would've defined additional bytes for sides, bytes per sector, first
sector of track (if other than 1), and maybe extended properties (CRC errors
and the like).
Here's my recommendation:
Make byte 2 of the header be # of sides (default 1), byte 3 be sector size
divided by 256 (default 1 with 0 meaning 128 bytes/sector), byte 4 be first
sector of track (default 1), byte 5 non-zero if there is a sector attribute
map (default 0). The sector attribute map would contain one byte per sector
indicating whether a read property such as read protect, CRC error, etc.
applies to that sector, and would come immediately after the header. The bit
positions for these sector attributes would be the same as their positions in
the FDC status register that results from a read.
- Jeff
Ohhh. This is nice.
So to clear up one last bit. If the header size is zero then:
if HeaderSize = (fileSize % 256) = 0 then
Sectors per track = 18
Sector id start = 1
Sides = 1
Sector size = 256
Tracks = fileSize / (18*256)
This is much better than the hack I was using.
Not quite. You have to allow for variable-sized headers and future expansion.
It's more like:
HeaderSize = fileSize % 256;
Sectors_per_track = 18;
Sides = 1;
Sector_size = 256;
Sector_id_start = 1;
Has_attribute_ byte = 0;
if (HeaderSize > 0) Sectors_per_track = file[0];
if (HeaderSize > 1) Sides = file[1];
if (HeaderSize > 2) Sector_size = file[2];
if (HeaderSize > 3) Sector_Id_start = file[3];
if (HeaderSize > 4) Has_attribute_map = file[4];
if (Sector_size == 0) Sector_size = 128;
if (Has_attribute_byte == 0)
Tracks = (fileSize - HeaderSize) / Sector_size;
else
Tracks = (fileSize - HeaderSize) / (Sector_size + 1);
Data_starts_at = HeaderSize;
So, a header of size 1 leaves everything but SPT at the default. This also
avoids a total breakdown when encountering a header of size 10, too. I did
change one thing from my previous post. I think it's better if the read
attributes (if present) go at the top of each sector rather than as one big
table at the top of the file. So if Has_attribute_map is set, the .DSK
contains 257 bytes per sector (or whatever size + 1) with the first byte being
bits to XOR into the FDC's read status.
We can call this format JVC. :-)
BTW, to reduce the amount of spam I'm getting, I tend to post under a dead
account name. If you want to email me, you can find my address at
http://www.vavasour.ca/jeff (Yeah, I know web pages get scanned for spam
lists too, but it's worse on the Usenet.)
- Jeff
"Jeff Vavasour" <je...@physics.ubc.ca> wrote in message
news:Y%TJ7.48312$Ud.23...@news1.rdc1.bc.home.com...
BTW, to reduce the amount of spam I'm getting, I tend to post under a dead
> account name. If you want to email me, you can find my address at
> http://www.vavasour.ca/jeff (Yeah, I know web pages get scanned for spam
> lists too, but it's worse on the Usenet.)
>
> - Jeff
>
>
That's why I have the "nospam" in my email signature. I was getting
a lot of crap too.
--
--
William R. Strutts - wrstr...@nospam.home.com - Whatever!
C'est moi! http://www.facelink.com/wrstrutts
Just hacking away...
Remove nospam to reply.
Shouldn't:
> if (Sector_size == 0) Sector_size = 128;
be
> if (Sector_size == 0) Sector_size = 256;
And should:
> if (Has_attribute_byte == 0)
> Tracks = (fileSize - HeaderSize) / Sector_size;
> else
> Tracks = (fileSize - HeaderSize) / (Sector_size + 1);
be
> if (Has_attribute_byte == 0)
> Sectors = (fileSize - HeaderSize) / Sector_size;
> else
> Sectors = (fileSize - HeaderSize) / (Sector_size + 1);
or
> if (Has_attribute_byte == 0)
> Tracks = ((fileSize - HeaderSize) / Sector_size) / Sectors_per_Track;
> else
> Tracks = ((fileSize - HeaderSize) / (Sector_size + 1)) /
Sectors_per_track;
Forgive me if I am mis understanding..
-Walter K. Zydhek
No. It wasn't a typo. Sector_size == 1 gives 256. 0 giving 256 would be
redundant. However, this has been revised to:
Sector_size = 128 << value;
>
> And should:
> > if (Has_attribute_byte == 0)
> > Tracks = (fileSize - HeaderSize) / Sector_size;
> > else
> > Tracks = (fileSize - HeaderSize) / (Sector_size + 1);
>
> be
> > if (Has_attribute_byte == 0)
> > Sectors = (fileSize - HeaderSize) / Sector_size;
> > else
> > Sectors = (fileSize - HeaderSize) / (Sector_size + 1);
That was a typo. Tim's website has the corrections.
- Jeff