atari800-users — Atari800 users

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

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

> One thing that's absolutely not clear to me is what you want the
> changes for. If you only want bigger ATRs then look at Yogis
> MegaATRs. If on the other hand you want a file that emulates a real
> HD then like we said before you should invent a AHI and put in it
> after the specific header a structure that reflects the one on your
> HD. If you make public documentation of the structure surely somebody
> like Jindroush will write utilities to transfer files to/from it ;-)

In the shortest possible explanation, I want a large disk image that the
emulator handles in a way that you don't need an external, host OS based
utility to format the "disk" for use.  Current ATR support doesn't allow for
that, unless I write my own SpartaDOS format program to run in the emulator
(HDINIT does not work with the stock drive emulation, and the regular format
options are extremely limited on what sizes are available).  With the
extremely simple changes that I've made, SpartaDOS has been able to actually
re-format a couple 16MB disk images that had been corrupted (these were
create with APE and a real Atari to format them).  I would rather not drop
YADIF (yet another disk image format) into a world where we already have so
many that aren't being supported well already.  There are 3 completely
undefined bytes in the ATR header, plus 7 undefined bits in the last byte.
The Atari800 emulator treats that whole byte as the read-only flag.  That's
sloppy programming that leads to more work later if/when more bits/functions
are actually desired/defined/implemented (having to rewrite many things to
stop setting/resetting bits that it shouldn't be playing with).  But, yes, I
do indeed wish to truely emulate a PBI HD (virtual IDE, most likely)
interface, including writing my own PBI code (hopefully allowing a circuit
to actually be built for a physical Atari that could use the same ROM code).

Maybe I'll just do my own thing.  Source always available (I stringly
believe in open source), but completely unsupported.  I'll likely end up
doing exactly what I didn't want to do (writing my own set of utilities to
read/write/create image files).  If I get enough requests for details on my
own modifications and/or file formats, then I can always put them up on my
own web site.  I'm not incapable of doing the bulk of this myself, I'm just
a lazy programmer (I never write a program that I don't need to, unless the
only versions available really suck).

>
> Gerhard
>
> P.S. : I find it very bad that every time I forget to correct the
> return address I send a private mail to a single guy instead of a
> reply to the list. And since I never had that problem before, I do
> forget it most of the time :(

I hear you.  I know we are moving this list to sf.net for convenience, but I
think this type of list which requires special configuration on the reader's
end so that everything works the way we want is actually more of a headache.
Surely we have a better option available.

Nate

>
> _______________________________________________
> Atari800-users mailing list
> Ata...@li...
> https://lists.sourceforge.net/lists/listinfo/atari800-users

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

[Janka G. <ger...@si...>]

Nathan Hartwell wrote:

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

One thing that's absolutely not clear to me is what you want the
changes for. If you only want bigger ATRs then look at Yogis
MegaATRs. If on the other hand you want a file that emulates a real
HD then like we said before you should invent a AHI and put in it
after the specific header a structure that reflects the one on your
HD. If you make public documentation of the structure surely somebody
like Jindroush will write utilities to transfer files to/from it ;-)

Gerhard

P.S. : I find it very bad that every time I forget to correct the
return address I send a private mail to a single guy instead of a
reply to the list. And since I never had that problem before, I do
forget it most of the time :(

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

Re: [Atari800-users] Request: A WinCE Binary

[Petr S. <pst...@so...>]

On Mon, 2001-12-10 at 15:37, Janka Gerhard wrote:
> Petr Stehlik wrote:
> 
> > What about the things that should form an archive? How much of the
> > documentation should be provided together with the binary?
> 
> how about either CHANGES, port specific INSTALL and ( merged ) USAGE
> or a link to a file containing the whole DOC directory 

some sort of documentation has to be included. At least README.1ST,
COPYING, README, USAGE and port specific INSTALL for binaries. Then the
cart.txt, ChangeLog and similar files would be in a separate DOC.zip?

> I would think either every binary seperately

Then I must limit the amount of documentation included because if you
downloaded three binaries (DOS/Direct/Win) and got the documentation
three times it would be wasting of your download time&money.

Petr

RE: [Atari800-users] Request: A WinCE Binary

[Petr S. <pst...@so...>]

On Mon, 2001-12-10 at 00:09, Vasyl Tsvirkunov wrote:
> > It would be great if the port maintainers compiled binary for their
> > respective platform, packed it together in a defined way (I have to come
> > up with something) and uploaded it to upload.sf.net. That way we'd have
> > a release with source and all binaries. That would be cool.
> 
> 
> Sorry, I was very busy lately, missed a lot of action here. WinCE port compiles
> from current sources.

Under Linux?

> I am not sure about the "defined way" -- some platforms are just too different.
> I would say, let's just make some filename convention for the archive and

What about the things that should form an archive? How much of the
documentation should be provided together with the binary?

> may be tricky as not all ports are called Atari800, and there are two different
> Win32 ports. Technically speaking, WinCE port is not one but three ports for
> three different CPUs.

That's another question: whether to pack together binaries (like
svga+x11+framebuffer+sdl, or dos+directx+win32) or whether to offer each
binary separately.

