Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!yale.edu!cmcl2!uupsi!sunic!isgate!krafla!adamd
From: adamd@rhi.hi.is (Adam David)
Newsgroups: comp.sys.atari.st
Subject: Was: How is Atari doing in Europe?
Message-ID: <3312@krafla.rhi.hi.is>
Date: 27 Jun 91 13:53:11 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: University of Iceland
Lines: 59

csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) writes:

>If you like, you can work without GEM on your ST today. Just place a
>command shell into your AUTO folder. Isn't MiNT meant just for purposes
>like these?

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.

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

>It isn't even sure that new machines will have a 1772 built-in
>that offers such capabilities.

Maybe not, but we can be reasonably sure that any typical FDC will be
able to handle several sector sizes, including 1024-byte.

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

>>Optimisation could be made almost automatic, the only handwork necessary
>>would be to mark which parts of the code must not be changed because they
>>are in some way critical.
>
>The time-critical sections are already written in assembler, especially
>the BIOS and the lower screen driver routines. They could and should 
>be faster, however.

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.

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.

--
Adam David.
(adamd@rhi.hi.is)