TOS 1.4 disassembly project

General Discussion, STOS.

Moderator: troed

User avatar
Smonson
Posts: 708
Joined: Sat Oct 28, 2017 10:21 am
Location: Canberra, Australia
Contact:

TOS 1.4 disassembly project

Post by Smonson »

Heyo,

I just thought I'd post a topic about my TOS 1.4 disassembly repo. I've only got a tiny bit of it disassembled so far (13%), and it's completely useless to everyone. But it exists, so there might as well be a record of it. As a matter of fact even if it was complete, it'd still probably be useless to everyone except me.

The main reason for the existence of this is that I've been working for years on a decompiler. The decompiler is also not at a useful stage of development (...it kinda stalled). But TOS has been a great test bed for the decompilation-oriented disassembler that I wrote as part of THAT project.

If you are thinking of clicking on this link. just be warned that I prefer to use modern GNU assembly syntax, which means the percent sign on register names, which I know everyone hates!

Anyway, it's here: https://github.com/smonson78/tos-re

I'm going to keep plugging away at it when I have free evenings.
User avatar
thorsten.otto
Posts: 148
Joined: Mon Nov 04, 2019 2:20 am

Re: TOS 1.4 disassembly project

Post by thorsten.otto »

I think you are aware of the source i reconstructed for TOS 2.x?

After i finished it, i also started on doing the same for TOS 1.04, and you can already find some work on it in that archive. However, it is far from being finished.

Also, if really working on it, the TOS 1.4 version should maybe be extracted to a separate repo, otherwise the source will become almost unreadable due to the needed ifdefs (AES and desktop in 1.4 are not seperated like in TOS 2.x, their sources are intermixed, and the desktop it *much* different than newer versions).

In your page i also read that your goal is to create a binary identical version (at least as a first step). I totally agree on that, since that is the only way to guarantee that there are no errors introduced by the conversion (there are already enough bugs in TOS itself,no need to add any more :D ) Apart from that (unless you really only want to use only the disassembly, despite the fact that BDOS, AES and DESKTOP were originally were written in C), you won't be able produce identical version with gcc. For that, you definitely have to use the Alcyon compiler. BTW the compiler i hacked already has some support to generate the Line-F shortcuts that are used in this TOS version.

However i would advise to not use any GCC specifics like % for register names. It is always possible to write assembler sources in a way that they are accepted both by gcc and alcyon. You can even preprocess the sources like gcc does, using my cross-toolchain for alcyon.

Edit:just realized that not all of the source i have locally are part of the archive. Amongst others, the dispatch table for the Line-F handler is missing. It is not complete (about 80%, mostly missing functions from desktop). If you need them i can try to generate a new archive.
User avatar
Smonson
Posts: 708
Joined: Sat Oct 28, 2017 10:21 am
Location: Canberra, Australia
Contact:

Re: TOS 1.4 disassembly project

Post by Smonson »

thorsten.otto wrote: Fri Nov 26, 2021 3:01 pm I think you are aware of the source i reconstructed for TOS 2.x?

After i finished it, i also started on doing the same for TOS 1.04, and you can already find some work on it in that archive. However, it is far from being finished.
I wasn't aware of it, I haven't really been in the loop on that sort of thing. I've been extensively cross-referencing with your TOS 3.06 to find out the names of symbols. Thanks for the info! I will check it out.
thorsten.otto wrote: Fri Nov 26, 2021 3:01 pm In your page i also read that your goal is to create a binary identical version (at least as a first step). I totally agree on that, since that is the only way to guarantee that there are no errors introduced by the conversion (there are already enough bugs in TOS itself,no need to add any more :D ) Apart from that (unless you really only want to use only the disassembly, despite the fact that BDOS, AES and DESKTOP were originally were written in C), you won't be able produce identical version with gcc. For that, you definitely have to use the Alcyon compiler. BTW the compiler i hacked already has some support to generate the Line-F shortcuts that are used in this TOS version.

However i would advise to not use any GCC specifics like % for register names. It is always possible to write assembler sources in a way that they are accepted both by gcc and alcyon. You can even preprocess the sources like gcc does, using my cross-toolchain for alcyon.

