freemint-discuss — The official FreeMiNT Mailing List

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

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

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:

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

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

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.

Re: [Freemint-discuss] XaAES often crashes during boot after a reboot

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

Good tips! I changed the program to set the free memory to 0x55, and if I run this program before mint.prg I can reproduce the crash almost every time on both the Milan and Falcon/CT60. Different network hardware, different drivers, same snapshot. Crashes somewhere between route (in mint.cnf) and starting the desktop.

Also, it does not happen if I don't run route. ifconfig alone does not cause the crash, ifconfig+route does.

I've attached the test program (no I haven't, the mail was rejected because of the .zip attachment. Get it here: https://atari.joska.no/download/memset.zip). It would be very interesting if you could reproduce this on your Falcon.

--------------->8------------------

#include <stdio.h>
#include <string.h>
#include <tos.h>

#define VALUE 0x55

int main(int argc, char **argv)
{
   long s, total = 0;

    printf("Setting all available memory to 0x%02x:\n", VALUE);

    printf("\nST-RAM:\n");
    while ((s = (long) Mxalloc(-1L, 0)) > 0)
    {
        char *m = Mxalloc(s, 0);
        printf("0x%08p (%ld Kb)\n", m, s / 1024L);
        memset(m, VALUE, s);
        total += s;
    }

    printf("\nFast-RAM:\n");
    while ((s = (long) Mxalloc(-1L, 1)) > 0)
    {
        char *m = Mxalloc(s, 1);
        printf("0x%08p (%ld Kb)\n", m, s / 1024L);
        memset(m, VALUE, s);
        total += s;
    }

    printf("\n%ld Kb set.\n\n", total / 1024L);
    return 0;
}

--------------8<-----------------

It must be run before mint.prg, if I run it from mint.cnf before ifconfig/route it doesn't make a difference. Same with clearing the RAM instead - do it before mint.prg and the crash never happens. So it looks like the kernel assumes that atleast one byte of the RAM it allocates is zeroed.

I run ifconfig/route as the last thing before GEM= in mint.cnf. GlueSTiK is started immediately before. It doesn't matter if GlueSTiK is started or not.

Jo Even

On Tue, 21 Jan 2025 14:04:05 +0100, "Miro Kropáček" <mir...@gm...> wrote:

>> - since your CT60 scenario is far less reproducible: what about filling RAM
>> with 0xFF instead of 0x00? Does it lead to more reliable crashes? (just to
>> be on the safe side, check on Milan before, too - the 0xFF may be one of
>> those "safe" ones)
>>
>> - do not run both ifconfig and route, just one of them and alternatively,
>> do not configure the given network interface, just the loopback one
 

Re: [Freemint-discuss] XaAES often crashes during boot after a reboot

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

On Tue, 21 Jan 2025 at 13:55, Jo Even Skarstein via Freemint-discuss <
fre...@li...> wrote:

> I should test another interface/driver on the Milan.

This is also a good idea but I'm afraid it wont tell us *that* much. It may
just call kernel functions in a different order, hiding the bug and it
would look like a driver issue.

 Two more hints:

- since your CT60 scenario is far less reproducible: what about filling RAM
with 0xFF instead of 0x00? Does it lead to more reliable crashes? (just to
be on the safe side, check on Milan before, too - the 0xFF may be one of
those "safe" ones)

- do not run both ifconfig and route, just one of them and alternatively,
do not configure the given network interface, just the loopback one

-- 
http://mikro.atari.org

Re: [Freemint-discuss] XaAES often crashes during boot after a reboot

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

Clearing RAM just prior to running ifconfig/route doesn't "fix" the problem, I have to clear RAM before running mint.prg.

I should test another interface/driver on the Milan. I'm using an RTL8139 PCI with Ozk's driver, but I have an ISA NE2000 that I bought with a driver back in 2001 too. Unfortunately I have misplaced the driver disk, I will have to look through some old backups and see if I can find it.

Jo Even



On Mon, 20 Jan 2025 21:36:55 +0100, "Miro Kropáček" <mir...@gm...> wrote:

