freemint-discuss — The official FreeMiNT Mailing List

Re: [Freemint-discuss] Disassembly of TOS 1.00 with Ghidra

[Thorsten O. <ad...@th...>]

On Freitag, 17. Januar 2025 12:16:12 CET Thorsten Otto via Freemint-discuss 
wrote:
> 've attached an old archive of cpm sources (can't remember where i got that
> from)

Edit: i think you can get almost the same by checking out very old emutos 
sources, from around 2001. Eg. in an attempt to compare the AES versions, i 
checked out commit f29cf59f826ab0a3957be1a12387ac809d89dba5

Re: [Freemint-discuss] Disassembly of TOS 1.00 with Ghidra

[Thorsten O. <ad...@th...>]

On Freitag, 17. Januar 2025 10:18:58 CET Vincent Rivière wrote:
> Important: I took those names mgetofd/oftdel from your TOS 1.04
> reconstructed sources.

IIRC that were my own inventions, because there was no source of bdos 
available at that time (at least not the version from TOS 3.x)


I've attached an old archive of cpm sources (can't remember where i got that 
from). Seems those are more close to the routines in TOS 1.00. Amongst others, 
there is a variable int osmem[4000], and also a comment that the len was 
bumped to 4000 in 1986.

Re: [Freemint-discuss] Disassembly of TOS 1.00 with Ghidra

[Vincent R. <vin...@fr...>]

On 17/01/2025 à 07:24, Thorsten Otto via Freemint-discuss wrote:
> BTW, i noticed some BDOS variables that you have added, a large memory pool 
> amongst others. OTOH, some variables from later versions are missing. I 
> haven't looked at it yet, but could it be that the BDOS is also very 
> different?

Yes, in TOS 1.00 there is mainly something that I called "bdos_mempool". It 
is a 6000-byte buffer used for BDOS internal structures. Blocks are 
allocated there, with sizes multiple of 2. Such blocks are used, then when 
freed they are put into a "free list". There is one per block size. So the 
big memory pool is progressively split into smaller chunks, either used or 
free. But that memory pool itself is never recovered, this is by design.

In my Ghidra archive, type G bdos_walloc and look at the decompiled source. 
It's purpose is to definitely alloc a memory block if any size (in WORDs) 
from the bdos_mempool.

See also the high-level functions:
- mgetofd() to alloc a block, either from the free list or a new block from 
the memory pool
- oftdel() to free a block, by putting it into the free list.

There are 20 free lists located at the "root" label 0x56fa. One for each 
block size, multiple of 2.

Important: I took those names mgetofd/oftdel from your TOS 1.04 
reconstructed sources. But indeed, this part looks very different in TOS 
1.00. Specially, it seems that later mgetofd/oftdel were specialized for the 
OFD stucts (used for folders). But int TOS 1.00, they are used for many 
other types. See references to mgetofd() for details. It seems obvious that 
the original names for those functions were actually different (no idea 
which ones).

For that memory stuff, I have renamed the parameters and local variables in 
the Ghidra decompilation window. So the functions are now pretty readable. 
This was my main task last month, when I was hunting for that bug.

As I understand, in TOS 1.02 Atari reworked that BDOS memory management. 
With some memory dedicated to the OFD struct for folders. Hence the 
40-folder limit. But in TOS 1.00, there is no such thing. All BDOS structs 
share the same pool.

> And did you document the bug that you initially was looking for?

I will do precisely, as I did many tests. Mainly I traced the state of the 
BDOS memory pool and the free lists. I took a lot of notes.

Main thing is a memory leak in TOS 1.00 Fsfirst. This means ixsfirst and 
more precisely the "scan" function. It was the GetDnd() call in scan(). If 
the directory contents is entirely in memory cache, fine. But if the disk 
directory needs to be walked, all directories found before finding the 
requested file name cause a DND memory leak. On each Fopen(). And of course, 
at some point, the 6000 bytes pool is exhausted. Fopens returns a "File not 
found" error, then everything else quickly crashes. There is no such issue 
in later TOS versions.

-- 
Vincent Rivière

Re: [Freemint-discuss] Disassembly of TOS 1.00 with Ghidra

[Thorsten O. <ad...@th...>]

On Donnerstag, 16. Januar 2025 23:53:04 CET Vincent Rivière wrote:
> Now you're only missing TOS 1.02.