Edit:just realized that not all of the source i have locally are part of the archive. Amongst others, the dispatch table for the Line-F handler is missing. It is not complete (about 80%, mostly missing functions from desktop). If you need them i can try to generate a new archive.
GNU as is a pain, because it replaces instructions that you specify in the source with different ones (if they're shorter/faster) as below, among others, which is super irritating.

Code: Select all

lea <addr>,%reg --> lea %pc@(<addr>),%reg
or #<imm>,%reg --> ori #<imm>,%reg
and #<imm>,%reg --> andi #<imm>,%reg
cmp #<imm>,%reg --> cmpi #<imm>,%reg
add #<imm>,%reg --> addi #<imm>,%reg
It also pads the unused byte in a word with fs while the original (Pure?) assembler used for TOS pads with zeros. I can't fault it for an arbitrary choice but it would have been nice to have a command-line switch to supply a custom value.

I began by just commenting out the mnemonics and replacing them with inline hex but now I'm using a preprocessor to assemble these and output hex instead (wherever it's easy to do it).

I really don't agree with leaving register prefixes off, it seems like a bad design choice better left in the 80s. If at any point someone wants to build this codebase with an assembler that doesn't use them then it would be trivial to strip the prefixes off in the preprocessor anyway, while going the other direction would not be possible. So having the explicit prefixes in there supports both cases.

So despite a couple of annoyances, GCC is actively maintained, involves zero effort to get it (you can just apt install it on Ubuntu), and it works well with binutils. So I'm going to stick with it for the time being.

What prompted me on this was the resolution unlock hack for the HDMI mod. For that one I made some edits to TOS 1.4 which I wrote in C and placed in the empty space at the end of the ROM, patched in with jmps. I had disassembled a couple of percent of the ROM by then, so I chucked it on github for later projects. I was surprised at how long-winded some of the code in TOS is and it made me want to start editing it!

I'm not myself interested in being able to re-compile C sources into byte-identical copies of the original TOS 1.4 functions - assembly source is fine for that goal. But I will certainly want to replace specific functions with C sources for the purpose of TOS mods, one day. That would be in a separate branch that doesn't interfere with the byte-identical disassembled one. The key thing is to first eliminate all the hard-coded symbol addresses in the source so that it doesn't explode when you slightly move everything up by a couple of bytes.
User avatar
thorsten.otto
Posts: 148
Joined: Mon Nov 04, 2019 2:20 am

Re: TOS 1.4 disassembly project

Post by thorsten.otto »

Smonson wrote: Sat Nov 27, 2021 1:28 pm I've been extensively cross-referencing with your TOS 3.06 to find out the names of symbols. Thanks for the info!
Erm, maybe you got me wrong. It's the same source, both 2.06 and 3.06 can be compiled from it. They are very similar, and thus can be handled by some ifdefs.
GNU as is a pain, because it replaces instructions that you specify in the source with different ones (if they're shorter/faster) as below, among others, which is super irritating.
Yes, i know. I have similar problems with PASM, which also has no option to turn such optimizations off.
GCC is actively maintained, involves zero effort to get it (you can just apt install it on Ubuntu), and it works well with binutils. So I'm going to stick with it for the time being.
GCC yes, but not the m68k backend. And since binutils 2.31, a.out was removed, so you can't really use it anymore for our cross-compiler, and instead have to use an older version (or use my toolchains, where i have added that support back in, but those are just tar archives for now, not debian packages).
I'm not myself interested in being able to re-compile C sources into byte-identical copies of the original TOS 1.4 functions - assembly source is fine for that goal.
That's possible of course, but the C-Code would be much easier to read. And large parts of GEMDOS, AES and DESKTOP were originally written in C.

Just reconstructing the disassembly should not be that hard, maybe a matter of a few days. But if you really want to make changes later, you will definitely work on C-Code where possible.

BTW, i just wonder how Atari managed to build the final ROM. They must have been using some scripts to replace the function calls for which linef-traps exist, and also the epilogue of the functions, which is also handled by the linef-handler.

PS.: i've just uploaded a new archive which is just an git-archive of my repo, to be sure i didn't miss anything this time. You will find it at http://tho-otto.de/download/tos306all.tar.bz2

Maybe of interest is the file lineftab.S which is the linef dispatcher table, so you know which function is called when you encounter them. There are also working versions of complete disassemblies in the listings directory, where the tos104de.s already has most of the function names annotated.
User avatar
thorsten.otto
Posts: 148
Joined: Mon Nov 04, 2019 2:20 am

Re: TOS 1.4 disassembly project

Post by thorsten.otto »

Looking at your assembly source, it seems that something has gone wrong there ;) E.g from addr_34fc on, there are lots of ".short" statements, but that is just normal code, no data.

Also, using just the dissassembly isn't really helpful i think if you want to understand what's going on. Lots of your routines from the BIOS don't even have proper names yet. And when you get to the desktop, it will get even worse. Unlike TOS 2.x, lots of the desktop global variables are kept in a structure, so there will be lots of statements like "tst.w 24220(a0)" etc. when that structure is accessed. Without at least replacing all that constants with some symbolic names, you won't understand what is done there, nor will you be able to change anything later.

