I digged little in TOS, AES, and seen not good thing

News,announcements,programming,fixes,game patches & discussions.

Moderator: Petari

Post Reply
Petari
Posts: 461
Joined: Tue Nov 28, 2017 1:32 pm

I digged little in TOS, AES, and seen not good thing

Post by Petari » Sat May 19, 2018 1:01 pm

... again. Is it me negative, or that could be really solved better ?
So, there are couple RSC structures in TOS, which contain all txt, objects, menus for Desktop, File Selector etc. In 1.04 it takes about 16KB ROM space.
They go, when AES is initialized in RAM, with some changes - coordinates depending from used resolution, and like. Just like with every RSC file. So, it will take then 16 KB space in RAM too. Not much for 512KB machine, could someone say. Well, there is never 512KB free RAM, but let see how much is max free RAM in case of TOS 1.04 when Desktop starts. It would be simply $80000-$8000 (screen) - $12496 (membottom) = 416618 bytes. 16KB is about 4% of it. Not little. Especially, as most of it is there in ROM, 100% same - text messages in first place. Objects have some parts - like coordinates updated, so they can not be used from ROM, at least not with this structure definition.
Since txt messages take some 40-50% of RSC space in case of AES, Desktop, could save some 7KB RAM space - with little effort - by setting pointers of text to existing ROM locations, and skipping copying of txt in RAM. But what to expect, when some 18 KB is wasted in case of AUTO run ?
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

User avatar
exxos
Site Admin
Posts: 2937
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: I digged little in TOS, AES, and seen not good thing

Post by exxos » Sun May 20, 2018 11:19 am

The RSC file data needs to be in RAM to allow editing of text though ?

If nothing changes in the RSC structure, then just ROM reads may work, but changes are always done, like the "tick" boxes in some menus etc ?
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.

stephen_usher
Posts: 123
Joined: Mon Nov 13, 2017 7:19 pm
Location: Oxford, UK.
Contact:

Re: I digged little in TOS, AES, and seen not good thing

Post by stephen_usher » Sun May 20, 2018 1:18 pm

I s'pose they could have implemented a "copy on write" system for the RSC, as in if a change is needed test whether the pointer points into ROM and if so, take a copy in RAM and then modify it. However, this would have required more complex code in the RSC modification routine(s).
Intro retro computers since before they were retro...
ZX81->Spectrum->Memotech MTX->Sinclair QL->520STM->BBC Micro->TT030->PCs & Sun Workstations.
Added code to the MiNT kernel (still there the last time I checked) + put together MiNTOS.
Collection now with added Macs, Amigas, Suns and Acorns.

Petari
Posts: 461
Joined: Tue Nov 28, 2017 1:32 pm

Re: I digged little in TOS, AES, and seen not good thing

Post by Petari » Sun May 20, 2018 1:50 pm

Most of text is static. No much editable ones. Editable should go in RAM, of course. And code for it should be not complicated, since order of txt items in memory must not follow order of objects on screen - so can put all static txt to end, and then just setting pointers to ROM addresses.
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

Petari
Posts: 461
Joined: Tue Nov 28, 2017 1:32 pm

Re: I digged little in TOS, AES, and seen not good thing

Post by Petari » Mon May 21, 2018 10:40 am

I disassembled AES part of TOS 1.04 - what was something what I did not plan earlier. Partially because changing here mentioned RSC handling, partially for making it shorter by optimizations, and partially to change not really good section layout in TOS ROM. Start of it was troublesome - it appeared that MON from Devpac 3 can not be set, to disasm properly line-F opcode - what begins with $F - and what is special subrutine call in AES from 1.04 . I did not see any way to set it for 68000 in manual, so it decoded lot of it as some pflush and like 68030 instructions. And worse, when I tried to reassemble, it showed only small count of errors, so I went in manual correction, but wondered why no more errors ... Well, it was lot of it, just Devpac can not display number bugger than 255 for errors (bad variable size ?), plus in list was only small part of all errors . When I realized it, tried with MONST from Devpac 2 - it disassembled line-F correct (as simple dc.w $Fxxx), but did not generate labels, dismissed last 30 KB ... I did not expect that it was so bad.
Anyway, instead looking for some other disassembler, what could be another waste of time, I decided to mod MON, so it disasm all line-F properly for 68000. That took about 1 hour, and I got good S file - otherwise should correct manually some 2000-4000 errors. Needed only to correct some 10 locations, and it is now error free. That was unexpectedly easy, must to say. With GEMDOS part it took days to fix S file - for all parts, what disassembler was not able to do right. Reassembling with optimization (short address form, when possible) resulted in 2K shorter code. Half of what was with GEMDOS part, but that's OK, since less variable access in low RAM, + ASM part (there are some in AES too) have already short addressing used. Now, I'm sure that used C compiler was simply not able for short addressing. They could save 6KB with that, and then could solve it without line-F . But best part just comes:

Of course, I looked code for copying mentioned RSCs in RAM. It actually copies in single pass all 3 : AES RSC, Desktop RSC and DESKTOP.INF template. What is 16836 bytes. That makes it even better packable . So, I did my optimization plan B - to put them packed in ROM, since they are never accessed there.
And it saved 10 KB ! So, now I have exactly 17470 bytes free space at end of TOS 1.04 ROM. That's about 14x more, than in original, or some 8.8 % of ROM space. Lot of space for diverse patches, add-ons . Here talking about unmodded TOS 1.04 - where nothing is changed, just optimized.
Plan A was, what talked here, to save some RAM space. That will be harder to solve, and will save max some 6KB - RAM space, possible to save little ROM space too, I guess. Will see about it later, likely.
There are other things to solve - like changing Desktop icons - well. that's what can see usually in modded TOS-es. Here will be it too, together with mods, of course - as is presented in couple other threads.
And my little older idea is now possible: to dismiss line-F from TOS 1.04 - now there is space for it. No, I will not self replace all of about 4000 line-F calls. Will just use AES from TOS 1.62, what is some 8KB longer. Of course, it needs to be disassembled too first.
P.S. : Done too.
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

Petari
Posts: 461
Joined: Tue Nov 28, 2017 1:32 pm

Re: I digged little in TOS, AES, and seen not good thing

Post by Petari » Fri May 25, 2018 1:29 pm

Mission accomplished. Static parts - bitmaps, icons and text what changes not (and what changes is not editable only, there are many others like those in disk info dialog - which display used, free sizes, and like) are now only in ROM, other is in RAM. Used packing for parts, what go in RAM - no need to have it unpacked in ROM. So, now there is some 6.3 KB more space in ROM (with only this optimization), and 6KB more free RAM . Total 12 KB space is saved. That's not bad - when is free (except my time). But I learned some things in all it. There were some strange values in 1 RSC header, and SW for creating S ASM. source file worked not well with that RSC. I think that bad docs were the problem, again.

lessram.png
lessram.png (13.45 KiB) Viewed 281 times
moreram.png
moreram.png (14.37 KiB) Viewed 281 times

Exactly 6112 bytes more free RAM. Not much when there is 4MB in machine, but why not ?
Hey, this is actually more than how much free RAM remained in first STs, with TOS and DR Basic in RAM - it was about 5 KB ! :lolbig:
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

Petari
Posts: 461
Joined: Tue Nov 28, 2017 1:32 pm

Re: I digged little in TOS, AES, and seen not good thing

Post by Petari » Fri Jun 29, 2018 10:35 am

Little digging in TOS 2.06 indicates that there it is solved better, static parts are not copied into RAM. And that saves much more RAM space, of course, since 2.06 Desktop and AES RSCs are much longer than in TOS 1.xx .
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

Post Reply