>> On Mon, 20 Jan 2025 at 21:19, Jo Even Skarstein via Freemint-discuss <
>> fre...@li...> wrote:
>>
>> > With network set up - I don't have to use it, just set it up
>>
>> I presume you mean entering the right ifconfig / route parameters (network
>> interface) and bringing that interface up, right?
>>
>> One more idea: what if you run the clearing program just before ifconfig
>> and/or route ? So you take all the free memory, clear it and release. If
>> that fixes the issue then we might have another interesting pointer, i.e.
>> that with a high probability the problem is in ifconfig/route itself.
>>
>> --
>> http://mikro.atari.org >> _______________________________________________
>> Freemint-discuss mailing list
>> Fre...@li...
>> https://lists.sourceforge.net/lists/listinfo/freemint-discuss

Re: [Freemint-discuss] XaAES often crashes during boot after a reboot

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

On Mon, 20 Jan 2025 at 21:19, Jo Even Skarstein via Freemint-discuss <
fre...@li...> wrote:

> With network set up - I don't have to use it, just set it up

I presume you mean entering the right ifconfig / route parameters (network
interface) and bringing that interface up, right?

One more idea: what if you run the clearing program just before ifconfig
and/or route ? So you take all the free memory, clear it and release. If
that fixes the issue then we might have another interesting pointer, i.e.
that with a high probability the problem is in ifconfig/route itself.

-- 
http://mikro.atari.org

Re: [Freemint-discuss] XaAES often crashes during boot after a reboot

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

On Mon, 20 Jan 2025 20:45:31 +0100, "Miro Kropáček" <mir...@gm...> wrote:

>> Sorry I meant on the Falcon. Whatever happens on Milan is between you and
>> Milan ;-) because I have no means to debug it.

Yes I know, but I wanted to test it first on the Milan as the problem is much easier to reproduce than on the Falcon. If I know exactly what triggers it on the Milan it's easier to know what to test on the Falcon.

>> Ooh, this is a strong indicator indeed. I have been witnessing weird
>> crashes/freezes during the boot when booting with ifconfig/route commands
>> in mint.cnf, too but I couldn't find anyone else with similar issues nor a
>> way to debug it.

I can confirm that it behaves the same with the latest snapshot too. If I don't set up networking I can't reproduce the crashes. If I clear RAM before running mint.prg I can't reproduce the crashes with network enabled either.

With network set up - I don't have to use it, just set it up - it crashes sometime during boot after most warm resets. And I have observed the same as you, sometimes there is a crash when or immediately after route/ifconfig has ran. I will have to test more, but not tonight. With and without Gluestik, route/ifconfig from mint.cnf or after booting, driver versions etc...

Jo Even

Re: [Freemint-discuss] XaAES often crashes during boot after a reboot

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

On Mon, 20 Jan 2025 at 20:38, Jo Even Skarstein via Freemint-discuss <
fre...@li...> wrote:

> I could not boot a 100% stock setup, as XaAES wouldn't run any programs
> without Milan VDI and NVDI loaded.

Sorry I meant on the Falcon. Whatever happens on Milan is between you and
Milan ;-) because I have no means to debug it.


> But... I'm not able to reproduce the problem if networking is not set up.
> Setting up (ifconfig and route, not dhcp) and use networking introduce
> instability. Having the driver loaded but network not set up causes no
> issues. I will have to test with the current kernel (both Falcon and Milan
> is running the latest snapshot) and see if I see the same pattern there.

Ooh, this is a strong indicator indeed. I have been witnessing weird
crashes/freezes during the boot when booting with ifconfig/route commands
in mint.cnf, too but I couldn't find anyone else with similar issues nor a
way to debug it.

Ironically, now that I replaced my disk and introduced a slightly different
way of starting the network (still from mint.cnf, though), I don't see one
single crash anymore.

So anything you can bring to the table is more than welcome.

-- 
http://mikro.atari.org

Re: [Freemint-discuss] XaAES often crashes during boot after a reboot

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

I downloaded and tested the oldest snapshot (from 2021), the problem is there too. I could not boot a 100% stock setup, as XaAES wouldn't run any programs without Milan VDI and NVDI loaded. But... I'm not able to reproduce the problem if networking is not set up. Setting up (ifconfig and route, not dhcp) and use networking introduce instability. Having the driver loaded but network not set up causes no issues. I will have to test with the current kernel (both Falcon and Milan is running the latest snapshot) and see if I see the same pattern there.

