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