Menu
▾
▴
freemint-discuss
|
From: Thorsten O. <ad...@th...> - 2025-01-20 13:23:40
|
On Montag, 20. Januar 2025 14:16:28 CET Vincent Rivière wrote: > Where did you find them? In old sources, either the archive i posted earlier, or very old emutos sources, like the ones from commit f29cf59f826ab0a3957be1a12387ac809d89dba5 |
|
From: Thorsten O. <ad...@th...> - 2025-01-20 13:29:14
|
PS.: with VDI, it seems to be similar. The sources seem to be more similar to the lisa sources, than to the routines found in later (blitter enhanced) VDI versions. |
|
From: Thorsten O. <ad...@th...> - 2025-01-22 19:03:19
|
VDI now also finished. Also some minor tweaks to BIOS (protobt writes 0xf8 media byte for SS, 80 tracks instead of 0xf9). The "make check" target still does not work, because bios,gemdos+vdi have to be combined into one part, and aes+desktop into another to get the initialized data where it is located in the ROMs. But you can use dd to extract those parts (up to address 0xfd91d0 of the french ROM, the function gemstart of the AES), and compare that to the original. Only works for the french version so far (still have to figure out where the german version differs), but already includes the resource data of the desktop. The sources are a strange mix: the assembler sources gsxasm1.S and gsxasm2.S are now mostly identical to the lisa sources, while the rest is mostly identical to the 1.04 sources (expect in places where blitter support was added). Apropos lisa sources: in those, there are two settings used, vme and rev_vid. The readme for this (https://github.com/emutos/emutos/blob/ f29cf59f826ab0a3957be1a12387ac809d89dba5/vdi/screen.hlp) mentions: The first, VME10, should always be equal to zero. This causes the code generated to work for the contiguous plane memory layout. The code switched out by these switches is for other memory layouts, However, most of the code is compiled as if the vme setting has been set to one. I removed them from the sources though (just like emutos did long ago), to make the code better readable. |
|
From: Thorsten O. <ad...@th...> - 2025-01-23 12:21:14
|
Ghidra seems to have problems detecting accesses to arrays inside a structure. Eg. the code d->g_ismask[(int16_t) d->iconaddr[i].ib_pmask] = TRUE; is compiled by Alcyon to The variable d is a pointer to THEDSK (in the assembly in a5), and i is in d5. 0x22 is sizeof(ICONBLK), the elements of the iconaddr array. 0x721c is the offset to the iconaddr array in that structure, and happens to also be the absolute value of the bss variable W_ACTIVE. 0x73b4 is the offset to the g_ismask array. The decompiler also produces nonsense: |
|
From: Thorsten O. <ad...@th...> - 2025-01-23 13:48:59
|
PS.: mkrom: tos.img is too big: 116 extra bytes Getting closer ;) |
|
From: Thorsten O. <ad...@th...> - 2025-01-29 15:16:06
|
On Dienstag, 14. Januar 2025 15:07:13 CET Thorsten Otto via Freemint-discuss wrote: > The desktop resource has 2 items in the menu that are not linked in the tree > structure. The format resource is even much stranger. According to the resource header, it has 1 tree, and 26 objects. However, the first tree (the copy/format dialog) has 11 objects, but only object #11 has the LASTOB flag set (the first object of the 2nd tree). Objects 11-16 seem to be another tree, and objects 17-25 another. The routines only fetch the address of the first tree, and access the objects of the others from there. What the hell did they think? I had to hack at ORCS just to able to load them, and assign object names. Interface is also quite confused. All the RCS from DRI i tried even think the file has only 10 objects. And of course, the rsh_rssize field does not match the actual filesize. How did they create such strange resource files? |
|
From: Thorsten O. <ad...@th...> - 2025-01-29 16:30:40
|
And another strange i noticed: the format/copy routine call Dbmsg(), with the device number of the floppy, and use the result as parameter for the skewtable of the Flopfmt() call. Could it be that this XBIOS function originally had a different purpose? It is not implemented in any ROM, and always returns 0L. |
|
From: Thorsten O. <ad...@th...> - 2025-01-30 12:58:16
|
On Donnerstag, 23. Januar 2025 14:48:50 CET Thorsten Otto via Freemint-discuss wrote: > Getting closer ;) Success. French version is now complete, and compiles to identical image :D |
|
From: Thorsten O. <ad...@th...> - 2025-01-31 11:43:05
|
On Donnerstag, 30. Januar 2025 13:58:03 CET Thorsten Otto via Freemint-discuss wrote: > Success. French version is now complete, and compiles to identical image :D The others (de, fr and dk) are now also ready. The dk ROM is just a patched german version. |
|
From: Vincent R. <vin...@fr...> - 2025-01-30 19:51:25
|
On 30/01/2025 at 13:58, Thorsten Otto via Freemint-discuss wrote: > Success. French version is now complete, and compiles to identical > image :D Well done, Thorsten 😃 TOS 1.0 has no more secret for you. -- Vincent Rivière |
|
From: Thorsten O. <ad...@th...> - 2025-01-31 11:39:58
|
On Donnerstag, 30. Januar 2025 20:51:11 CET Vincent Rivière wrote: > TOS 1.0 has no more secret for you. I'm still curious about the build process back in the days. The LineF hack is currently implemented by a modified compiler/assembler. Surely they used something different. Also the way the ROM is linked in two parts currently is handled by linking the 2nd half of the ROM at the absolute address of the end of the 1st half, then putting them together with the mkrom utility. I tried with partially linking, but that did not work: you still end up with two large objects that both have text & data, and when you link that, the data segment will be put at the end, as usual. And some other mysteries still remain. The glued resource files are too large for example, and contain some garbage at the end that is nowhere used. Also those resource files are really strange, and cannot be changed without corrupting everything. And why they did some juggling with the AES global array when starting the copy/format dialog also is hard to understand. |
|
From: Thorsten O. <ad...@th...> - 2025-01-31 10:09:57
|
On Samstag, 4. Januar 2025 11:55:02 CET Thorsten Otto via Freemint-discuss wrote: > In TOS 1.04 and later, such addresses typically only differ by a few bytes, > caused by different handling of alt-keys in the bios. But in this case, > they differ by more than 800 bytes. So, given the different dates of the > ROMs, i wonder whether language versions like de/fr were maybe already > compiled from slightly newer versions of the code? BTW, that address differences are just caused by the way the ROMs are organized. In TOS 1.00 (and also 1.02), the resource data is at the end of the BIOS/GEMDOS/VDI segment, therefor the length of that file affects all AES/ DESKTOP addresses. Nevertheless, the US version uses a slightly older version of code in the showfile() function. Which, btw, also has an influence on the linef table (there are 2 more entries, and some others are swapped). |
|
From: Vincent R. <vin...@fr...> - 2025-01-31 10:36:10
|
On 31/01/2025 at 11:09, Thorsten Otto via Freemint-discuss wrote: > BTW, that address differences are just caused by the way the ROMs are > organized. BTW, there is something I haven't looked at: TOS 1.00 on floppy. I wonder if it is the same as the ROM version. Maybe a bit older. EDIT: I forgot that we already discussed that recently. That floppy version has mushrooms instead of bombs. That's a first difference. Addresses will of course differ, but I guess that the content should me mostly similar. -- Vincent Rivière |
|
From: Thorsten O. <ad...@th...> - 2025-01-31 11:12:06
|
On Freitag, 31. Januar 2025 11:35:53 CET Vincent Rivière wrote: > but I guess that the content should me > mostly similar. I think there will be more differences. It does not have any ROM header, for example. Which, unfortunately, makes it impossible to say from which exact release date it is. The GEM_MUPB structure is also missing. It also seems to have a routine at the start that copies everyting to absolute address $5000 (us) or $6100 (de), and a few more things. Also it could be that most of the hardware init was done by the minimal ROM from those early STs. |
|
From: Thorsten O. <ad...@th...> - 2025-02-03 15:06:49
|
On Freitag, 17. Januar 2025 10:18:58 CET Vincent Rivière wrote: > Main thing is a memory leak in TOS 1.00 Fsfirst. This means ixsfirst and > more precisely the "scan" function. BTW, did you try your test program also with TOS 1.02? From what i've seen, the GEMDOS is almost identical to that of 1.00, main difference is that they increased the osmem pool from 3000 to 8000 words. But that only means it would take longer to trigger the bug. |
|
From: Vincent R. <vin...@fr...> - 2025-02-03 16:53:33
|
On 03/02/2025 at 16:06, Thorsten Otto via Freemint-discuss wrote: > > Main thing is a memory leak in TOS 1.00 Fsfirst. This means ixsfirst and > > more precisely the "scan" function. > > BTW, did you try your test program also with TOS 1.02? Hum... I think so, but not sure. I made so many tests... My feeling was that it worked well with TOS 1.02. But initially, I hadn't all the internal traces. > From what i've seen, the GEMDOS is almost identical to that of 1.00, > main difference is that they increased the osmem pool from 3000 to > 8000 words. But that only means it would take longer to trigger the > bug. Very possible. I will look at that again, later. -- Vincent Rivière |
|
From: Thorsten O. <ad...@th...> - 2025-02-04 06:59:00
|
On Dienstag, 7. Januar 2025 21:52:53 CET Eero Tamminen wrote: > => Could those TOS address & symbol names be provided as Hatari (= nm > format) symbol files, along with checksums for matching original TOS images? For TOS 2.x/3.x/1.4 such maps already exist (as for example tos306de.map in the glue directory: https://github.com/th-otto/tos3x/blob/master/glue/ tos306de.map) However those were generated automatically, and could need some cleanup for Hatari's purpose. So i would like to know how they should look like. - they have some absolute symbols like SELECTED that are used in assemmly sources. I guess it is better to remove those? - they also have absolute symbols for the system variables. Should those be retained? - same for absolute symbols for I/O addresses. - there are some duplicates that should definitely be removed - Also note that BSS starts at address 0, unlike normal program layout. Could this lead to problems? - there are some symbols from the VDI overlay area, that appear as absolute, but are actually BSS variables. However they overlap with other symbols. - What about local labels from assembler code? Mostly they are from BIOS + VDI. Would it be better to remove them (for the profiler to work), or retain them to easier identify exact locations? - TOS 1.00/1.02 have another difficulty: there are text symbols from BIOS/ GEMDOS/VDI, followed by data symbols, then followed by text symbols from AES/ DESKTOP. Could those data symbols confuse Hatari? |
|
From: Thorsten O. <ad...@th...> - 2025-02-05 06:54:33
|
Just pushed slightly cleaned up symbol maps (for all TOS versions that can currently be build, so basically everything except 1.02 and 4.04). They are in https://github.com/th-otto/tos3x/tree/master/hatari (note that some of the ROM images itself are in the other repo, https://github.com/th-otto/tos1x/tree/ master/roms) Please let me know what do you think about these, or if you spot any problems. |
|
From: Eero T. <oa...@he...> - 2025-02-05 12:52:08
|
Hi, On 4.2.2025 8.58, Thorsten Otto via Freemint-discuss wrote: > On Dienstag, 7. Januar 2025 21:52:53 CET Eero Tamminen wrote: >> => Could those TOS address & symbol names be provided as Hatari (= nm >> format) symbol files, along with checksums for matching original TOS images? > > For TOS 2.x/3.x/1.4 such maps already exist (as for example tos306de.map in > the glue directory: https://github.com/th-otto/tos3x/blob/master/glue/ > tos306de.map) However those were generated automatically, and could need some > cleanup for Hatari's purpose. So i would like to know how they should look > like. > > - they have some absolute symbols like SELECTED that are used in assemmly > sources. I guess it is better to remove those? Absolute symbols are not used for values in disassembly. Only use for them would be in breakpoints for variable value comparisons, but it's really marginal use. IMHO indeed it's better to remove them. > - they also have absolute symbols for the system variables. Should those be > retained? > > - same for absolute symbols for I/O addresses. Yes, those are useful. > - there are some duplicates that should definitely be removed > > - Also note that BSS starts at address 0, unlike normal program layout. Could > this lead to problems? It depends on compiler whether BSS addresses start from program start, or from BSS section start, and Hatari code should already handle that, so it should be fine. > - there are some symbols from the VDI overlay area, that appear as absolute, > but are actually BSS variables. However they overlap with other symbols. It would be good for them to have correct type, as absolute symbols are ignored in several contexts, where data/BSS symbols can be used (e.g. for TAB-completion). > - What about local labels from assembler code? Mostly they are from BIOS + > VDI. Would it be better to remove them (for the profiler to work), or retain > them to easier identify exact locations? Labels for loops are actively harmful. Profiler adds each encountered symbols to callstack, so labeled loops: * Can slow down profiler a lot * Distort accumulated call counts, making call count callgraphs less useful As to other local symbols, I've rarely found use for them. Once one has identified issue down to a function / subroutine level, it's rather obvious from profiler instruction counts how the code flowed inside given function. => Remove at least all loop labels, or all local ones if it's more convenient > - TOS 1.00/1.02 have another difficulty: there are text symbols from BIOS/ > GEMDOS/VDI, followed by data symbols, then followed by text symbols from AES/ > DESKTOP. Could those data symbols confuse Hatari? IHMO symbol files are best to be sorted by address. - Eero |
|
From: Thorsten O. <ad...@th...> - 2025-02-05 13:28:02
|
On Mittwoch, 5. Februar 2025 13:51:58 CET Eero Tamminen wrote: > Yes, those are useful. I have removed them from the rom tables, but copied them to separate files, since they are always identical. Can easily be prepended to the maps again, so hatari only has to deal with one file. >It would be good for them to have correct type, as absolute symbols are >ignored in several contexts, Hm ok. So they should be changed to BSS instead. Not a big deal, however they are only actually accessed in rare cases (they are used by the seedfill algorithm). >=> Remove at least all loop labels, or all local ones if it's more >convenient Hm, that is going to be difficult. Removing all locals would also remove entry points of static functions. And there are lots of them that are not loop labels, but rather branch targets for if/else in the assembler sources etc. Any idea how to remove them automatically? There are currently 55 files, with 3000-4500 labels each. >IHMO symbol files are best to be sorted by address. Yes, they are. But those ROMs actually have two data and two text segments, and the first data segment is in the middle of the ROM. |
|
From: Eero T. <oa...@he...> - 2025-02-05 19:32:37
|
Hi,
On 5.2.2025 15.27, Thorsten Otto via Freemint-discuss wrote:
> On Mittwoch, 5. Februar 2025 13:51:58 CET Eero Tamminen wrote:
>> Yes, those are useful.
>
> I have removed them from the rom tables, but copied them to separate files,
> since they are always identical. Can easily be prepended to the maps again, so
> hatari only has to deal with one file.
Dropping absolute symbols is fine too. Code symbols are most useful,
data ones next and absolute symbol less so, as they are not used by any
of the builtin debugger functionality, only by debugger users.
Marking system variables symbols as data types may help their use in
Hatari debugger (I don't remember anymore which places in debugger limit
symbol types).
>> It would be good for them to have correct type, as absolute symbols are
>> ignored in several contexts,
>
> Hm ok. So they should be changed to BSS instead. Not a big deal, however they
> are only actually accessed in rare cases (they are used by the seedfill
> algorithm).
Ah, that's a really rarely used function (partly due to its perf). No
real loss then...
>> => Remove at least all loop labels, or all local ones if it's more
>> convenient
>
> Hm, that is going to be difficult. Removing all locals would also remove entry
> points of static functions. And there are lots of them that are not loop
> labels, but rather branch targets for if/else in the assembler sources etc.
> Any idea how to remove them automatically? There are currently 55 files, with
> 3000-4500 labels each.
GCC uses special prefix for local symbols (".L<number>"), so it was easy
to remove local symbols it generates.
If TOS ones cannot be removed easily in an automated way, they can
always be left into symbol file and if some of them turn out to be
noticeably problematic, I guess they can be removed (manually) later on...
>> IHMO symbol files are best to be sorted by address.
>
> Yes, they are. But those ROMs actually have two data and two text segments,
> and the first data segment is in the middle of the ROM.
I don't think that's a problem, but you could try when Hatari imports it OK.
- Eero
|
|
From: Thorsten O. <ad...@th...> - 2025-02-06 08:10:31
|
On Mittwoch, 5. Februar 2025 20:32:27 CET Eero Tamminen wrote:
> GCC uses special prefix for local symbols (".L<number>"), so it was easy
> to remove local symbols it generates.
The compiler generated symbols are already removed. The remaining ones are
from assembler code, like https://github.com/th-otto/tos3x/blob/
4802009c9b8a77ec1befc70055576e304834dd1c/hatari/tos306us.sym#L1865-L1872
which are from code like https://github.com/th-otto/tos3x/blob/
4802009c9b8a77ec1befc70055576e304834dd1c/vdi/line1010.S#L113-L141
>I don't think that's a problem, but you could try when Hatari imports it OK.
Seems to work. It only complains about
Removed 55 symbols in same addresses as other symbols.
That seem to be local symbols with the same name from different sources, which
is perfectly valid. IMHO Hatari should not remove them. BTW, the detailed list
of them is omitted if autoload is enabled, even if i load them manually with
the "symbol <filename>" command.
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X