Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

M.E.S.S. emulator

36 views
Skip to first unread message

Roger Taylor

unread,
Nov 16, 2001, 11:10:10 PM11/16/01
to
TIM,

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
---------------------------------------------------

tim lindner

unread,
Nov 17, 2001, 8:54:39 AM11/17/01
to
> 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.

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

Jeff Vavasour

unread,
Nov 17, 2001, 5:51:21 PM11/17/01
to

"tim lindner" <tlin...@IX.NETCOM.COM> wrote in message
news:120611743...@watermarkpress.com...

> 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.

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

tim lindner

unread,
Nov 17, 2001, 9:53:51 PM11/17/01
to
> "tim lindner" <tlin...@IX.NETCOM.COM> wrote in message
> news:120611743...@watermarkpress.com...
> > 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.
>
> 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.

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.

:)

Jeff Vavasour

unread,
Nov 17, 2001, 11:17:23 PM11/17/01
to
"tim lindner" <tlin...@IX.NETCOM.COM> wrote in message
news:1f3155b.1y1rn651qa288iM%tlin...@ix.netcom.com...

> Was there ever anything to determine the number of sides in a disk
> image?

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

tim lindner

unread,
Nov 18, 2001, 9:21:35 AM11/18/01
to
> 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.

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.

Jeff Vavasour

unread,
Nov 18, 2001, 2:31:04 PM11/18/01
to

"tim lindner" <tlin...@IX.NETCOM.COM> wrote in message
news:120602977...@watermarkpress.com...

> 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)

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

will strutts

unread,
Nov 19, 2001, 9:01:19 PM11/19/01
to

"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.


Walter K. Zydhek

unread,
Nov 23, 2001, 8:54:18 PM11/23/01
to
Question.. Is there a typo here?

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

Jeff Vavasour

unread,
Nov 24, 2001, 12:16:57 AM11/24/01
to
"Walter K. Zydhek" <wa...@GIFTMARKET.ORG> wrote in message
news:MJEFJMKGLLCMHCGE...@giftmarket.org...

> Question.. Is there a typo here?
>
> Shouldn't:
> > if (Sector_size == 0) Sector_size = 128;
> be
> > if (Sector_size == 0) Sector_size = 256;

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

0 new messages