freemint-discuss — The official FreeMiNT Mailing List

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

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
>