Petr

[Atari800-users] major oops

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

If anyone grabbed my diff file prior to the writing of this message, please
check input.c and remove the "key_code = keycode & 0xFF;" line and the
comment off the line before it. I forgot to remove that before making the
diff.

[Atari800-users] FYI

[Petr S. <pst...@so...>]

-----Forwarded Message-----

From: Marius & Hester <gro...@zo...>
To: Petr Stehlik <pst...@so...>
Subject: emulator for direct x
Date: 10 Dec 2001 13:55:10 +0100

Hi!

Great thing this new version (1.2.0) of the atari 800 emulator - directx. It
is getting better and better everytime I'm working with these new versions
you guys make!

Perhaps an idea to provide the two needed .dll files for this direct x
version? I had to search voor cygz.dll and cygwin1.dll on the net now.

In the "TODO" file you are already writing a thing about joycfg. Did you
know:

The variables added by joycfg to the .cfg file are unknown by the direct-x
version of the emulator?

I get this on the screen when I start it:

Unrecognized Variable: KEYSET_0
Unrecognized Variable: KEYSET_1
Unrecognized Variable: KEYSET_2
Unrecognized Variable: KEYSET_3
Unrecognized Variable: JOYSTICK_0
Unrecognized Variable: JOYSTICK_1
Unrecognized Variable: JOYSTICK_2
Unrecognized Variable: JOYSTICK_3

Please keep doing the great job! It's almost that nice as my 256kb XL!

Greetz,
Marius

[Atari800-users] for those interested and/or wanting my slop

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

Here's a couple web links for people interested in playing with a 65816
enhanced virtual Atari system:

http://www.magelair.com/atari_8bit_stuff.htm - my Atari page
http://www.magelair.com/Atari%208-bit/a8-816.tgz - direct link to the source
diff

Now, if I only had a pseudo-modem to interface this emulator to the net.
I've heard the rumor that it's already been written and "ported" to the
Atari800 source.  But until I get my hands on the source to play with, it
might as well be vaporware.

Nate

[Atari800-users] Turbo-OS (65816 OS ROM )

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

Anyone know if there's a legal issue with free distribution of the Turbo-OS
ROM image?  If there is indeed an issue with distributing images of that OS
ROM, then I shall have to start work on my own 65816 compatible ROM.

[Atari800-users] well, I'll be....

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

65816 emulation is working correctly, now.  The CPU emulation is ported from
the XGS/32 emulator (Apple IIgs).  I "broke" the emulation in trying to
merge the 5 opcode source/object files into one main file.  After pulling
much hair out and taking a lot of time to almost completely adapt the
monitor.c module for 65816 support, I simply could see why it was acting the
way it was.  So, 30 minutes ago, I edited the Makefile to include 5 extra
object files, split the 5 operational modes of the 65816 back into 5 source
file, and found myself able to run SysInfo without a glitch.  I still have
some cleanup to do on the code and need to add some of the advanced feature
support (profiling, tracing, BRK interception, etc).  Plus, I'm going to see
if I can't track down the "errors" that never showed up and get things
merged back into one file (for easier selection between 6502/65816).

RE: [Atari800-users] Request: A WinCE Binary

[Vasyl T. <va...@pa...>]

> It would be great if the port maintainers compiled binary for their
> respective platform, packed it together in a defined way (I have to come
> up with something) and uploaded it to upload.sf.net. That way we'd have
> a release with source and all binaries. That would be cool.


Sorry, I was very busy lately, missed a lot of action here. WinCE port compiles
from current sources. However, considering all latest changes, I would expect
that some things are broken. I hope to have some time soon to test it and add
a few badly needed features.
I am not sure about the "defined way" -- some platforms are just too different.
I would say, let's just make some filename convention for the archive and
settle on archive format used, that should be enough in most cases. Even that
may be tricky as not all ports are called Atari800, and there are two different
Win32 ports. Technically speaking, WinCE port is not one but three ports for
three different CPUs.

Vasyl

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

[Jindrich K. <ku...@as...>]

