freemint-discuss — The official FreeMiNT Mailing List

Re: [Freemint-discuss] FPU emulation

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

On Mon, 3 Mar 2025 at 10:39, Thorsten Otto via Freemint-discuss <
fre...@li...> wrote:

> Yes, that is also something i don't understand. Without emulation of
> atleast the instructions that are supported by 040, the emulator is rather
> useless.
>
> Maybe some rarely used opcodes like fsgldiv/fsdiv/fddiv etc. could be
> ommited, but not the trgonmetric functions.
>
I asked Geert, who contributed to that part of code recently and he doesn't
know either. He recommended asking in lin...@li....

-- 
http://mikro.atari.org

Re: [Freemint-discuss] FPU emulation

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

On Sonntag, 2. März 2025 20:51:48 CET Miro Kropáček wrote:
> Maybe you can quickly test it in Aranym,

That won't work, because i would need a linux/m68k kernel which has 
CONFIG_M68KFPU_EMU enabled.

But unless i missed something else, the lines 
https://github.com/torvalds/linux/blob/
7eb172143d5508b4da468ed59ee857c6e5e01da6/arch/m68k/kernel/vectors.c#L96

and 

https://github.com/torvalds/linux/blob/
7eb172143d5508b4da468ed59ee857c6e5e01da6/arch/m68k/kernel/vectors.c#L119

are rather clear: if the emulator is already installed, the FPSP won't be 
used.

>an application will succeed in executing fadd but not fsin? That doesn't 
make sense.

Yes, that is also something i don't understand. Without emulation of atleast 
the instructions that are supported by 040, the emulator is rather useless.
Maybe some rarely used opcodes like fsgldiv/fsdiv/fddiv etc. could be ommited, 
but not the trgonmetric functions.

Re: [Freemint-discuss] FPU emulation

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

On Sat, 1 Mar 2025 at 12:04, Thorsten Otto via Freemint-discuss <
fre...@li...> wrote:

> - it does not implement all the arithmetic function. I don't know how this
> is supposed to work, because either the emulation is installed, or one of
> the FPSP, but never both. So emulations for fasin etc. have to be written.
>
Hmm, that's weird. Maybe you can quickly test it in Aranym, where you
artificially disable the FPU, how does it behave? I can't imagine the
advantage there: an application will succeed in executing fadd but not
fsin? That doesn't make sense.

-- 
http://mikro.atari.org

[Freemint-discuss] FPU emulation

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

Hi,

I'm currently thinking about a softfloat FPU emulation, one that emulates 
*all* FPU instructions, as opposed to FPSP040/060 that only emulates the ones 
that have been dropped from those CPU versions. So this is mainly intended for 
Falcons without FPU, clones with 68EC040 etc. Of course that will be much 
slower than a real FPU, and maybe won't be suitable for FPU heavy applications 
like povray, but should atleast enable them to work instead of aborting 
because of a missing FPU.

There seem to be basically two already existing implementations that can be 
used as a basis, and i want to outline how they internally work, as found so 
far.

The first is one that is used by NetBSD, and which @agranlund also used as a 
basis for his raven clone: https://github.com/agranlund/raven/tree/main/sw/
tools/fpu_emu

It is mostly implemented in C, except for the atari-specific setup of the 
exception vectors. It uses a single, static set of emulated FPU registers 
(just like you would have on real hardware), which means it also has to 
emulate the fsave/frestore instruction on context switch.

The other is part of linux/m68k: https://github.com/torvalds/linux/tree/
master/arch/m68k/math-emu This one implements all the <ea> calculation in 
assembler, only the actual artithmetic functions are implemented in C. It 
maintains a per-thread set of FPU registers, which only works because it is 
part of the kernel, and thus has access to it. Because of this, it does not 
have to emulate fsave/frestore. For mint that would mean we also have to make 
it part of the kernel (could eventually be a module).

Now for the pros/cons:

pros for the linux version:
- obviously, doing the address calculation in assembler will be much faster. 
Not emulating fsave/frestore is not an option for us, since (unlike on linux), 
an application may switch to supervisor mode and use it itself, but 
implementing that should not be too hard. Not having to use them on context 
switch will still be a bit of speedup in a time-critical area.

cons for the linux version:
- it does not implement all the arithmetic function. I don't know how this is 
supposed to work, because either the emulation is installed, or one of the 
FPSP, but never both. So emulations for fasin etc. have to be written.
- it maintains a slightly different layout of 96bit double internally. This is 
not a problem, because of course it is converted to the expected format when 
written to memory. There are however 3 situations where it matters:
- when dumping a corefile. Does not matter for mint, since that is not 
implemented yet
- when building a signal context. As above, this is not implemented yet in 
mint
- When the process is traced and the FPU registers are read/written. This 
would actually have to be fixed in mint too, but is imho of rather low 
priority.

pros for the netbsd version:
It is easier to implement, and almost complete. Because it emulates also 
fsave/frestore, it could also be compiled as a standalone program, run from 
the auto-folder.

cons for the netbsd version:
It will be slower. Worst thing imho is that it will also slow down context 
switches, thus affecting overall performance, even if only one process uses 
the FPU.

So what do you think? For speed reasons, i would prefer the linux version, 
especially because of the penalty in context switches in the netbsd version.
But it requires some work to implement the missing functions.

Re: [Freemint-discuss] TOS symbol files

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

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.

Re: [Freemint-discuss] TOS symbol files

[Eero T. <oa...@he...>]

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

Re: [Freemint-discuss] USB debugging

[Peter S. <ps...@sc...>]

Ok. I forgot it was just the mint+elf.



⁣Peter​

On 5 Feb 2025, 14:23, at 14:23, Thorsten Otto via Freemint-discuss <fre...@li...> wrote:
>On Mittwoch, 5. Februar 2025 14:02:52 CET Peter Slegg via
>Freemint-discuss 
>wrote:
>> Hello,
>> 
>> If gdb is now working again, could it be used to debug the usb issues
>on the
>> Milan ?
>> 
>> 
>> ⁣Peter​
>
>Unlikely, since that is either a problem in the kernel or in the
>driver. Both 
>can hardly be debugged with gdb. Also remember that gdb only works with
>
>MiNT+ELF executables.
>
>
>
>------------------------------------------------------------------------
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Freemint-discuss mailing list
>Fre...@li...
>https://lists.sourceforge.net/lists/listinfo/freemint-discuss

Re: [Freemint-discuss] USB debugging

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

On Mittwoch, 5. Februar 2025 14:02:52 CET Peter Slegg via Freemint-discuss 
wrote:
> Hello,
> 
> If gdb is now working again, could it be used to debug the usb issues on the
> Milan ?
> 
> 
> ⁣Peter​

Unlikely, since that is either a problem in the kernel or in the driver. Both 
can hardly be debugged with gdb. Also remember that gdb only works with 
MiNT+ELF executables.

Re: [Freemint-discuss] TOS symbol files (was: Disassembly of TOS 1.00 with Ghidra)

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

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.

[Freemint-discuss] USB debugging

[Peter S. <ps...@sc...>]

Hello, 

If gdb is now working again, could it be used to debug the usb issues on the Milan ?


⁣Peter​

Re: [Freemint-discuss] TOS symbol files (was: Disassembly of TOS 1.00 with Ghidra)

[Eero T. <oa...@he...>]

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

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

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

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.

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

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

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?

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

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

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

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

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

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

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.

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

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

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.

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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?

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

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

PS.:

mkrom: tos.img is too big: 116 extra bytes

Getting closer ;)