adamd@rhi.hi.is (Adam David) (06/27/91)
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)
csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) (06/28/91)
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 ----------------------------------------------------------------------
adamd@rhi.hi.is (Adam David) (06/29/91)
csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) writes: [about reclamation of GEM space] >Much more address range is "wasted" by the generous hardware register >assignments. 32 kB was fine. 1 MB is certainly over-generous on a system with maximum 16 MB address space. The reason that it was 32 kB is presumably so that all the hardware can be accessed using absolute short addressing modes. >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. True, but less data space is available to the program. When we get into multitasking it might be necessary to choose between several non-GEM apps or one GEM one. I do not say GEM is bad or takes too much space, only that it is a pity not to be able to return that space when no longer needed. >lots of other, more important things in TOS that should be improved >before this. Absolutely! >Most of the memory GEM uses is malloc()'ed just like any other memory block. So all that is necessary is to incorporate an exit mechanism in the GEM code. Might this happen someday? -- Adam David. (adamd@rhi.hi.is)