At 04:39 7.12.2001 -0500, Nathan Hartwell wrote:
>How about A8HI for Atari 800 Harddisk Image?  I would say a fixed 512 byte
>sector size, but no DOS supports it, so it might as well be a fixed 256 byte
>sector size.  So, we have a 32-bit signature (A8HI), a 32-bit sector count
>(but really only use the lower 16 bits), a 32-bit flags variable (read-only
>flag and such), and then optional 32-bit CRC.  Would that cover everything?
>We'd need utilities for creating/importing/exporting a new format, but we
>need a SpartaDOS compatible import/export program anyway.

I'm missing the point of new disk image format. What's bad on std 16MB long 
ATR?

SpartaDOS compatible export program is available on my pages.


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

[Atari800-users] motif and x11-shm targets (was Re: a800s120.tgz - missing configure script?)

[Jiri S. <jir...@ds...>]

On 4 Dec 2001, Petr Stehlik wrote:

> > source code is same for motif (mentioned fixes are regarding to emulator 
> > functions changes outside of atari_x11.c - for example SIO_Mount).
> 
> send me that asap, please.

now i know more...
(patch will be, when more than one line changed :-) )


motif/lesstif:
small fixes, that i did when i tried motif target, i did in version 1.0.7.
now i tried 1.2.0. because of rewrited memory-d.c now motif code miss a 
lot of functions :-(

atari_x11.o: In function `motif_insert_rom':
atari_x11.o(.text+0x1176): undefined reference to `Remove_ROM'
atari_x11.o(.text+0x1197): undefined reference to `Insert_8K_ROM'
atari_x11.o(.text+0x11a7): undefined reference to `Insert_16K_ROM'
atari_x11.o(.text+0x11b7): undefined reference to `Insert_OSS_ROM'
atari_x11.o(.text+0x11c7): undefined reference to `Insert_DB_ROM'
atari_x11.o(.text+0x11d7): undefined reference to `Insert_32K_5200ROM'
atari_x11.o: In function `motif_system_cback':
atari_x11.o(.text+0x1335): undefined reference to `Remove_ROM'
atari_x11.o(.text+0x134d): undefined reference to `Initialise_AtariOSA'
atari_x11.o(.text+0x135d): undefined reference to `Initialise_AtariOSB'
atari_x11.o(.text+0x136d): undefined reference to `Initialise_AtariXL'
atari_x11.o(.text+0x1375): undefined reference to `Initialise_AtariXE'
atari_x11.o(.text+0x1385): undefined reference to `Initialise_Atari5200'

then small fix is now impossible. i will look at it, but i really hate 
this motif code (and some new widgets are needed and i'm absolutely 
unfamiliar with motif programming). at least that i'm now able to 
correctly fix nedeed *configure* stuff.


x11-shm:
for those, who asked for x11-shm version (Piotr Skamruk, but i deleted 
that mail already), only one little fix is needed:


atari_x11.c, line 2608:

original (version 1.2.0):
if( invisible || !draw_display )   goto after_screen_update;  /* mmm */

fixed:
if( invisible )   goto after_screen_update;  /* mmm */


this regarding to change mentioned in atari.h:

Revision 1.18  2001/09/21 17:08:41  fox
removed draw_display, added Atari800_Initialise

same problem with draw_display is in atari_falcon.c and atari_amiga.c too.


			- JirkaS

Re: [Atari800-users] bug...

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

----- Original Message -----
From: "Jacek Popławski" <jp...@in...>
To: <ata...@li...>
Sent: Saturday, December 08, 2001 6:05 AM
Subject: Re: [Atari800-users] bug...


> > can somebady add a posibility to run emulation in full speed
> > (like befor F7 in atari800win-plus). 100% of atari speed is
> > okey, but sometimes some of operations cold be done a bit faster...
>
> I will try.

The CPU modules that I am workign with have a "turbo" patch that I designed.
All I do, when turbo mode is active, is use a static int to count the # of
instructions and performing an xpos++ when a defined instructions per clock
value has been reached.  I currently have that as a #define and limit the
execution speed to 4 instructions per clock cycle.  That pretty much leaves
everything else alone, as far as timings go.  I've had no problems with that
design.

>
> --
> Safe in dreams
> Away from where they are
> Let me be nowhere
> Just another star                            "Feed my head" - Ronnie James
Dio
>
> _______________________________________________
> Atari800-users mailing list
> Ata...@li...
> https://lists.sourceforge.net/lists/listinfo/atari800-users

Re: [Atari800-users] bug...

[Jacek <jp...@in...>]

On Fri, Dec 07, 2001 at 03:19:22PM +0100, Piotr Skamruk wrote:
> there is a bug when yoo want to compile atari800
> with target=x11-shm

Can you explain me why you need x11-shm ?

> 	can somebady add a posibility to run emulation in full speed
> 	(like befor F7 in atari800win-plus). 100% of atari speed is
> 	okey, but sometimes some of operations cold be done a bit faster...

I will try.

-- 
Safe in dreams
Away from where they are
Let me be nowhere
Just another star                            "Feed my head" - Ronnie James Dio

[Atari800-users] Bye

[Piotr F. <P....@el...>]

Hi,

I'd like to inform you, that I unsubscribe the Atari800 mailing list. You
can still reach me by e-mail, of course.

Bye,
Piotr

Re: [Atari800-users] cvs

[Petr S. <pst...@so...>]

On Fri, 2001-12-07 at 15:23, Christian Groessler wrote:
> Hi,
> 
> is CVS also switched to sf? The CVS repository on sf appears empty.

it hasn't been switched there yet. I want to be sure that the current
developers with CVS write access are able to continue working on the new
CVS. Piotr, has you got your login name on sf.net yet? Note that "fox"
is already used by another guy...

> So should I still use an...@so... to get the newest version?

Right now, yes.

Petr

Re: [Atari800-users] Re: request for comments (was Re: sourceforge)

[Piotr F. <P....@el...>]

> > So let's use GNU style:
>
> I checked a couple of GNU packages and found very different ChangeLogs.

That's right. But there's "GNU Coding Standards" doc on www.gnu.org. The
style proposed there looks good IMHO.
>
> > Do you ask me to write about my old changes in ChangeLog ?
>
> You said you would split your entry. I understood that you would do that
> since 1.0.7 changes, at least roughly.

That's right, I'll do it today.

> Actually we would be more
> interested in NEWS (i.e. user related information) since 1.0.7 because
> you did a lot of great things that are unknown for us.

Actually everything is described in CHANGES. Did I omit anything?

Piotr

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

[Piotr F. <P....@el...>]

> As I pointed out before, the ATR header definition in Atari800
> does not match the original definition by Nick Kennedy. I once
> tried to write a definition that would work with either APE and
> SIO2PC ATRs but somehow never succeeded in getting it in the
> official source. But basically, except the meaning of some header
> bytes the two ATR variances are the same.

There's a difference in boot sectors in 256 bytes/sector images (one
character means 128 bytes, digits are sector data, '-' means unused):