This is only the BIOS so far. There still is a long way to go ;)

BTW, i noticed some BDOS variables that you have added, a large memory pool 
amongst others. OTOH, some variables from later versions are missing. I 
haven't looked at it yet, but could it be that the BDOS is also very 
different? And did you document the bug that you initially was looking for?

Re: [Freemint-discuss] Disassembly of TOS 1.00 with Ghidra

[Vincent R. <vin...@fr...>]

On 17/01/2025 at 00:01, Miro Kropáček wrote:
> On the contrary, that must have been the TOS which was loaded from floppy disk.

Dumb me, 0x5000 is standard RAM, not custom ROM 😅
Thanks for the clarification.

>     And at page 297 of the PDF, we can see it's the ancient "Mushroom" version,
>     with mushroom clouds instead of bombs.
> 
> Yes, that confirms that.

Do all floppy-TOS versions have mushrooms instead of bombs?
I wonder how many variants of TOS 1.00 have been officially released.

BTW: Among other nice things to disassemble (and maybe rebuild), there is 
the ancient and colorful bootstrap ROM to load TOS from floppy.

-- 
Vincent Rivière

Re: [Freemint-discuss] Disassembly of TOS 1.00 with Ghidra

[Miro K. <mir...@gm...>]

On Thu, 16 Jan 2025 at 23:53, Vincent Rivière <vin...@fr...>
wrote:

> Note that in this early version, the ROM is located at address 0x5000
> instead of standard 0xfc0000. Pretty weird, definitely not a stock ST.
>
On the contrary, that must have been the TOS which was loaded from floppy
disk.


> And at page 297 of the PDF, we can see it's the ancient "Mushroom"
> version,
> with mushroom clouds instead of bombs.
>
Yes, that confirms that.

-- 
http://mikro.atari.org

Re: [Freemint-discuss] Disassembly of TOS 1.00 with Ghidra

[Vincent R. <vin...@fr...>]

On 16/01/2025 at 18:11, Thorsten Otto via Freemint-discuss wrote:
> BIOS of 1.00 can now be compiled to identical code.

Well done 🙂

Now you're only missing TOS 1.02.
As I said earlier, Ghidra *can* be used to match many labels from one ROM to 
another. And some editions of Atari ST Intern (at least my French one) has 
its BIOS disassembly, named "Mega ST TOS". That could help.

Due to Line-F hacks, that automatic matching doesn't work for AES/Desktop 
code. But I guess that with your recent work on processor patch, that could 
work better.

> I wonder whether they already had access to the sources? (the book is
> from 1988,
I guess yes.
Or at least a disassembly with labels.

Note that, at that time, the BDOS/VDI/AES/Desktop was still copyrighted by 
Digital Research (later open-sourced as GPL by Lineo). Maybe Atari just 
shared their own parts with those people? Namely, the BIOS? This was also 
easier, because it was obviously entirely manually written in assembly language.
Or maybe, is it possible that such commented disassembly was available with 
official Atari development kits? I have no idea.

> but there is also an earlier edition from 1986).
Do you mean this one?
https://www.synacktiv.com/ressources/Atari-ST-Internals.pdf

At the end, there is the disassembly of an early TOS 1.0 with a build date 
of 20/06/1985.

Note that in this early version, the ROM is located at address 0x5000 
instead of standard 0xfc0000. Pretty weird, definitely not a stock ST.

And at page 297 of the PDF, we can see it's the ancient "Mushroom" version, 
with mushroom clouds instead of bombs.

> And another small gimmick: the data of the bomb image differs by 1 pixel 
> compared to later versions.

Funny.

-- 
Vincent Rivière

Re: [Freemint-discuss] Disassembly of TOS 1.00 with Ghidra

[Thorsten O. <ad...@th...>]

BIOS of 1.00 can now be compiled to identical code. Well identical has to be 
proven (i only did that manually for now, since it references some functions 
from VDI & BDOS which have still different addresses).

Some new (actually old) function names where taken from the ST-Internal PDF. I 
also saw that there are much more labels than i thought (they are in the 
comments to the right). They are astonishingly similar to the ones i already 
used, which are mostly based on the leaked sources. I wonder whether they 
already had access to the sources? (the book is from 1988, but there is also 
an earlier edition from 1986).