Jo Even


On Sun, 19 Jan 2025 11:45:00 +0000, Jo Even Skarstein via Freemint-discuss <fre...@li...> wrote:

>> Not sure if I want to spend all the time that this requires... Also, the problem is a bit vague. While I can get it to crash quite consistently after a warm reboot, the crashes are not the same.
>>
>> https://atari.joska.no/Milan/crash-milan-1.jpg
>> https://atari.joska.no/Milan/crash-milan-2.jpg
>> https://atari.joska.no/Milan/crash-milan-3.jpg
>> https://atari.joska.no/Milan/crash-milan-4.jpg
>> https://atari.joska.no/Milan/crash-milan-5.jpg
>>
>>
>> How to reproduce (on my Milan):
>> - Boot to the desktop from a power-up.
>> - Run and exit some program.
>> - Do a warm reboot (I do this from the task manager).
>>
>> It will usually crash when starting XaAES when I do this. When it crashes the computer is locked up, resetting from the keyboard doesn't work. If I clear memory before running MiNT - either with my small program or by clearing the fastload-bit on mintmin.prg - this never happens. Have rebooted repeatedly for about half an hour without a single glitch.
>>
>> If I instead of rebooting the machine only restarts or quits XaAES (from the XaAES system menu) there is no problem.
>>
>> Btw you'll see in a couple of the screenshot that the last (and only) auto-folder-program is the FPU-emulator. I have also tested without running this and it makes no difference.
>>
>> The XaAES logfile says nothing.
>>
>> The problem happens less frequently on my CT60, but when it happens it is very similar to what happens on the Milan.
>>
>> Jo Even
>>
>> (btw. mikro - you sent me a mail about resuming testing of LEDstorm, could you resend it? I must have accidentally deleted it.)
>>
>> On Sat, 18 Jan 2025 21:53:36 +0100, "Miro Kropáček" wrote:
>>
>> >> Oh dear. Any chance you could grab some older snapshot from
>> >> https://tho-otto.de/snapshots/freemint/bootable and observe how it behaves?
>> >> I can't say I have noticed something like this on my CT60(+SV, sometimes)
>> >> setup. What does xaaes log say? Does it crash in the same place?
>> >>
>> >> On Sat, 18 Jan 2025 at 21:43, Jo Even Skarstein via Freemint-discuss <
>> >> fre...@li...> wrote:
>> >>
>> >> > On my CT60/SV I have noticed that XaAES very often crashes while
>> >> > starting up if I do a warm reboot. I have attributed this to the
>> >> > idiosyncrasies of the CT60, and "fixed" the problem by always doing a
>> >> > coldboot. On the CT60, a coldboot means that all fast-RAM is zeroed.
>> >> >
>> >> > Now, a couple of days ago I fired up my Milan which hasn't really been
>> >> > used for ages, as I somehow managed to mess up my trusty old MiNT-setup
>> >> > and couldn't get current snapshots to boot properly. After dealing with
>> >> > some hardware issues I noticed the same trend as on the Falcon - XaAES
>> >> > would often crash at various points while starting up. The Milan does
>> >> > not clear fast-RAM after a coldboot, so I wrote a small program that
>> >> > does this and ran it before MiNT in the autofolder. And now XaAES has
>> >> > booted without any problems every time. Which suggests that either the
>> >> > kernel or XaAES depends on some memory/variables being zeroed.
>> >> >
>> >> > 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] Disassembly of TOS 1.00 with Ghidra

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

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.

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

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

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

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

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

On 20/01/2025 at 09:54, Thorsten Otto via Freemint-discuss wrote:
> BDOS of 1.00 should now also compile to identical code

Fine.

> Since the memory management is completely different, i also renamed 
> those functions to their original names (xmgetblk & xmfreblk).

This was the names I was looking for!
Where did you find them?

-- 
Vincent Rivière

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

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

BDOS of 1.00 should now also compile to identical code (again, only checked 
manually, but only the some absolute references to the data segment differ).