APE: 123
SIO2PC: 123---
There's also another scheme: 1-2-3-

Fortunately, all of these are now supported by Atari800.

Piotr

[Atari800-users] cvs

[Christian G. <cp...@al...>]

Hi,

is CVS also switched to sf? The CVS repository on sf appears empty.

So should I still use an...@so... to get the newest version?

regards,
chris

[Atari800-users] bug...

[Piotr S. <jel...@tr...>]

there is a bug when yoo want to compile atari800
with target=x11-shm

there are some old definitions which in rest of some file was
abandoned, but in section containing code 4 x11-shm this definitions
are untouched.

i have some small question...
	can somebady add a posibility to run emulation in full speed
	(like befor F7 in atari800win-plus). 100% of atari speed is
	okey, but sometimes some of operations cold be done a bit faster...

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

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

----- Original Message -----
From: "Janka Gerhard" <ger...@si...>
To: "Nathan Hartwell" <ma...@ma...>
Sent: Friday, December 07, 2001 4:56 AM
Subject: Re: [Atari800-users] Re: monitor.[ch]


> Nathan Hartwell wrote:
>
> > How about A8HI for Atari 800 Harddisk Image?  I would say a fixed 512
byte
> > sector size, but no DOS supports it, so it might as well be a fixed 256
byte
> > sector size.  So, we have a 32-bit signature (A8HI), a 32-bit sector
count
> > (but really only use the lower 16 bits), a 32-bit flags variable
(read-only
> > flag and such), and then optional 32-bit CRC.  Would that cover
everything?
> > We'd need utilities for creating/importing/exporting a new format, but
we
> > need a SpartaDOS compatible import/export program anyway.
>
> Since you want to be compatible to existing DOSes and therefore not
> invent something with new type of file system etc. I think that it
> would be enough.
>
> Gerhard