There are also some problems to be solved for the final image later. I already 
mentioned that the data of the switch table in the bdos entry function is 
somewhere in the middle of the rom. Same happens also in other places, eg. 
with the constant strings from prtblk(). I wonder how they achieved that? I 
first though it might be caused by partially linking the modules to an object 
file, then finally linking those to the rom. However, that string data appears 
*after* all the bios, bdos and vdi functions. Any idea how that can be 
handled?


And another small gimmick: the data of the bomb image differs by 1 pixel 
compared to later versions.

Re: [Freemint-discuss] Disassembly of TOS 1.00 with Ghidra

[Thorsten O. <ad...@th...>]

Other funny thing i just realized: the original version of the alcyon 
assembler was not able to assemble short absolute addressing modes, which 
saves 2 bytes when acessing system variables or I/O addresses. In TOS 2.x and 
above they used mas instead, but in older versions this was worked around by 
setting a5 to 0 and use that as a base register. However in TOS 1.00, they 
missed a lot of places where this mode could be used, sometimes even inside 
one instruction:

vsetscreen:
[00fc0982] 4aaf 0004                 tst.l      4(a7)
[00fc0986] 6b06                      bmi.s      $00FC098E
[00fc0988] 2b6f 0004 044e            move.l     4(a7),1102(a5)
[00fc098e] 4aaf 0008                 tst.l      8(a7)
[00fc0992] 6b10                      bmi.s      $00FC09A4
[00fc0994] 13ef 0009 ffff 8201       move.b     9(a7),$FFFF8201
[00fc099c] 13ef 000a ffff 8203       move.b     10(a7),$FFFF8203
[00fc09a4] 4a6f 000c                 tst.w      12(a7)
[00fc09a8] 6b24                      bmi.s      $00FC09CE
[00fc09aa] 1b6f 000d 044c            move.b     13(a7),1100(a5)
[00fc09b0] 6100 fd74                 bsr        $00FC0726
[00fc09b4] 13ed 044c ffff 8260       move.b     1100(a5),$FFFF8260   <---
[00fc09bc] 426d 0452                 clr.w      1106(a5)
[00fc09c0] 4eb9 00fc a7e2            jsr        esc_init
[00fc09c6] 33fc 0001 0000 0452       move.w     #$0001,$00000452
[00fc09ce] 4e75                      rts

Re: [Freemint-discuss] Disassembly of TOS 1.00 with Ghidra

[Miro K. <mir...@gm...>]

On Tue, 14 Jan 2025 at 20:11, Thorsten Otto via Freemint-discuss <
fre...@li...> wrote:

> I don't mind. Until now it's mostly you and me who are discussing here. If
> someone is bothered by this being off-topic, we can move anywhere else.
> OTOH i guess some people just silenty read this and just wait how far this
> goes ;)
>
As far as I am concerned, I don't mind either. It's an interesting topic
and keeps the Atari topic alive. :-)

MiNT ML or any of its descendants was never purely about (Free)MiNT, so I
don't see a problem with that.

-- 
http://mikro.atari.org

Re: [Freemint-discuss] Disassembly of TOS 1.00 with Ghidra

[Thorsten O. <ad...@th...>]

On Dienstag, 14. Januar 2025 19:06:32 CET Vincent Rivière wrote:
> Nice findings.

As expected, there are some other "hidden" objects. That's really strange, 
because there is absolutely no way to access them in an editor. There is also 
a problem in the AES resource, the (physically) last object of tree #2 does 
not have the LASTOB flag set. I had quite some trouble to fix ORCS to even be 
able load those files ;)

Not to mention, that some of the objects have a x86 style NIL pointer for the 
text (-1L instead of NULL).

>Alternatively, I've setup a couple of discussions on the DisasTOS 
>project on GitHub :

I don't mind. Until now it's mostly you and me who are discussing here. If 
someone is bothered by this being off-topic, we can move anywhere else. OTOH i 
guess some people just silenty read this and just wait how far this goes ;)

Re: [Freemint-discuss] Disassembly of TOS 1.00 with Ghidra

[Thorsten O. <ad...@th...>]

On Dienstag, 14. Januar 2025 19:02:51 CET Vincent Rivière wrote:

> If your Line-A decompilation support is just as script,

LineF currently, not LineA ;) Most of the work is done in the script,
but it can only work with the modified processor description (basically, that 
patch just disables the FPU & MMU instructions so that the LineF opcodes are 
not accidently trying to also decode the effective address), and defines 2 new 
pseudo-opcodes for the calling and return variants.

