freemint-discuss — The official FreeMiNT Mailing List

Re: [Freemint-discuss] vq_devinfo and vqt_devinfo

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

Hi Olivier,

On Mon, 24 Mar 2025 at 19:58, OL <o....@lu...> wrote:

> Looking at toshyp documentation and NVDI 4 english documentation, look
> like there is a small error, third parameter, shoudl not be dev_exist
> but dev_open,

I guess you meant *gemlib* and NVDI4 documentation? TOS.HYP correctly lists
it as dev_open, it is gemlib which goes an extra mile and slightly changed
the function signature AFAICS.


> so the return if driver is found could not be always 1 but
> could be 0 link to vdi_ptsout[0], this value is here the return value
> while documentation said void, return value could be interesting but not
> this one, better I think should be the actual value in dev_exist if we
> want have one (usefull for vqt_devinfo). If something is changed in
> vq_devinfo, warning it impact vqt_devinfo that call it.
>
I'm not sure I completely follow, I guess you are referring to gemlib here?
Maybe propose a patch if you would like to have something changed there?

vqt_devinfo, there is not same number of parameters between gemlib
> and toshyp

This again seems like some kind of oddity in gemlib.

Since you are way more experienced in GEM programming than I am, I can only
repeat my request for providing a patch. :-)

-- 
http://mikro.atari.org

Re: [Freemint-discuss] Weird problem with MiNTnet

[Björn B. <bj...@cu...>]

That would have been a packet fragmentation issue. Some node in the 
chain would have an MTU <1500. Had to troubleshoot a zillion of those 
with PPPoE in the zero years, before somewhat intelligent routers came 
to people's homes.

Peace,

       Björn Buske
-->bj...@cu... <--

On 20.04.25 20:03, Peter Slegg via Freemint-discuss wrote:
> The weirdest thing I ever had was caused by the packet size. I 
> couldn't send anything over a certain size.
>
> Once the packet size was changed everything worked normally.
>
> Peter
> On 20 Apr 2025, at 17:37, "Miro Kropáček" <mir...@gm...> 
> wrote:
>
>     I can only speculate that something changed on your router, i.e.
>     it suddenly became sensitive to some of MiNT-Net's settings.
>     Really odd.
>
>     On Thu, 17 Apr 2025 at 21:33, Jo Even Skarstein via
>     Freemint-discuss <fre...@li...> wrote:
>
>         I've ran into a weird problem with MiNTnet. Suddenly none of
>         my Ataris running MiNTnet are available to other devices on my
>         LAN, except the router. Networking between my Ataris works
>         normally, and I can ping my other devices (PC's running Linux
>         or Windows) from my Ataris but not vice versa. I can't access
>         any servers on my PC's from my Ataris, but any external
>         servers (ftp, http, mail...) works fine. This happened
>         suddenly and at the same time for all my Ataris, so the
>         problem is not caused by any changes on the Atari side.
>
>         What's strange is that if I boot TOS and run UIPtool instead
>         of MiNT/MiNTnet everything works fine. The Atari is assigned
>         the same IP as under MiNTnet (using DHCP in both cases), but
>         with UIPtool running I can access the Atari from any device on
>         my LAN.
>
>         Any idea on what's going on?
>
>         Jo Even
>
>
>         _______________________________________________
>         Freemint-discuss mailing list
>         Fre...@li...
>         https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>
>
>
>     -- 
>     http://mikro.atari.org
>
>     ------------------------------------------------------------------------
>
>     Freemint-discuss mailing list
>     Fre...@li...
>     https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>
>
>
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss

Re: [Freemint-discuss] Weird problem with MiNTnet

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

The weirdest thing I ever had was caused by the packet size. I couldn't send anything over a certain size. 

Once the packet size was changed everything worked normally.

⁣Peter​

