Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!sol.ctr.columbia.edu!ira.uka.de!fauern!faui43.informatik.uni-erlangen.de!csbrod
From: csbrod@immd4.informatik.uni-erlangen.de (Claus Brod)
Newsgroups: comp.sys.atari.st
Subject: Re: Was: How is Atari doing in Europe?
Message-ID: <1991Jun27.171831.15580@informatik.uni-erlangen.de>
Date: 27 Jun 91 17:18:31 GMT
References: <1991Jun14.010821.9903@noose.ecn.purdue.edu> <5360@syma.sussex.ac.uk> <1991Jun17.190053.7342@clinet.fi> <3283@krafla.rhi.hi.is> <1991Jun21.104233.24151@informatik.uni-erlangen.de> <3300@krafla.rhi.hi.is> <1991Jun26.124900.5744@informatik.uni-erlangen.de>
Organization: CSD., University of Erlangen, Germany
Lines: 66

adamd@rhi.hi.is (Adam David) writes:

>Yes, I've used this. Trouble is, I want to be working with non-GEM and GEM
>programs. On a 68000 there is not _very_ much available memory space. Because
>there is (almost) no distinction made between user and supervisor spaces
>and because code=data space, it is not possible to get a full 16 MB of user
>RAM. Therefore the ROM and RAM must compete for available address ranges.
>When GEM is running, there is space taken by the GEM variables and data
>structures. So far it has not been possible to deinitialise GEM and reclaim
>this space without a reset. If GEM is in ROM, the space taken by the GEM code
>cannot be reclaimed either. 256k might not be considered very much memory
>any more but it's enough for one more full-blown application process or
>for one of the non-GEM applications to handle more data in memory at once.

Much more address range is "wasted" by the generous hardware register
assignments. No, I don't think this is a serious restriction. At least,
I don't know a single application that would run on a 1 MB ST without
GEM and doesn't because GEM installs its own data areas. It wouldn't be
bad to reclaim the space GEM allocated for itself, but I think there are
lots of other, more important things in TOS that should be improved
before this.

>>The current TOS versions cannot handle a physical sector size of 1024
>>bytes. It's not unreasonable to suppose that this won't ever find its
>>way into TOS again due to compatibility problems.

>Conceptually there is the same problem with supporting HD floppies.
>In the one case it can be fixed in hardware, in the other case it needs
>a software fix. In either case the newer format cannot be used by the
>older machine without modification.

The difference is: DOS machines won't understand 1024-byte-sectors.
And file system compatibility has always been of some importance
for Atari, as it seems.

>>As I stated a while ago, I tested a third-party floppy driver some time
>>ago which offered 1024-bytes-per-sector support.

>Is this available anywhere? I simply don't have the time right now to write
>my own floppy driver, but would like to move to this format.

Not yet - as far as I know. I don't know what the author did with it.

>Yes, and some parts of the assembler generated code will need to be protected
>from the optimiser. Even in 1.62 there are software timing loops. There might
>also be certain race conditions which must be avoided.

Even TOS 3.01 seems to have timing loops. When moving TOS 3.01 to TT-RAM,
thus speeding it up by 20 to 40 percent, sometimes you get problems
when reading and writing HD disks ("data corrupted" alerts and the like).
I think this is due to some tight timing loops that break in the fast
part of RAM.

>About a possible RAM-based GEM. Is it not reasonable to have a GEM which
>allocates its data memory somewhere other than below the TPA base address?
>This would seem to offer more flexibility in initialising and removing GEM
>(maybe several times) during the same work session.

Most of the memory GEM uses is malloc()'ed just like any other memory block.

----------------------------------------------------------------------
Claus Brod, Am Felsenkeller 2,			Things. Take. Time.
D-8772 Marktheidenfeld, Germany		 	(Piet Hein)
csbrod@medusa.informatik.uni-erlangen.de
Claus_Brod@wue.maus.de
----------------------------------------------------------------------