Ways of making SW for Atari ST, TOS more efficient, less RAM hungry

[ParanoidLittleMan]

Currently I working on new game starting menu SW, what will not work via changing DESKTOP.INF file. That will need some special 'hackish' way in cowork with TOS to achieve that will have opened game's DIR in Desktop, while did not start game from there.

And it reminded me about how useful is to know TOS characteristics very good - because that helps in making - as title says: more efficient, using less RAM ..  Well, some may say that RAM usage not really relevant, when you have like 4 MB . Not correct for all SW - some SW just don't like when lot of low RAM is occupied, and will fail. It stays mostly for games. And there is plenty of games which also don't use RAM well.

 

1.  Executables with extension TOS use less RAM than those with ext. PRG , and therefore start on lower address. Diff is about 20 KB, depending from TOS version. Not much, but sometimes it is matter of work or not work.  And here to add that after exiting PRG, and running TOS after it, it will start at same address (+14 bytes) as where PRG started - as result of simplified memory management of TOS. So, reset sometimes may be useful.

Now, there are plenty of games and other SW which have main exec as PRG - often without any or real need. Some can rename to TOS and will work flawless.  More often there are some AES calls of simple things - like reading mouse, some graphic op. which can be done with functions which work in GEMDOS - you don't need AES for mouse, it is operative in GEMDOS too (like AUTO run SW), just need to init it - there is XBIOS call for it. Line-A emulator works in GEMDOS too . Etc ...

And AUTO run will save even more RAM that using TOS ext. from Desktop . Like 60 KB (only if you are faster than light), or about 36 KB in compare to run PRG from Desktop.

 

2. Everyone knows that coding in ASM will result in shorter exec. Diff depends a lot from used compiler, from programming style, experience ...

 

3.  I really don't like CONTROL.ACC, XCONTROL ...  they perform simple tasks, often are resident in RAM, are coded in C mostly. With compilers which for instance put longer routine lib. in exec, while most of it is never called by concrete PRG - yeah, should work more on such things ...  So, selection of C compiler may result with more efficient, shorter code.  I can not say which are better - never used C with ST. But saw lot of machine code generated by them.

 

4. Starting another exec from running exec:  there is plenty of games where I saw it - like one, usually not much long exec - like for displaying title screen, some anim or whatever starts first, and when finished it starts main exec of game.  Of course same can see with 'serious' SW too.

And how it starts other exec ? Of course using pexec trap #1 call.   However, there is one 'little' problem:  RAM area allocated by first exec will be not freed, and there will be less RAM for main exec available (well in rare cases, some used it somehow) .

And there is really not too complicated way to use RAM better:  solution is to not use pexec, but to load second exec at same RAM loc where is first, relocate it, correct basepage values, and jump to start address.  Code for it is about 250 bytes, ASM of course.

 

Finally to add:  Dungeon Master would not work with 512KB STs if they did not take care and use some of methods suggested here.

Yeah, some can say now: who cares about 512 KB Atari STs now ? Well, they are still used by some. And why not doing more efficient code ? It really costs not so much time to follow few rules.

[marakatti]

Having something similar to iGame for the ST would be great.

https://www.indieretronews.com/2020/09/igame-v2-well-known-amiga-game-launcher.html?m=1

[ParanoidLittleMan]

There is game launcher under work by couple Atari users, which will have displaying of screenshot from game. Will not write here who works on it - will for sure present it here too, when is ready.

 

Scanning hard disk for hard disk adapted games - it would work partially - can find some specific types, but file names in TOS are short, so to get exact game title would look in README.TXT, if there is such. 

In any case, game list is done in big part previous summer, and it is easy to correct if some games, groups of games go on different partition. 

I'm thinking about screenshots too . It may come in some later version.  Or people can jump on my WEBsite and find game in couple seconds - there are screenshots, cover scans and YT videos

http://atari.8bitchip.info/fromhd3.php?s=n#DL

Above sets alphabetical order in table.