Well, one of the remaining 31 flag bits could be used for 256/512 sector
selection.  As I'm mainly thinking of the HD image for a virtual PBI drive
controller, the 256 byte SIO limitation would be avoided.  Actually though,
I seem to recall that it was the OS ROM that had the 256 byte limit.  A
"driver", like a PBI ROM, should be good enough to get around that.
Besides, I have a fully operational 16-bit IDE controller design already.  I
just need to throw a PBI interface on it and re-write ROM code.  It's based
on the SmartIDE design by Bob Woolley.

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

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

----- Original Message -----
From: "Janka Gerhard" <ger...@si...>
To: "Nathan Hartwell" <ma...@ma...>
Sent: Friday, December 07, 2001 4:16 AM
Subject: Re: [Atari800-users] Re: monitor.[ch]


> Nathan Hartwell wrote:
> >
> > ----- Original Message -----
> > From: "Janka Gerhard" <ger...@si...>
> > > How about AHI ( Atari Harddisk Image ) ;-) and at least a different
> > > 'magic number' in the first two header bytes too ?
> > >
> > > Gerhard
> >
> > AHI could work.  The header could simple use AHI as the first 3 bytes.
> > That'd still leave room for all the same information in the ATR header
with
> > a few bytes left over.
>
> Yes. I would like it that way. And since I made a mistake writing
> about a two byte magic number, because it actually is four bytes
> you could even put NAHI ( Nathans Atari Harddisk Image ) there ;-)
>
> Gerhard

How about A8HI for Atari 800 Harddisk Image?  I would say a fixed 512 byte
sector size, but no DOS supports it, so it might as well be a fixed 256 byte
sector size.  So, we have a 32-bit signature (A8HI), a 32-bit sector count
(but really only use the lower 16 bits), a 32-bit flags variable (read-only
flag and such), and then optional 32-bit CRC.  Would that cover everything?
We'd need utilities for creating/importing/exporting a new format, but we
need a SpartaDOS compatible import/export program anyway.

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

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

Don't you just hate it when you forget to change the To: field? :)

----- Original Message -----
From: "Nathan Hartwell" <ma...@ma...>
To: "Janka Gerhard" <ger...@si...>
Sent: Friday, December 07, 2001 3:45 AM
Subject: Re: [Atari800-users] Re: monitor.[ch]


>
> ----- Original Message -----
> From: "Janka Gerhard" <ger...@si...>
> To: <a8...@so...>; <ata...@li...>
> Sent: Friday, December 07, 2001 3:34 AM
> Subject: [Atari800-users] Re: monitor.[ch]
>
>
> > As I pointed out before, the ATR header definition in Atari800
> > does not match the original definition by Nick Kennedy. I once
> > tried to write a definition that would work with either APE and
> > SIO2PC ATRs but somehow never succeeded in getting it in the
> > official source. But basically, except the meaning of some header
> > bytes the two ATR variances are the same.
> > In contrary to that, what you propose is a different format and
> > I would think it much cleaner to name it that way to avoid confusion.
> > How about AHI ( Atari Harddisk Image ) ;-) and at least a different
> > 'magic number' in the first two header bytes too ?
> >
> > Gerhard
>
> AHI could work.  The header could simple use AHI as the first 3 bytes.
> That'd still leave room for all the same information in the ATR header
with
> a few bytes left over.
>
> >
> > _______________________________________________
> > Atari800-users mailing list
> > Ata...@li...
> > https://lists.sourceforge.net/lists/listinfo/atari800-users
>

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

[Janka G. <ger...@si...>]

Nathan Hartwell wrote:
> Also, I noticed that the ATR header is processed in such a way
> that the last header byte is used as a read-only flag.  I found a web page
> that listed only bit 0 of that byte is used for read-only, so I adjusted the
> SIO_Mount() code to check that bit only.  Also, I added a definition for bit
> 1 of that byte to make the image look like a hard drive (1 track with x
> sectors).  HDINIT.COM can now format an ATR.  I was thinking of coding the
> 0xEC command (to emulate the IDE interfaces) into the SIO() function.  I
> suppose it'd have to go into the Command_Frame() function, too.  Any
> thought/objections to that idea?  Granted, nothing else uses/supports that
> bit 1 flag for HD mode, but I didn't feel like coding a whole new disk image
> format.

As I pointed out before, the ATR header definition in Atari800
does not match the original definition by Nick Kennedy. I once
tried to write a definition that would work with either APE and
SIO2PC ATRs but somehow never succeeded in getting it in the
official source. But basically, except the meaning of some header
bytes the two ATR variances are the same.
In contrary to that, what you propose is a different format and
I would think it much cleaner to name it that way to avoid confusion.
How about AHI ( Atari Harddisk Image ) ;-) and at least a different
'magic number' in the first two header bytes too ?

Gerhard