> Anyway, it's too early for that.

Yes, a bit. I'm also not sure whether is worth do put much effort into such an 
extension (unless someone wants to contribute and has trouble applying the 
patch). That whole thing is only real useful for TOS 1.00 for now, and not 
useful for any other atari project.

Re: [Freemint-discuss] Disassembly of TOS 1.00 with Ghidra

[Vincent R. <vin...@fr...>]

On 14/01/2025 at 15:07, Thorsten Otto via Freemint-discuss wrote:
> There are also some other strange things. The desktop resource has 2 
> items in the menu that are not linked in the tree structure. Same could 
> be the case at some other places. When you open the resource in 
> interface, then save it without changing anything, the file immediatly 
> is about 600 bytes shorter.

Nice findings.

BTW, all those discussions are very nice and productive. But that's a 
bit out of topic here, on the FreeMiNT project. Personally, I don't 
mind. But that might annoy other people (or not).

Alternatively, I've setup a couple of discussions on the DisasTOS 
project on GitHub :

https://github.com/disastos/tos100fr/discussions

I didn't know that feature before. Basically, GitHub Discussions are 
similar to Issues. Difference is that a discussion is not necessarily a 
problem. A Discussion can later be converted into an Issue.

And regarding to the notifications, anyone can subscribe to a 
discussion. Or even "watch" the whole project (or restrict to Custom > 
Discussions).

Only drawback is that users need a GitHub account to contribute to 
discussions and/or get notifications.

Anyway, not matter where, discussions must continue.

-- 
Vincent Rivière

Re: [Freemint-discuss] Disassembly of TOS 1.00 with Ghidra

[Vincent R. <vin...@fr...>]

On 14/01/2025 at 05:17, Thorsten Otto via Freemint-discuss wrote:
> What do you mean by "extension"? The script is separate and just has to 
> be copied to your scripts directory (but it may need some tweaks once 
> the few remaining desktop functions have been identified). But the patch 
> to the processor definition is another thing. I can't think of a simple 
> way of offering that in another form, other than repacking the whole 
> ghidra directory.

A Ghidra "extension" is some kind of plugin which can be installed on a 
standard Ghidra setup to add features. As I understand, extensions can 
do much, including new processor support, new user interface features, 
additional scripts, etc.

If your Line-A decompilation support is just as script, then fine, any 
user can indeed put that script somewhere. I had in mind the processor 
definition, but you say that's another thing.

When everything is mature, I think we could create a Ghidra extension to 
hold all stuff related to Atari ST ROMs and PRGs. That would be 
convenient for users. Anyway, it's too early for that.

-- 
Vincent Rivière

Re: [Freemint-discuss] Disassembly of TOS 1.00 with Ghidra

[Thorsten O. <ad...@th...>]

On Dienstag, 14. Januar 2025 05:35:37 CET Thorsten Otto via Freemint-discuss 
wrote:
> BTW, could be that one of the additional data blocks in the builtin resource
> data contains the desktop icons.

Yes, that is the case. That now makes 5 offsets in the glue header:

- 0: offset to start of desktop resource header
- 1: offset to start of desktop icons
- 2: offset to start of desktop.inf
- 3: offset to start of format resource
- 4: offset to end of format resource, used to calculate its size

However, there are still some strangenesses:

- The last offset should give the total size of all data, however rsc_read 
seems to have some other hardcoded value compiled in, allocating actually some 
bytes more than needed. That also means that there is some garbage in the ROMs 
after the format resource.

- The size of the desktop icons should be identical in all versions, but 
isn't: in the fr ROM, it is 1540 bytes, and in the us/de ROM it is 1538 bytes.

- the icondata does not have a resource header, it is just 6 ICONBLKs, 
followed by the data. Only 5 of the icons are actually used. But i still don't 
get the math: just the data for 6 32x32 icons would be (32 / 8 * 32 * 2 * 6 = 
1536) bytes, but then there would be no space for the 6 ICONBLKs (6 * 34 = 204 
bytes).

- in the german ROM, all but the first offset in the header are odd.


There are also some other strange things. The desktop resource has 2 items in 
the menu that are not linked in the tree structure. Same could be the case at 
some other places. When you open the resource in interface, then save it 
without changing anything, the file immediatly is about 600 bytes shorter.

Re: [Freemint-discuss] Disassembly of TOS 1.00 with Ghidra