I've left in some ifdef GEMDOS, but only for reference where bugs were fixed 
in later versions, or the behaviour actually changed. There are too many 
places with other small changes, so don't expect to be able to use the same 
source for 1.00 and later versions.

Since the memory management is completely different, i also renamed those 
functions to their original names (xmgetblk & xmfreblk).

Unfortunately, a lot of functions had to be moved to the same source file 
(fshand.c mostly). This is because there are bsr (short calls) to some other 
functions, and the assembler will only do that when they are defined in the 
same source. But you will already see from the symbol table, that the physical 
order of functions does not make much sense. Dunno how they achieved that, i'm 
quite sure it was originally not done by moving the function around, both the 
original sources and sources from later versions are more logically organized.

There are also some functions which apparently had unused local variables, 
maybe leftovers from some debug code. Again, those variables appear neither in 
the original nor in later sources.

And there are *lots* of bugs, some already known, some not. Eg. Pexec() does 
not close the file handle on error, Cconout() will crash when you try to write 
to a redirected file, Fwrite() only handles writes up to 32k when writing to 
con:/aux:, some possible memory leaks etc.

Re: [Freemint-discuss] XaAES often crashes during boot after a reboot

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

On Sun, 19 Jan 2025 at 14:00, Miro Kropáček <mir...@gm...> wrote:

> When I get home, I'll try to reproduce it on my CT60.
>
I gave it a good go of at least 10-15 reboots, nothing suspicious spotted.
I even installed SV_XBIOS and its NVDI drivers just to be close to your
CT60 setup. Basically I let it boot to Teradesk, started QED, quit QED and
CTRL+ALT+DEL.

At this point I guess the most helpful would be if you installed on your
CT60 Falcon clean snapshots from 2021, 2022, 2023, 2024 and the latest one,
enable only default NVDI5 and try to reproduce it (you can start with the
latest one so after you see the problem I can do the same). We can never
rule out influence of Taskbar, drivers, XaAES settings, ...

P.S. The regression I had introduced poisoned builds running on Milan/CTPCI
between 04.09.2022 - 12.10.2023 however for CT60 testing it shouldn't
matter.

-- 
http://mikro.atari.org

Re: [Freemint-discuss] XaAES often crashes during boot after a reboot

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

When I get home, I'll try to reproduce it on my CT60.

However it would help if you could confirm that at least *some* build
worked - i.e. take a random build from 2021, 2022, 2023, 2024 and try at
least those.

Although on Milan there's a catch as for a year there was this regression
of mine which I had introduced. I'm on my phone now so can't check the
dates but it's still worth doing the tests - even if you say 2021 was ok,
2022-2023 showed the regression and 2024 already has the warm boot issue.

Led Blur: I'll prepare a build for you today with some debug outputs (I'm
hugely sceptical but we shall see).

Dňa ne 19. 1. 2025, 12:45 Jo Even Skarstein via Freemint-discuss <
fre...@li...> napísal(a):

