Re: [Atari800-users] Re: monitor.[ch]

[Nathan H. <ma...@ma...>]

----- Original Message -----
From: "Jindrich Kubec" <ku...@as...>
To: "Nathan Hartwell" <ma...@ma...>
Sent: Monday, December 10, 2001 4:50 PM
Subject: Re: [Atari800-users] Re: monitor.[ch]


> At 17:46 9.12.2001 -0500, Nathan Hartwell wrote:
> >Well, it's either create a new image format, or re-write the image
mounting
> >code so that all images (or images over a certain size) activate hard
drive
> >code.  Why is this important?  Well, as I thought I'd already said, the
> >emulator is hard coded to return 40 tracks, 1 or 2 heads, and total
sector
> >count divided by 40 as the sectors per track.  That kills any possibility
> >for true hardware emulation, and prevent any DOS that I know of from
being
> >able to format an image (whether it was corrupt, was newly created and
has
> >no format, or simply contains a lot of data that you don't need anymore).
> >Right now, I do have a modified ATR header that activates the proposed
hard
> >drive changes.  According to data I've seen, the Atari800 emulator is
using
> >a whole byte as the read-only flag when only bit 0 of that byte was
defined
> >for that purpose.  I changed the code to reflect the bit 0 usage and
added a
> >bit 1 definition.
>
> So far, so good. This is good solution, I think.

And there's plenty of growth available in the ATR header, if people support
it properly.  Which is why I've stuck with a modified ATR format for now.

>
> >   The problem is, while I have no problem manually hex
> >editing the image file(s) to enable/disable hard drive mode, no other
> >software supports my modification.
>
> Since there is no 'hard drive 2 pc' ;) it's not a problem I think. Also
APE
> can't emulate BlackBox or whatever. And you could contact Dan Vernon to
> have that incorporated into Atari810 (open source APE clone).

I was more concerned with current ATR utilities resetting the hard drive bit
and forcing the user to turn it back on.  Maybe I could write a quick and
dirty perl script just to do that (that way it'd be portable to just about
all platforms).

>
> >  Plus, the ATR format is limited to
> >128/256 bytes per sector,
>
> Why? There's a word where's usually 0x80 or 0x100. No problem to have
0x200
> there. And size of file could be up to 256 MBs (which is enought,
methinks)

Well, everyone seems to think that SIO is limited to 256 byte data
transfers.  Just because the stock OS ROM SIO code only supports 128/256 and
no DOS currently tries 512, that doesn't mean that 512 byte sectors are not
allowed.  Any DOS that has it's own UltraSpeed SIO code could easily support
a 512 byte sector.

>
> >I'm not saying that anyone
> >has to use the new format.  If you're perfectly satisfied with having to
use
> >external software to create and format all disk images, then by all mean
> >stick with ATR files.  I'm going to write my own format for my own
personal
> >use.  If anyone else wants it, that's fine.
>
> I don't think that's true. Another format - another need for external
> utilities, convertors, documentation, support in existing programs etc.
> Look at the situation now, we have XFD, ATR, APE-ATR, DCM, DI, SCP. Isn't
> that enough?

Then let's get the ATR community in on a few changes.

Nate

>
>
> Jindroush (ku...@as...)
> For Atari utilities look here: http://www2.asw.cz/~kubecj
(jindroush.atari.org)
>