On 20 Apr 2025, 17:37, at 17:37, "Miro Kropáček" <mir...@gm...> wrote:
>I can only speculate that something changed on your router, i.e. it
>suddenly became sensitive to some of MiNT-Net's settings. Really odd.
>
>On Thu, 17 Apr 2025 at 21:33, Jo Even Skarstein via Freemint-discuss <
>fre...@li...> wrote:
>
>> I've ran into a weird problem with MiNTnet. Suddenly none of my
>Ataris
>> running MiNTnet are available to other devices on my LAN, except the
>> router. Networking between my Ataris works normally, and I can ping
>my
>> other devices (PC's running Linux or Windows) from my Ataris but not
>vice
>> versa. I can't access any servers on my PC's from my Ataris, but any
>> external servers (ftp, http, mail...) works fine. This happened
>suddenly
>> and at the same time for all my Ataris, so the problem is not caused
>by any
>> changes on the Atari side.
>>
>> What's strange is that if I boot TOS and run UIPtool instead of
>> MiNT/MiNTnet everything works fine. The Atari is assigned the same IP
>as
>> under MiNTnet (using DHCP in both cases), but with UIPtool running I
>can
>> access the Atari from any device on my LAN.
>>
>> Any idea on what's going on?
>>
>> Jo Even
>>
>>
>> _______________________________________________
>> Freemint-discuss mailing list
>> Fre...@li...
>> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>>
>
>
>-- 
>http://mikro.atari.org
>
>
>------------------------------------------------------------------------
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Freemint-discuss mailing list
>Fre...@li...
>https://lists.sourceforge.net/lists/listinfo/freemint-discuss

Re: [Freemint-discuss] Weird problem with MiNTnet

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

I can only speculate that something changed on your router, i.e. it
suddenly became sensitive to some of MiNT-Net's settings. Really odd.

On Thu, 17 Apr 2025 at 21:33, Jo Even Skarstein via Freemint-discuss <
fre...@li...> wrote:

> I've ran into a weird problem with MiNTnet. Suddenly none of my Ataris
> running MiNTnet are available to other devices on my LAN, except the
> router. Networking between my Ataris works normally, and I can ping my
> other devices (PC's running Linux or Windows) from my Ataris but not vice
> versa. I can't access any servers on my PC's from my Ataris, but any
> external servers (ftp, http, mail...) works fine. This happened suddenly
> and at the same time for all my Ataris, so the problem is not caused by any
> changes on the Atari side.
>
> What's strange is that if I boot TOS and run UIPtool instead of
> MiNT/MiNTnet everything works fine. The Atari is assigned the same IP as
> under MiNTnet (using DHCP in both cases), but with UIPtool running I can
> access the Atari from any device on my LAN.
>
> Any idea on what's going on?
>
> Jo Even
>
>
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>


-- 
http://mikro.atari.org

[Freemint-discuss] Weird problem with MiNTnet

[Jo E. S. <jo...@on...>]

I've ran into a weird problem with MiNTnet. Suddenly none of my Ataris running MiNTnet are available to other devices on my LAN, except the router. Networking between my Ataris works normally, and I can ping my other devices (PC's running Linux or Windows) from my Ataris but not vice versa. I can't access any servers on my PC's from my Ataris, but any external servers (ftp, http, mail...) works fine. This happened suddenly and at the same time for all my Ataris, so the problem is not caused by any changes on the Atari side.

What's strange is that if I boot TOS and run UIPtool instead of MiNT/MiNTnet everything works fine. The Atari is assigned the same IP as under MiNTnet (using DHCP in both cases), but with UIPtool running I can access the Atari from any device on my LAN.

Any idea on what's going on?

Jo Even

[Freemint-discuss] vq_devinfo and vqt_devinfo

[OL <o....@lu...>]

Hello


Looking at toshyp documentation and NVDI 4 english documentation, look 
like there is a small error, third parameter, shoudl not be dev_exist 
but dev_open, so the return if driver is found could not be always 1 but 
could be 0 link to vdi_ptsout[0], this value is here the return value 
while documentation said void, return value could be interesting but not 
this one, better I think should be the actual value in dev_exist if we 
want have one (usefull for vqt_devinfo). If something is changed in 
vq_devinfo, warning it impact vqt_devinfo that call it.


vqt_devinfo, there is not same number of parameters between gemlib and 
toshyp


Olivier

Re: [Freemint-discuss] Strange bug with asm clobbers

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

Hmm, it reminds me of https://github.com/freemint/freemint/issues/285 but
this time it looks like behaving the other way around?

Dňa so 22. 3. 2025, 14:07 Thorsten Otto via Freemint-discuss <
fre...@li...> napísal(a):

> Hi,
>
> while trying to write a test program, i encountered a strange bug with gcc
> asm
> clobber list. The code in question is
>
>         register unsigned short *start __asm__("a0");
>         unsigned short *end;
>         oldsp = Super(0);
>         start = buf + sizeof(buf) / sizeof(buf[0]);
>         __asm__ __volatile__(
>                   ".dc.w 0xf320,0x4e71,0x4e71,0x4e71\n" /* fsave -(a0)
> */
>                   "move.l %1,%0\n"
>                 : "=a"(end)
>                 : "a"(start)
>                 : );
>         SuperToUser(oldsp);
>
>         printf("start: %08lx end: %08lx size: %ld\n", (long)end,
> (long)start, (long)start - (long)end);
>
> And the generated code is:
>
> [0000014a] 7000                      moveq.l    #0,d0
> [0000014c] 2f00                      move.l     d0,-(a7)
> [0000014e] 3f3c 0020                 move.w     #$0020,-(a7) ; Super
> [00000152] 4e41                      trap       #1
> [00000154] 5c8f                      addq.l     #6,a7
> [00000156] 41f9 0001 94c8            lea.l      $000193E4,a0
> [0000015c] f320                      fsave      -(a0)
> [0000015e] 4e71                      nop
> [00000160] 4e71                      nop
> [00000162] 4e71                      nop
> [00000164] 2648                      movea.l    a0,a3
> [00000166] 2a4f                      movea.l    a7,a5         <--
> apparently
> the backup_sp from SuperToUser macro
> [00000168] 2f00                      move.l     d0,-(a7)
> [0000016a] 3f3c 0020                 move.w     #$0020,-(a7) ; Super
> [0000016e] 4e41                      trap       #1
> [00000170] 2e4d                      movea.l    a5,a7
> [00000172] 2008                      move.l     a0,d0         <-- using
> a0,
> although it was declared as being clobbered???
> [00000174] 908b                      sub.l      a3,d0
> [00000176] 2f00                      move.l     d0,-(a7)
> [00000178] 2f08                      move.l     a0,-(a7)
> [0000017a] 2f0b                      move.l     a3,-(a7)
> [00000186] 487a ff3a                 pea.l      .LC0(pc)
> [0000018a] 4eb9 0000 2998            jsr        _printf
>
>
> As seen above, gcc seems to assume that "a0" still contains the value of
> start, although is was declared as being clobbered in the SuperToUser
> macro.
>
> Did i miss something, or what is going wrong there?
>
>
>
>
>
>
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>

[Freemint-discuss] Strange bug with asm clobbers

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

Hi,

while trying to write a test program, i encountered a strange bug with gcc asm 
clobber list. The code in question is

	register unsigned short *start __asm__("a0");
	unsigned short *end;
	oldsp = Super(0);
	start = buf + sizeof(buf) / sizeof(buf[0]);
	__asm__ __volatile__(
		  ".dc.w 0xf320,0x4e71,0x4e71,0x4e71\n" /* fsave -(a0) 
*/
		  "move.l %1,%0\n"
		: "=a"(end)
		: "a"(start)
		: );
	SuperToUser(oldsp);

	printf("start: %08lx end: %08lx size: %ld\n", (long)end, 
(long)start, (long)start - (long)end);

And the generated code is:

[0000014a] 7000                      moveq.l    #0,d0
[0000014c] 2f00                      move.l     d0,-(a7)
[0000014e] 3f3c 0020                 move.w     #$0020,-(a7) ; Super
[00000152] 4e41                      trap       #1
[00000154] 5c8f                      addq.l     #6,a7
[00000156] 41f9 0001 94c8            lea.l      $000193E4,a0
[0000015c] f320                      fsave      -(a0)
[0000015e] 4e71                      nop
[00000160] 4e71                      nop
[00000162] 4e71                      nop
[00000164] 2648                      movea.l    a0,a3
[00000166] 2a4f                      movea.l    a7,a5         <-- apparently 
the backup_sp from SuperToUser macro
[00000168] 2f00                      move.l     d0,-(a7)
[0000016a] 3f3c 0020                 move.w     #$0020,-(a7) ; Super
[0000016e] 4e41                      trap       #1
[00000170] 2e4d                      movea.l    a5,a7
[00000172] 2008                      move.l     a0,d0         <-- using a0, 
although it was declared as being clobbered???
[00000174] 908b                      sub.l      a3,d0
[00000176] 2f00                      move.l     d0,-(a7)
[00000178] 2f08                      move.l     a0,-(a7)
[0000017a] 2f0b                      move.l     a3,-(a7)
[00000186] 487a ff3a                 pea.l      .LC0(pc)
[0000018a] 4eb9 0000 2998            jsr        _printf


As seen above, gcc seems to assume that "a0" still contains the value of 
start, although is was declared as being clobbered in the SuperToUser macro.

Did i miss something, or what is going wrong there?

Re: [Freemint-discuss] FPU emulation

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

On Montag, 3. März 2025 20:18:33 CET Eero Tamminen wrote:
> Is there no way to enable fsave/frestore at run-time only for programs
> that use FPU regs / instructions?

To detect wether the FPU is in use, you have to use fsave already. If it was 
not in use, you will get a NULL frame.

>Or have e.g. program flag for enabling it?

That can't be done on a per-program basis, since you have to save the state 
also for other programs that might have used the FPU.

Re: [Freemint-discuss] FPU emulation

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

Hi,

On 1.3.2025 13.04, Thorsten Otto via Freemint-discuss wrote:
...
> 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.

Is there no way to enable fsave/frestore at run-time only for programs 
that use FPU regs / instructions?

Or have e.g. program flag for enabling it?


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


	- Eero

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.