Jump to content
Sign in to follow this  
ParanoidLittleMan

The real reason(s) why TOS is split in 2 parts

Recommended Posts

It is not much known that TOS actually consists from 2 pretty much independent parts:  first is so called GEMDOS part, where early HW init, disk functions, basic TXT output, and even VDI is . And of course trap #1, trap #13, trap #14 calls. Trap #2 is for VDI and AES - and GEMDOS part performs VDI trap #2 calls.

Second part is GEM or AES + Desktop. There is no any direct jump, jsr or memory loc. address access from one part to other. All goes via trap calls and low RAM locations - like system variables. There are some special areas below $400 to pass some data in case of need for AES alert during some disk operation error.

 

So, I'm thinking about what made programmers to make it so ?

Possible reasons:  it was done by 2 more-less independent teams. Used compiler (Alcyon) for 68000 was not capable to compile larger code - possible that because used computer had not so much RAM too. Splitting in 2 part solved it.

But splitting in 2 functionally different parts has benefits, of course:  you may update one part while leaving other unchanged.  Debugging is simpler too.

 

And another interesting question is: why they split GEMDOS part in 2 sections ? There is main part at ROM start, then comes AES main part, after what comes GEMDOS section with font definitions, keyboard control - for shift, Alt ... And after it comes end of AES part - what is basically RSC for AES and Desktop + initial DESKTOP.INF data.

I guess that having fonts and keyboard shifts separated made easier work on other language versions. Still don't see why it needed to be placed after AES.  I reassembled it with complete GEMDOS in 1 section, and AES in other. Works fine, less work in putting it together.

 

For the end: packing mentioned RSC + DESKTOP.INF data can save almost 10 KB in ROM space. It goes in case of TOS 1.xx straight into RAM when AES part is initialized by simple copy. AES is started as GEMDOS APP btw.

 

 

 

 

Share this post


Link to post
Share on other sites
Posted (edited)

interesting topic

 

8 hours ago, ParanoidLittleMan said:

And another interesting question is: why they split GEMDOS part in 2 sections ? There is main part at ROM start, then comes AES main part, after what comes GEMDOS section with font definitions, keyboard control - for shift, Alt ... And after it comes end of AES part - what is basically RSC for AES and Desktop + initial DESKTOP.INF data.

so, it seems they split ROM space into two sections: code (GEMDOS, AES) and data (GEMDOS , AES). That sounds reasonable.

 

Edited by Cyprian_K
mistyped

Share this post


Link to post
Share on other sites
13 hours ago, Cyprian_K said:

interesting topic

 

so, it seems they split ROM space into two sections: code (GEMDOS, AES) and data (GEMDOS , AES). That sounds reasonable.

 

Yes, but I don't see why data part of GEMDOS is not right after GEMDOS code part, and same for AES. That's how it is easier to assemble/compile.

And of course, there are lot of shorter-longer data blocks in code sections too, as it is usual. Just try to disassemble it properly and will see it 😀

 

And to add that I was able to cut down De TOS 1.04 size from 191 KB to 174 KB by packing RSC block + code optimization in Devpac. Same is with other versions. So, almost 10 % .

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...