BTW i've taken a look at my own sources again, and it seems that i've got much farther than i thought ;) After some minor changes, BIOS, VDI and GEMDOS of 1.4 are now complete.That leaves only AES and DESKTOP. AES itself is quite similar to the one from 2.x, so is almost there, only problem is that the desktop and aes sources are badly intermixed, so it can't be finished until also desktop is complete. And the desktop is totally different from 2.x, so almost completely has to be rewritten. But altogether that means that about 60% of TOS 1.4 are already done.
User avatar
Smonson
Posts: 708
Joined: Sat Oct 28, 2017 10:21 am
Location: Canberra, Australia
Contact:

Re: TOS 1.4 disassembly project

Post by Smonson »

thorsten.otto wrote: Tue Nov 30, 2021 12:45 pm from addr_34fc on, there are lots of ".short" statements, but that is just normal code, no data.
thorsten.otto wrote: Tue Nov 30, 2021 12:45 pm Lots of your routines from the BIOS don't even have proper names yet.
That's just how far I've gone so far, as I mentioned only 13% of the ROM is disassembled.

Re: the desktop, it's less interesting to me because there is not as much scope for mods in that code as there is in the lower-level routines. That's why I've started at the boot end. That said, I certainly would prefer to have proper source code for things.

Congrats on completing BIOS, VDI and GEMDOS sources - that's a huge achievement.
thorsten.otto wrote: Tue Nov 30, 2021 12:45 pm GCC is actively maintained, involves zero effort to get it (you can just apt install it on Ubuntu), and it works well with binutils. So I'm going to stick with it for the time being.
GCC yes, but not the m68k backend. And since binutils 2.31, a.out was removed, so you can't really use it anymore for our cross-compiler, and instead have to use an older version (or use my toolchains, where i have added that support back in, but those are just tar archives for now, not debian packages).
The m68k backend for GCC doesn't produce very optimised machine code, but at least it continues to function, and it's quite a bit better than what's currently in the 1.4 ROM, so that's good enough for these purposes. The fact that GCC comes with the compiler, assembler, and linker (and objcopy) increases its utility by virtue of having a simpler workflow.
thorsten.otto wrote: Tue Nov 30, 2021 12:45 pm Just reconstructing the disassembly should not be that hard, maybe a matter of a few days
Perhaps if it's copied from the existing source code, but I wasn't aware of its existence until just now.
User avatar
thorsten.otto
Posts: 148
Joined: Mon Nov 04, 2019 2:20 am

Re: TOS 1.4 disassembly project

Post by thorsten.otto »

I've been working a bit on the TOS sources again, and made up a new repo, which was cleaned up to contain only the relevant parts for TOS 1.4 (keeping it all in a single source archive would just require too many ifdefs, making the code difficult to read)

Current state is that BIOS, VDI, GEMDOS & AES are finished. Only thing to be done is the desktop, which is much different from what is found in later TOS versions. So the desktop currently still consists mostly of assembler sources, but reformatted from the disassembly so that it can be assembled again. As a result, the us, uk, de and fr versions can already be compiled to identical images (for other languages, there may be some tweaks needed, eg. the image of the swedish version that i have seems to have some patches applied. If someone has an unpatched swedish version, please let me know).


The results are currently available in a private github repo. If someone is interested in the source, let me know so that i can invite him. Eventually that repo will be made public once everything is complete.
User avatar
thorsten.otto
Posts: 148
Joined: Mon Nov 04, 2019 2:20 am

Re: TOS 1.4 disassembly project

Post by thorsten.otto »

Bump ;)

Did some more work, and desktop (and thus the whole TOS) is almost complete now. Nobody taking care? ;)
User avatar
stephen_usher
Posts: 5579
Joined: Mon Nov 13, 2017 7:19 pm
Location: Oxford, UK.
Contact:

Re: TOS 1.4 disassembly project

Post by stephen_usher »

thorsten.otto wrote: Sun Dec 19, 2021 2:26 pm Bump ;)

Did some more work, and desktop (and thus the whole TOS) is almost complete now. Nobody taking care? ;)
I might... maybe :lol:
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.
User avatar
JezC
Posts: 2081
Joined: Mon Aug 28, 2017 11:44 pm

Re: TOS 1.4 disassembly project

Post by JezC »

This is really great progress!

I'm still trying to make the time to find out how to install all the tools & s/w to rebuild EmuTOS (for my own development purposes/interest) but think this work on the original versions is a very worthwhile project too.

:thumbup:
Post Reply

Return to “SOFTWARE”