[Thorsten O. <ad...@th...>]

On Dienstag, 14. Januar 2025 02:14:49 CET Vincent Rivière wrote:
> They seem to be
> related to the "show file" feature, as well as the floppy-format applet.

Yes exactly.

>I wasn't able to find the source for that in Thorsten's TOS 1.04 
reconstructed sources. Is the source of that stuff unavailable ?

Of course it is, otherwise it won't compile to an identical image ;)

The show_file() command is handled in https://github.com/th-otto/tos1x/blob/
master/desk/deskshow.c, and the format dialog in https://github.com/th-otto/
tos1x/blob/master/desk/deskdisk.c. However, the versions in tos 1.00 seem to 
be quite different, that's why i left them out for now (only assigned some 
dummy labels corresponding to the LineF opcodes). Remember also the separate 
resource file for the format dialog. Looks like they tried to mimic the 
behaviour of the x86 version, which does some strange things to load 
FORMAT.COM and run that as a separate process.

BTW, could be that one of the additional data blocks in the builtin resource 
data contains the desktop icons. Atleast they are not in the normal resource 
file. But i have to check that, the offsets from the glue header look a bit 
strange to me, especially in the german version.

Re: [Freemint-discuss] Disassembly of TOS 1.00 with Ghidra

[Thorsten O. <ad...@th...>]

On Montag, 13. Januar 2025 13:51:02 CET Vincent Rivière wrote:
> Do you think it would be possible to pack your patch into a clean
> extension that would run on standard Ghidra?

What do you mean by "extension"? The script is separate and just has to be 
copied to your scripts directory (but it may need some tweaks once the few 
remaining desktop functions have been identified). But the patch to the 
processor definition is another thing. I can't think of a simple way of 
offering that in another form, other than repacking the whole ghidra 
directory.

Re: [Freemint-discuss] Disassembly of TOS 1.00 with Ghidra

[Vincent R. <vin...@fr...>]

On 09/01/2025 at 13:59, Thorsten Otto via Freemint-discuss wrote:
> I've pushed the ghidra archive now to my TOS_100 branch, in the ghidra 
> directory. Please let me know if you can import it. AES functions should now 
> be complete, as well as most BSS symbols from AES.
> 
> There are also text files for the symbols, and the structure definitions, 
> just in case.

Source:
https://github.com/th-otto/tos1x/blob/TOS_100/ghidra/tos100frsyms.txt

I've just written a script to import that (after some manual cleanup):
https://github.com/disastos/tos100fr/blob/main/ghidra_scripts/ImportLabels.java

I also added a few missing labels for the remaining AES/desk functions.

And I've pushed the result to my GAR archive:
https://github.com/disastos/tos100fr

As there are now almost all function names on dw references, the assembler 
disassembly looks very well 😃 Pretty usable.

Now there are only a few missing function labels in desk. They seem to be 
related to the "show file" feature, as well as the floppy-format applet. I 
wasn't able to find the source for that in Thorsten's TOS 1.04 reconstructed 
sources. Is the source of that stuff unavailable ?

-- 
Vincent Rivière

Re: [Freemint-discuss] Disassembly of TOS 1.00 with Ghidra

[Vincent R. <vin...@fr...>]

On 13/01/2025 at 13:34, Thorsten Otto via Freemint-discuss wrote:
> I think i got it. Decompiled code now looks like

Marvelous!
Do you think it would be possible to pack your patch into a clean 
extension that would run on standard Ghidra? That would be ideal.

-- 
Vincent Rivière

Re: [Freemint-discuss] Disassembly of TOS 1.00 with Ghidra

[Thorsten O. <ad...@th...>]

I think i got it. Decompiled code now looks like



and


for some simple functions.

An updated patch and the script i used are now also pushed.

Now trying to reconstruct the definition of THEDSK structure. It seems to have 
almost identical content, but in totally different order :(

Re: [Freemint-discuss] Disassembly of TOS 1.00 with Ghidra

[Thorsten O. <ad...@th...>]

On Sonntag, 12. Januar 2025 22:13:49 CET Vincent Rivière wrote:
> See "Out of Print Books" on the left, then "Atari ST - Internals (Abacus #2,
> 3rd edition) [Jan 1988]".

