New GOS for running games from hard disk & new driver versions

Started by Petari, 09-02-2011, 14:08:10

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

Petari

I working at moment seriously on my old idea, and actually final revision on hard disk drivers combined with support of gaming from hard disks.

The whole idea/concept is that hard disk driver and filesystem driver (GEMDOS) work complete independant from MFP and complete in high RAM.
It means that then we can have hard disk accesses during gameplay almost same as floppy access  - without even disabling interrupts and any MFP changes, sampling and similar.  I already did succesful tests with 2 games and ACSI driver. So, it is workable way.

But it needs special driver, which is also MFP and low RAM, vector independant. So, it will work only with my drivers, latest revisions.
The benefits:  faster loadings, no interrupts during disk accesses, no flashing. More reliable work. Less RAM usage.
I will post new hard disk image with some 60 games in weeks....
  •  

johnz

is it ok for 1 go partitions? what about the ct63 compatibility? a new boot interface is in work?
it seems to be very interesting that new release :-)
  •  

munchy

  •  

Petari

Some details, explanations more:

It will not work with 1GB partitions, and not with Hddriver. As already said it needs special driver - so only mine will be OK for. Therefore no 1GB support.  I could do it easy in fact - it is just couple parameters setting and similar. But don't see much use of it - it would be usable only on Falcon.
But I don't plan SCSI driver for Falcon, only IDE. 14x 512 MB gives total 7GB, what is more than enough for all games and other SW.

Actually, new concept is best for people with ST(E) and not much RAM (1MB).  Falcon users can use it too, but only with IDE drives (best with CF cards) and mine driver, so 512MB/part. max.
The another reason for 512MB limit is that I still use TOS 1.04 core for hard disk access from games.
It is reliable, can work complete independent from MFP and interrupts, what is not case with TOS 2.06 or 4.xx (Falcon TOS). For gaming it is ideal, I say - reliable, enough fast etc.

Some technical details:  to play from hard disk games which perform disk access (loadings) during gameplay  and are placed in very low RAM we need solution which resolves conflict with low RAM usage:
since TOS (GEMDOS) is tied to low RAM too both can not work at same time, from same RAM
Oldest solutions were using RAMdisk for storing floppy data and FFLS driver. RAMdisk is fine and fast solution, but needs RAM, so usually 2 MB min RAM is needed. But for multifloppy games even 4MB can be unufficient.
FFLS is special hard disk and FAT16 filesystem driver, which uses little RAM and can run in high RAM. Made by crew Superior around 1992. There is a number of games what uses it (I guess about 50), and it is fast enough.  But has some serious limits:  max 32MB partitions and only ACSI attached drives on ST(E). Plus, it is read only, so no saves possible on hard disk.
Then we have WHDload (Amiga) and it's Atari clone ULS. It resolves low RAM conflict by swapping low and high RAM by every disk access performed during game. Since there is 150-400 or even more KB for swapping it may be slow in case of many short disk accessings.

What I made is similar to FFLS - so hard disk driver and FAT16 filesys driver in high RAM, but without mentioned limitations. So, read and write. Max 512KB partitions. ACSI and IDE attached drives ( + will be usable with CATA and ACSI-CF).  It is fast because no large RAM swaps.
Instead writing FAT16 driver from 0 in assembler I use reassembled and modded TOS 1.04 core. Btw. TOS 1.04 core is used for many other games, working not in low RAM and not with direct floppy access - for resolving TOS version compatibility problems. So, I disassembled TOS 1.04's GEMDOS with 2 things in mind.

Current version of ingame hard disk access, called GOS 5 is still MFP and little low RAM dependant. There are smaller slowdowns by sampling MFP timers for instance. Then, usage of Trap calls in GEMDOS means that very low RAM (first 1KB) is still shared.
To achieve comlete MFP and very low RAM independent ingame hard disk access we need:  hard disk driver working total independent from MFP, vertical blank and other interrupts, then fully PC-relative code and care about not using low RAM for buffers (so move TOS disk buffer up too).
Then, GEMDOS FAT16 filesys driver must fullfill same conditions - so no Trap calls at all. It required some code part rewritings, changing complete workspace location etc.
Finally, game launcher must cowork with all above well.  The good thing is that now only 1 file is OK for ST(E)s and Falcon too (no stack frame problems more, as no Trap calls). Plus I solved that same file is good for all games, RAM usages.

Conclusion:  all it was pretty much work, done during some 20 months gradually. Please accept it as is.
I achieved what wanted - fast and reliable work (for now tested with 6 games on ST(E)s and Falcon).
No sound interrupts and flashings during loads. And all it with 1MB RAM in machine.

I thought about writing complete new FAT16 filesys driver in assembler, which would work with DOS and TOS type partitions up to 2GB. But is is really very hard, and writing some 30KB of such ASM code is almost insane. Some said that is not possible in ASM, only in C (as is done in TOS self). Plus, don't see much sense - 512MB limit is good for me. And I solved already DOS/TOS compatible partitioning with 14 partitions max.
Maybe will do when will retire :-)

  •