> Not sure if I want to spend all the time that this requires... Also, the
> problem is a bit vague. While I can get it to crash quite consistently
> after a warm reboot, the crashes are not the same.
>
> https://atari.joska.no/Milan/crash-milan-1.jpg
> https://atari.joska.no/Milan/crash-milan-2.jpg
> https://atari.joska.no/Milan/crash-milan-3.jpg
> https://atari.joska.no/Milan/crash-milan-4.jpg
> https://atari.joska.no/Milan/crash-milan-5.jpg
>
>
> How to reproduce (on my Milan):
> - Boot to the desktop from a power-up.
> - Run and exit some program.
> - Do a warm reboot (I do this from the task manager).
>
> It will usually crash when starting XaAES when I do this. When it crashes
> the computer is locked up, resetting from the keyboard doesn't work. If I
> clear memory before running MiNT - either with my small program or by
> clearing the fastload-bit on mintmin.prg - this never happens. Have
> rebooted repeatedly for about half an hour without a single glitch.
>
> If I instead of rebooting the machine only restarts or quits XaAES (from
> the XaAES system menu) there is no problem.
>
> Btw you'll see in a couple of the screenshot that the last (and only)
> auto-folder-program is the FPU-emulator. I have also tested without running
> this and it makes no difference.
>
> The XaAES logfile says nothing.
>
> The problem happens less frequently on my CT60, but when it happens it is
> very similar to what happens on the Milan.
>
> Jo Even
>
> (btw. mikro - you sent me a mail about resuming testing of LEDstorm, could
> you resend it? I must have accidentally deleted it.)
>
> On Sat, 18 Jan 2025 21:53:36 +0100, "Miro Kropáček" <
> mir...@gm...> wrote:
>
> >> Oh dear. Any chance you could grab some older snapshot from
> >> https://tho-otto.de/snapshots/freemint/bootable and observe how it
> behaves?
> >> I can't say I have noticed something like this on my CT60(+SV,
> sometimes)
> >> setup. What does xaaes log say? Does it crash in the same place?
> >>
> >> On Sat, 18 Jan 2025 at 21:43, Jo Even Skarstein via Freemint-discuss <
> >> fre...@li...> wrote:
> >>
> >> > On my CT60/SV I have noticed that XaAES very often crashes while
> >> > starting up if I do a warm reboot. I have attributed this to the
> >> > idiosyncrasies of the CT60, and "fixed" the problem by always doing a
> >> > coldboot. On the CT60, a coldboot means that all fast-RAM is zeroed.
> >> >
> >> > Now, a couple of days ago I fired up my Milan which hasn't really been
> >> > used for ages, as I somehow managed to mess up my trusty old
> MiNT-setup
> >> > and couldn't get current snapshots to boot properly. After dealing
> with
> >> > some hardware issues I noticed the same trend as on the Falcon - XaAES
> >> > would often crash at various points while starting up. The Milan does
> >> > not clear fast-RAM after a coldboot, so I wrote a small program that
> >> > does this and ran it before MiNT in the autofolder. And now XaAES has
> >> > booted without any problems every time. Which suggests that either the
> >> > kernel or XaAES depends on some memory/variables being zeroed.
> >> >
> >> > 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] XaAES often crashes during boot after a reboot

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

Not sure if I want to spend all the time that this requires... Also, the problem is a bit vague. While I can get it to crash quite consistently after a warm reboot, the crashes are not the same.

https://atari.joska.no/Milan/crash-milan-1.jpg
https://atari.joska.no/Milan/crash-milan-2.jpg
https://atari.joska.no/Milan/crash-milan-3.jpg
https://atari.joska.no/Milan/crash-milan-4.jpg
https://atari.joska.no/Milan/crash-milan-5.jpg


How to reproduce (on my Milan):
- Boot to the desktop from a power-up.
- Run and exit some program.
- Do a warm reboot (I do this from the task manager).

It will usually crash when starting XaAES when I do this. When it crashes the computer is locked up, resetting from the keyboard doesn't work. If I clear memory before running MiNT - either with my small program or by clearing the fastload-bit on mintmin.prg - this never happens. Have rebooted repeatedly for about half an hour without a single glitch.

If I instead of rebooting the machine only restarts or quits XaAES (from the XaAES system menu) there is no problem.

Btw you'll see in a couple of the screenshot that the last (and only) auto-folder-program is the FPU-emulator. I have also tested without running this and it makes no difference.

The XaAES logfile says nothing.

The problem happens less frequently on my CT60, but when it happens it is very similar to what happens on the Milan.

Jo Even

(btw. mikro - you sent me a mail about resuming testing of LEDstorm, could you resend it? I must have accidentally deleted it.)

On Sat, 18 Jan 2025 21:53:36 +0100, "Miro Kropáček" <mir...@gm...> wrote:

>> Oh dear. Any chance you could grab some older snapshot from
>> https://tho-otto.de/snapshots/freemint/bootable and observe how it behaves?
>> I can't say I have noticed something like this on my CT60(+SV, sometimes)
>> setup. What does xaaes log say? Does it crash in the same place?
>>
>> On Sat, 18 Jan 2025 at 21:43, Jo Even Skarstein via Freemint-discuss <
>> fre...@li...> wrote:
>>
>> > On my CT60/SV I have noticed that XaAES very often crashes while
>> > starting up if I do a warm reboot. I have attributed this to the
>> > idiosyncrasies of the CT60, and "fixed" the problem by always doing a
>> > coldboot. On the CT60, a coldboot means that all fast-RAM is zeroed.
>> >
>> > Now, a couple of days ago I fired up my Milan which hasn't really been
>> > used for ages, as I somehow managed to mess up my trusty old MiNT-setup
>> > and couldn't get current snapshots to boot properly. After dealing with
>> > some hardware issues I noticed the same trend as on the Falcon - XaAES
>> > would often crash at various points while starting up. The Milan does
>> > not clear fast-RAM after a coldboot, so I wrote a small program that
>> > does this and ran it before MiNT in the autofolder. And now XaAES has
>> > booted without any problems every time. Which suggests that either the
>> > kernel or XaAES depends on some memory/variables being zeroed.
>> >
>> > 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] XaAES often crashes during boot after a reboot

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

I'm not using MP and I'm not on the latest build either.

⁣Peter​

On 19 Jan 2025, 10:49, at 10:49, Jo Even Skarstein via Freemint-discuss <fre...@li...> wrote:
>IIRC you are not using memory protection, correct?
>
>
>Jo Even
>
>On Sat, 18 Jan 2025 20:51:41 +0000, Peter Slegg
><ps...@sc...> wrote:
>
>>> I've not noticed this issue with my Milan. Maybe it's a different
>motherboard version or due to the bootblock version ?
>>>
>>> ⁣Peter​
> 
>
>
>_______________________________________________
>Freemint-discuss mailing list
>Fre...@li...
>https://lists.sourceforge.net/lists/listinfo/freemint-discuss

Re: [Freemint-discuss] XaAES often crashes during boot after a reboot

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

IIRC you are not using memory protection, correct?


Jo Even

On Sat, 18 Jan 2025 20:51:41 +0000, Peter Slegg <ps...@sc...> wrote:

>> I've not noticed this issue with my Milan. Maybe it's a different motherboard version or due to the bootblock version ?
>>
>> ⁣Peter​
 

Re: [Freemint-discuss] XaAES often crashes during boot after a reboot

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

On 19/01/2025 at 09:50, Thorsten Otto via Freemint-discuss wrote:
>  > kernel or XaAES depends on some memory/variables being zeroed.
> 
> Uh, that would be really bad. Such things are hard to find.

It would be nice if some emulator (i.e. Hatari or ARAnyM) could help finding 
usages of uninitialized variables 😊

-- 
Vincent Rivière

Re: [Freemint-discuss] XaAES often crashes during boot after a reboot

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

Btw it reminds me of https://github.com/freemint/freemint/issues/109, that
I can reproduce all the time (implying that if Jo Even's issue hasn't been
always present, those are separate problems).

On Sun, 19 Jan 2025 at 09:51, Thorsten Otto via Freemint-discuss <
fre...@li...> wrote:

> On Samstag, 18. Januar 2025 21:42:57 CET Jo Even Skarstein via
> Freemint-discuss wrote:
>
> > Which suggests that either the
>
> > kernel or XaAES depends on some memory/variables being zeroed.
>
> Uh, that would be really bad. Such things are hard to find. One could try
> to hack kmalloc() and/or Malloc(), and explicitly set the memory to
> something else then zero, then try if such a kernel also crashes on other
> hardware.
>
>
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>


-- 
http://mikro.atari.org

Re: [Freemint-discuss] XaAES often crashes during boot after a reboot

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

On Samstag, 18. Januar 2025 21:42:57 CET Jo Even Skarstein via Freemint-
discuss wrote:
> Which suggests that either the
> kernel or XaAES depends on some memory/variables being zeroed.

Uh, that would be really bad. Such things are hard to find. One could try to 
hack kmalloc() and/or Malloc(), and explicitly set the memory to something 
else then zero, then try if such a kernel also crashes on other hardware.

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.
>
I took this opportunity to merge your new labels into my Ghidra archive. 
There are a lot of known variables, now.