Oh yes, thats seems very useful. Although i don't see many labels there, 
except the entry pints for the bios/xbios functions. But the serial functions 
in tos 1.00 seem to be quite different (probably again different in 1.02). And 
the comment "We don't expect any changes to this listing in the near future" 
is quite funny ;)

And some progress again:



So the decompiler already sees the reference to the functions. Just have to 
tell him the parameters now...

Re: [Freemint-discuss] Disassembly of TOS 1.00 with Ghidra

[Vincent R. <vin...@fr...>]

On 12/01/2025 at 21:42, Thorsten Otto via Freemint-discuss wrote:
> Had partly success with my patched processor definition. The decompiler now 
> atleast does not barf on the linef-call anymore. A simple function now looks 
> like this:

Hats off! That's really cool.

I haven't tried the 68000mshort patch myself, yet. But you should try to 
contribute it upstream. I quickly saw it was only a new configuration file, 
so it shouldn't hurt other targets.

Regarding to Line-F calls, of course it's Atari specific. But it's the same 
problematic for Lisa/Mac Line-A calls, so some global solution should be 
found. I.e. some optional settings, or even a new "language" specific to Atari.

On my side, I wrote a script named EnhancedDisassemble:
https://github.com/disastos/tos100fr/blob/main/ghidra_scripts/EnhancedDisassemble.java

Basically, it's the same as 'D' (disassemble), but it also handles Line-F as 
"dw" + reference (my other script). It was very useful, as I managed to 
easily and quickly disassemble the whole ROM. The result is pretty clean in 
the Listing (disassembly) view. Of course, this is only a workaround, as 
this doesn't fix the decompile view (unlike your language patch). I pushed 
the result.

Another hint, not sure if it is well-known.
This is about the book "Atari ST Intern" from Data Becker.

I've got some French version named "Le livre du développeur sur Atari ST" 
(Micro Application, 1989). This edition includes, at the end, a full 
disassembly of the BIOS for German TOS 1.00 and TOS 1.02. Comments are 
translated to French. But for some functions, labels are mentioned. It seems 
that the authors had somehow access to the original labels. So this seems to 
be a good source for original BIOS labels.

The English translation is "Atari ST Internals", by Abacus Software.
The 3rd edition is on the Atari Document Archive.
https://docs.dev-docs.org/
See "Out of Print Books" on the left, then "Atari ST - Internals (Abacus #2, 
3rd edition) [Jan 1988]".
At the end, there is the disassembly of German TOS 1.0, with English 
comments. And some original labels, as I said.

The code before the keyboard handler matches perfectly with tos100fr.img. 
But as Thorsten said, the code after is shifted by a few bytes, due to 
language differences. Anyway, it's a good thing to be able to find multiple 
sources of information.

-- 
Vincent Rivière

Re: [Freemint-discuss] Disassembly of TOS 1.00 with Ghidra

[Thorsten O. <ad...@th...>]

Had partly success with my patched processor definition. The decompiler now 
atleast does not barf on the linef-call anymore. A simple function now looks 
like this:




linefcall(0x708) is the call to get_par().


The strange assignment to obj in line 9 is, because ghidra does not know yet 
that linefcall() is a function that returns a value in d0.

I've also pushed an updated archive. Functions from desktop are almost 
complete, except for a few which seem to be related to an older implementation 
of the textfile viewer, and the format dialog.

Re: [Freemint-discuss] Disassembly of TOS 1.00 with Ghidra

[Thorsten O. <ad...@th...>]

Found some interesting bug in the meantime.

In TOS 1.00, the THEDSK structure (which holds most variables of the desktop) 
is larger than 32k. The g_screen array (which holds the icons placed on the 
desktop background) starts at offset 31900, and has 133 items. That makes 
routines like obj_init (at 0xfdff56) and obj_ialloc (at 0xfe0134) produce code 
that write into other parts of the structure. Ghidra is also confused by this:

Re: [Freemint-discuss] Disassembly of TOS 1.00 with Ghidra

[Thorsten O. <ad...@th...>]

On Freitag, 10. Januar 2025 00:12:14 CET Vincent Rivière wrote:
> It will have to
> be tweaked to produce the expected output format, but basically it's there.

I think that should already almost work, except that you need to add the 
symbol type. For the ROMs, that is easy: you can just treat everything >= 
0xfc0000 as text('T'), and everything else as bss ('B') . Maybe the system 
variables < 0x800 should also be ommitted (IIRC Hatari has them builtin)