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

[ParanoidLittleMan]

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.

 

 

 

 

[Cyprian]

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 August 17, 2019 by Cyprian_K
mistyped

[ParanoidLittleMan]

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 % .

 

[BillG]

On 8/17/2019 at 4:44 AM, ParanoidLittleMan said:

It is not much known that TOS actually consists from 2 pretty much independent parts:

 

It is probably historical.

 

The first part is derived from CP/M --> Concurrent PC DOS --> DR DOS plus the GSX graphics extensions originally hosted by CP/M.

 

The second part is the GEM GUI.

[ParanoidLittleMan]

Surely that GEMDOS part is based on CP/M and what was done for PC by DRI . Don't know about VDI,  mouse, Line-A ? Yes, later 2 is in GEMDOS part too, although not initialized when AUTO run happens.

But that GEM GUI is later creation, concept means not that 2 parts could not be compiled at once. And that was not the case, I'm sure. There are indicators for that - no calls from one part to other. AES alerts for disk operations communicate via special RAM address for that (right under $400) .

I see as main reason that DRI had not strong enough computer and C-compiler what could deal with plenty of source code - surely over 1 MB, near 200 KB long output. So needed to do it in 2 parts.

I was able to reassemble complete TOS 1.04 from single S file with Devpac and 4 MB RAM. It was on edge - source len was close to it's limit.  And C-compiler for sure needs more RAM than assembler.

 

[mikro]

I'd imagine they had some kind of TSR (maybe a cart) which represented the GEMDOS/VDI part and the other team was just developing AES/Desktop as a standalone app in Alcyon C, along with libraries etc. And then the final product was merged together with the few bridges in memory as needed.