I also used a nice Ghidra feature: Program Trees.
The main idea is to split the address space into functional blocks. So I 
created folders for BIOS, BDOS, etc.
See the red arrow on the top. It is the currently focused "View". It is 
possible to select any other item (including folders) and press the 'S' key 
to focus on that view. This has the effect to shrink the memory area 
displayed in the Listing window, so the slider is easier to use, to avoid 
being lost. To go out, select the root item tos100fr.img and press 'S' again.

Note that several Program Trees could be created, if different views of the 
whole address space was needed. I didn't find usage for that, so I simply 
used a single Program Tree.



-- 
Vincent Rivière

Re: [Freemint-discuss] XaAES often crashes during boot after a reboot

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

Oh dear. Any chance you could grab some older snapshot from
https://tho-otto.de/snapshots/freemint/bootable and observe how it behaves?
I can't say I have noticed something like this on my CT60(+SV, sometimes)
setup. What does xaaes log say? Does it crash in the same place?

On Sat, 18 Jan 2025 at 21:43, Jo Even Skarstein via Freemint-discuss <
fre...@li...> wrote:

> On my CT60/SV I have noticed that XaAES very often crashes while
> starting up if I do a warm reboot. I have attributed this to the
> idiosyncrasies of the CT60, and "fixed" the problem by always doing a
> coldboot. On the CT60, a coldboot means that all fast-RAM is zeroed.
>
> Now, a couple of days ago I fired up my Milan which hasn't really been
> used for ages, as I somehow managed to mess up my trusty old MiNT-setup
> and couldn't get current snapshots to boot properly. After dealing with
> some hardware issues I noticed the same trend as on the Falcon - XaAES
> would often crash at various points while starting up. The Milan does
> not clear fast-RAM after a coldboot, so I wrote a small program that
> does this and ran it before MiNT in the autofolder. And now XaAES has
> booted without any problems every time. Which suggests that either the
> kernel or XaAES depends on some memory/variables being zeroed.
>
> Jo Even
>
>
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>


-- 
http://mikro.atari.org

Re: [Freemint-discuss] XaAES often crashes during boot after a reboot

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

I've not noticed this issue with my Milan. Maybe it's a different motherboard version or due to the bootblock version ?

⁣Peter​

On 18 Jan 2025, 20:42, at 20:42, Jo Even Skarstein via Freemint-discuss <fre...@li...> wrote:
>On my CT60/SV I have noticed that XaAES very often crashes while
>starting up if I do a warm reboot. I have attributed this to the
>idiosyncrasies of the CT60, and "fixed" the problem by always doing a
>coldboot. On the CT60, a coldboot means that all fast-RAM is zeroed.
>
>Now, a couple of days ago I fired up my Milan which hasn't really been
>used for ages, as I somehow managed to mess up my trusty old MiNT-setup
>and couldn't get current snapshots to boot properly. After dealing with
>some hardware issues I noticed the same trend as on the Falcon - XaAES
>would often crash at various points while starting up. The Milan does
>not clear fast-RAM after a coldboot, so I wrote a small program that
>does this and ran it before MiNT in the autofolder. And now XaAES has
>booted without any problems every time. Which suggests that either the
>kernel or XaAES depends on some memory/variables being zeroed.
>
>Jo Even
>
>
>_______________________________________________
>Freemint-discuss mailing list
>Fre...@li...
>https://lists.sourceforge.net/lists/listinfo/freemint-discuss

[Freemint-discuss] XaAES often crashes during boot after a reboot

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

On my CT60/SV I have noticed that XaAES very often crashes while
starting up if I do a warm reboot. I have attributed this to the
idiosyncrasies of the CT60, and "fixed" the problem by always doing a
coldboot. On the CT60, a coldboot means that all fast-RAM is zeroed.

Now, a couple of days ago I fired up my Milan which hasn't really been
used for ages, as I somehow managed to mess up my trusty old MiNT-setup
and couldn't get current snapshots to boot properly. After dealing with
some hardware issues I noticed the same trend as on the Falcon - XaAES
would often crash at various points while starting up. The Milan does
not clear fast-RAM after a coldboot, so I wrote a small program that
does this and ran it before MiNT in the autofolder. And now XaAES has
booted without any problems every time. Which suggests that either the
kernel or XaAES depends on some memory/variables being zeroed.

Jo Even