freemint-discuss — The official FreeMiNT Mailing List

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

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

On 07/01/2025 at 21:52, Eero Tamminen wrote:
> Btw. Hatari Git version will automatically load symbols for TOS image, like 
> it already did for programs started from GEMDOS HD.

Nice.

> Only thing needed for that is symbols being in <image>.sym file in same dir 
> as corresponding TOS <image>.img.
> 
> (This already works fine for EmuTOS releases providing the corresponding 
> *.sym files.)

Good!

> => Could those TOS address & symbol names be provided as Hatari (= nm 
> format) symbol files, along with checksums for matching original TOS images?

Yes!
This was one of the goals of such disassembly. To help people when 
debugging. And getting automatically the symbol names in Hatari is 
definitely convenient.

I think that such labels could easily be exported with some Ghidra scripts. 
And for TOS 1.04+, Thorsten already has the address/label pairs.

So I think that your proposition is completely good. Hatari could be 
distributed with the symbols (as external files) for all know TOS versions. 
And when detecting a know TOS version, load those symbols automatically. 
This couldn't be simpler for the users.

-- 
Vincent Rivière

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

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

On 04/01/2025 at 11:55, Thorsten Otto via Freemint-discuss wrote:
> While trying to identify some more functions from aes/desktop, i also 
> noticed that there are some strange differences if the location of 
> functions, for example gem_main:
> 
> 
> - in fr: gem_main fd9362
> 
> - in de: gem_main fd902a
> 
> - in us: gem_main fd9340

Oh.

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

Possible.

> Also, it seems that TOS 1.00 was more close to the original DRI sources. Eg. 
> the first thing in gem_main is a function call, which seems to be 
> "ini_dlong" from the DRI sources. In 1.04, that function was "inlined" into 
> gem_main.

Indeed, I tried to understand gem_main(), but it didn't match the 1.04 
source. You found the reason.

> PS: even worse, addresses of some variables seem to be different:

Oh. This is interesting to know, in case someone wants to do something with 
those private variables. Starting from debugging.

> So maybe it would have been better to start with the US version?

Certainly. But as I started with the French version, and I already had done 
some amount of work, then I continued.

Note that Ghidra supports applying the disassembly markup (labels, etc...) 
to newer or older version of the target software. As I understood, it should 
be able automatically find code similarities. However, I haven't tested that 
feature. Without relocation table, I'm not sure if it could do that with 
different TOS ROMs. That feature is called "version tracking", and it can be 
enabled from the Ghidra Project Manager window (NOT the CodeBrowser).

-- 
Vincent Rivière

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

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

Hi,

On 7.1.2025 20.00, Thorsten Otto via Freemint-discuss wrote:
> That was a great understatement. I recently took a closer look, and realized
> that you managed to enter already 1700!! symbols. Even with the 1.04 source
> available, that is simply awesome. You even managed to find some aes variables
> although the functions cannot correctly be disassembled by ghidra (because of
> the LineF opcodes). How long did it take to get that far?

Btw. Hatari Git version will automatically load symbols for TOS image, 
like it already did for programs started from GEMDOS HD.

Only thing needed for that is symbols being in <image>.sym file in same 
dir as corresponding TOS <image>.img.

(This already works fine for EmuTOS releases providing the corresponding 
*.sym files.)


=> Could those TOS address & symbol names be provided as Hatari (= nm 
format) symbol files, along with checksums for matching original TOS images?


	- Eero

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

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

On Freitag, 3. Januar 2025 07:14:05 CET Thorsten Otto via Freemint-discuss 
wrote:
> Nice work!

That was a great understatement. I recently took a closer look, and realized 
that you managed to enter already 1700!! symbols. Even with the 1.04 source 
available, that is simply awesome. You even managed to find some aes variables 
although the functions cannot correctly be disassembled by ghidra (because of 
the LineF opcodes). How long did it take to get that far?

Anyway, i've spend some time trying to identify the aes functions. About 
halfway through, (most of aes is done, but most of desktop is still missing). 
I've pushed my current work to a new branch of the sources: https://
github.com/th-otto/tos1x/tree/TOS_100

Most of it is just done on a large assembler listing (not compilable, just 
used as a reference).

I've also changed already some of the sources where i saw differences, but 
without being able to verify them yet. There are also extracted resource 
files. Handling of the resource file is a bit strange: the format dialog is in 
a seperate resource, and there are 2 additional blocks of data for which i 
have idea yet what they are good for (you already noticed that too, given that 
you already assigned lables to them). The routine that copies them to ram 
(ram_rom) also does some strange juggling with the aes global array.


BTW, it seems there only have been official releases for us,de and fr. All 
other images i found on the net seem to be just patched versions of the german 
version.

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

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

> for us/uk: 11/20/1985
> for de: 02/06/1986
> for fr: 04/24/1986

While trying to identify some more functions from aes/desktop, i also noticed 
that there are some strange differences if the location of functions, for 
example gem_main:

- in fr: gem_main fd9362
- in de: gem_main fd902a
- in us: gem_main fd9340

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?


Also, it seems that TOS 1.00 was more close to the original DRI sources. Eg. 
the first thing in gem_main is a function call, which seems to be "ini_dlong" 
from the DRI sources. In 1.04, that function was "inlined" into gem_main.

PS: even worse, addresses of some variables seem to be different:

fr:
gem_main:
[00fd9362] 4e56 fff8                 link       a6,#-8
[00fd9366] 48e7 0304                 movem.l    d6-d7/a5,-(a7)
[00fd936a] 2a7c 0000 73e0            movea.l    #$000073E0,a5
[00fd9370] f7c8                      dc.w       $F7C8 ; ini_dlongs
[00fd9372] f7cc                      dc.w       $F7CC ; hcli
[00fd9374] f7d0                      dc.w       $F7D0 ; takecpm
[00fd9376] 4279 0000 9f1c            clr.w      $00009F1C
[00fd937c] 4279 0000 6ed2            clr.w      $00006ED2
[00fd9382] 42b9 0000 6e98            clr.l      $00006E98

de:
gem_main:
[00fd902a] 4e56 fff8                 link       a6,#-8
[00fd902e] 48e7 0304                 movem.l    d6-d7/a5,-(a7)
[00fd9032] 2a7c 0000 73e4            movea.l    #$000073E4,a5
[00fd9038] f7c8                      dc.w       $F7C8 ; ini_dlongs
[00fd903a] f7cc                      dc.w       $F7CC ; hcli
[00fd903c] f7d0                      dc.w       $F7D0 ; takecpm
[00fd903e] 4279 0000 9f20            clr.w      $00009F20
[00fd9044] 4279 0000 6ed6            clr.w      $00006ED6
[00fd904a] 42b9 0000 6e9c            clr.l      $00006E9C

So maybe it would have been better to start with the US version?

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

[Jean-François L. <jfl...@po...>]

On Friday 3 January 2025 10:31:19 Central European Standard Time Miro Kropáček 
wrote:
> On Fri, 3 Jan 2025 at 03:30, Vincent Rivière <vin...@fr...>
> wrote:
> > Here is my present:
> > A (partial) disassembly of TOS 1.00 using Ghidra
> > Everything is here, including explanations:
> > https://github.com/disastos/tos100fr
> 
> Btw not sure if it's just me but if I click on any of the pictures in
> README.md, I get some weird one-page http error and not a zoomed image.

No such problem here with Firefox.

Cheers,
JFL
-- 
Jean-François Lemaire

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

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

On Fri, 3 Jan 2025 at 03:30, Vincent Rivière <vin...@fr...>
wrote:

> Here is my present:
> A (partial) disassembly of TOS 1.00 using Ghidra
>
> Everything is here, including explanations:
> https://github.com/disastos/tos100fr

Very nice, interesting read.

TOS 4.04 most likely doesn't need this treatment as its leaked source code
is pretty much complete.

Btw not sure if it's just me but if I click on any of the pictures in
README.md, I get some weird one-page http error and not a zoomed image.

-- 
http://mikro.atari.org

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

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

Happy New Year everyone. 

I had a quick look at Ghidra a few months back and last night I was using Sweet16 midi sequencer to try to get my head around Ghidra.

I tried Reko decompiler a few years ago but didn't make any progress.

⁣Peter​

On 3 Jan 2025, 02:29, at 02:29, "Vincent Rivière" <vin...@fr...> wrote:
>Hi, and happy new year to all of you.
>
>Here is my present:
>A (partial) disassembly of TOS 1.00 using Ghidra
>
>Everything is here, including explanations:
>https://github.com/disastos/tos100fr
>
>Here is some background.
>
>Recently, someone told me about a strange GEMDOS bug happening only on 
>TOS 1.00. I quickly managed to reproduce it with a program of mine. As 
>it was simple enough to be bug-free, the problem was obviously inside 
>TOS 1.00. I'm used to trace the ROM with MonST2, no problem for that. 
>But as the GEMDOS is written in C, and uses rather complex structures, 
>it quickly becomes hard to follow. Then I looked at Thorsten's 
>(excellent) reconstructed sources. It helped a lot, but unfortunately 
>the bug was in memory management. And that part of the code changed 
>between TOS 1.00 (my target) and TOS 1.04 (Thorsten's sources). So it 
>wasn't enough. So I decided to disassemble the TOS 1.00 using Ghidra. 
>Not entirely, of course, but at least the offending GEMDOS functions. I
>
>finally found the bug, then a workaround, and everyone was happy. I 
>still need to clarify a few things, then I will tell more. Anyway, 
>that's another topic.
>
>During that investigation, I practiced Ghidra a lot. And definitely, 
>that's a really powerful tool. And Free. Not completely polished, but 
>definitely very usable, as soon as you have understood the basics. My 
>conclusion is that Ghidra is *the* tool to learn for anyone interested 
>in reverse engineering (just like Git for source control).
>
>Ghidra is a bit bloated (not so much, for nowadays standards). It 
>requires a Java JDK as runtime, then it can be downloaded as a simple 
>zip archive. And run from a .bat file. After an austere project 
>management window, the main tool opens. It is a nice workspace-like 
>window, see the screenshot on GitHub.
>
>Basically, you start creating a new project by specifying the 68000
>CPU. 
>Import the ROM binary (I used tos100fr.img). Then it is automatically 
>analyzed, and disassembled to both assembly language and C.
>Be sure that the disassembly is as good as possible. But there are no 
>miracles. You do get labels and cross-references, but the names are 
>meaningless. Fortunately, just press L to rename a label and it will 
>change everywhere. Same in the C decompilation, you can rename 
>functions, parameters, variables, etc. For code using structs (such as 
>basepage), it's quite unreadable. But as soon as you define the actual 
>struct and correctly specify the type of the variables, the 
>decompilation becomes completely usable, and you're able to understand 
>the algorithms.
>
>And this works really well, thanks to the hard work of Thorsten on the 
>reconstruction of TOS 1.4 sources. Even if there are some important 
>differences, the major code base is similar, when not identical. Of 
>course, the addresses of the internal functions are different. But
>after 
>renaming some labels, it's just like a puzzle: highly addictive. With 
>more labels, you are able to identify more functions, and so on. So 
>after my initial bugfix, I continued to add labels. And finally, I
>found 
>most major functions of BIOS/XBIOS/BDOS/VDI. Bad luck with AES/Desktop,
>
>because due to the infamous Line-F obfuscation (to reduce code size), 
>Ghidra is lost. Maybe something could be done with a proper script. 
>Again another topic.
>
>Anyway, as I disassembled most of the TOS 1.00, and added a lot of 
>labels and structs from Thorsten's sources, I considered it was worth
>to 
>share this work. It can help a lot to find bugs, and understand things 
>from the origins. As that 40-years old TOS has been considered as 
>abandonware for a long time, it shouldn't be a problem to put that 
>disassembly and related documentation on GitHub.
>
>I don't plan to work much more on that project. Or maybe, occasionally.
>
>But other people may have additional needs, to disassemble other parts,
>
>etc. So this needs to be a collaborative project.
>
>This is why I've created a new GitHub Organization to hold that
>project. 
>I named it DisasTOS, meaning "Disassembly of TOS, and more". Currently,
>
>it only holds this single TOS 1.0 project. But this could work equally 
>well for TOS 4.04 for example. Or even some user programs such as 
>FOLDRXXX.PRG for example. My idea is to easily give write access to the
>
>DisasTOS organization, so many developers can contribute. Between 
>disassembly and documentation, there is much to do.
>
>So if people are interested, here is a new toy. Feel free to
>contribute. 
>Really, it is worth to learn Ghidra. I won't do much more myself on
>that 
>topic.
>
>Just one more thing:
>Unfortunately, Ghidra projects can't be easily shared. They actually 
>can, but that requires a Ghidra Server. And we don't have one. If this 
>project becomes popular, we could consider to setup a Guidra Server 
>somewhere. It just needs to be able to run Java, and a Ghidra instance.
>
>But for now, let's start like this. What I have set up is really not 
>convenient, but that's a starting point. Basically, Ghidra projects can
>
>be archived into a GAR archive. I've put such archive in the GitHub 
>project, so any developer must unpack/work/repack/push the archive. As 
>it is a binary file, it doesn't support multiple concurrent 
>modifications. So a only single user can work on the project as the
>same 
>time. That's a severe restriction. The only solution seems to be usage 
>of a Ghidra Server. We will see if we finally need that.
>
>Enjoy!
>
>-- 
>Vincent Rivière
>
>
>_______________________________________________
>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...>]

Ok, installing a newer version of ghidra (and also a newer version of JDK) 
worked.

I "hacked" the launch.sh script (in <ghidra>/support) a bit to get it working. 
At the top, i added:

export JAVA_HOME=$HOME/ghidra_11/jdk-21.0.5+11
export PATH=$JAVA_HOME/bin:$PATH

where $HOME/ghidra_11 is the directory where i installed it. Maybe you want to 
do the same when working on linux, or put that statements in some custom 
script.

What i didn't know until know: even the tos header with the date seems to be 
different for different tos languages.

for us/uk: 11/20/1985
for de: 02/06/1986
for fr: 04/24/1986

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

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

On Freitag, 3. Januar 2025 03:29:59 CET Vincent Rivière wrote:
> Here is my present:
> A (partial) disassembly of TOS 1.00 using Ghidra

Nice work!

Unfortunately, ghidra has another quirk: i'm currently not able to open the 
archive, because it was "created using an unknown version of ghidra" (i'm 
using a somewhat older version, 9.1.2). I have to check whether i can install 
a newer version of ghidra alongside, and try again.

>Bad luck with AES/Desktop, 
>because due to the infamous Line-F obfuscation (to reduce code size), 

Yes, that is certainly a problem. Note that the Line-F dispatcher is used for 
2 purposes:
- replace function calls by a single trap instruction. The file https://
github.com/th-otto/tos1x/blob/master/bin/linux/lineftab.txt currently defines 
the mapping of these for TOS 1.04. If they are different in TOS 1.0, that can 
just be adjusted. Then you'll have to find a way to tell ghidra to understand 
those calls. Should be doable by a script (but maybe not that easy, you have 
to dig deep into ghidra documentation)
- replace the function epilogue (movem; unlk; rts) I would expect that TOS 1.0 
uses the same logic here as TOS 1.4. But for ghidra, this is still a problem, 
as it probably does not find the end of the function.

Ghidra has some other quirks (most of them you already mention in your 
readme). One of them being, that it often tends to generate "equivalent" C-
code, but not neccessarily what was originally written. Eg. It often changes 
code like "x > 0" to "x >= 1" or similar, and also reorders the bodies of if/
else. 

But of course, ghidra is only an intermediate tool to easier spot the 
differences. Ultimate goal would be to do the same as for tos 1.4, and get 
sources that can be compiled to binary identical images. A long way to go, 
though.


>Or even some user programs such as FOLDRXXX.PRG for example.

That is already available in the other repo: https://github.com/th-otto/tos3x/
blob/master/system/foldr100.S

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

[Roger B. <an...@xp...>]

Hi Vincent,
On 3 Jan 2025 at 3:29, Vincent Rivière wrote:

> Hi, and happy new year to all of you.
> 
> Here is my present:
> A (partial) disassembly of TOS 1.00 using Ghidra
> 
> Everything is here, including explanations:
> https://github.com/disastos/tos100fr
> 
Nice!

Happy New Year!
Roger

[Freemint-discuss] Disassembly of TOS 1.00 with Ghidra

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

Hi, and happy new year to all of you.

Here is my present:
A (partial) disassembly of TOS 1.00 using Ghidra

Everything is here, including explanations:
https://github.com/disastos/tos100fr

Here is some background.

Recently, someone told me about a strange GEMDOS bug happening only on 
TOS 1.00. I quickly managed to reproduce it with a program of mine. As 
it was simple enough to be bug-free, the problem was obviously inside 
TOS 1.00. I'm used to trace the ROM with MonST2, no problem for that. 
But as the GEMDOS is written in C, and uses rather complex structures, 
it quickly becomes hard to follow. Then I looked at Thorsten's 
(excellent) reconstructed sources. It helped a lot, but unfortunately 
the bug was in memory management. And that part of the code changed 
between TOS 1.00 (my target) and TOS 1.04 (Thorsten's sources). So it 
wasn't enough. So I decided to disassemble the TOS 1.00 using Ghidra. 
Not entirely, of course, but at least the offending GEMDOS functions. I 
finally found the bug, then a workaround, and everyone was happy. I 
still need to clarify a few things, then I will tell more. Anyway, 
that's another topic.

During that investigation, I practiced Ghidra a lot. And definitely, 
that's a really powerful tool. And Free. Not completely polished, but 
definitely very usable, as soon as you have understood the basics. My 
conclusion is that Ghidra is *the* tool to learn for anyone interested 
in reverse engineering (just like Git for source control).

Ghidra is a bit bloated (not so much, for nowadays standards). It 
requires a Java JDK as runtime, then it can be downloaded as a simple 
zip archive. And run from a .bat file. After an austere project 
management window, the main tool opens. It is a nice workspace-like 
window, see the screenshot on GitHub.

Basically, you start creating a new project by specifying the 68000 CPU. 
Import the ROM binary (I used tos100fr.img). Then it is automatically 
analyzed, and disassembled to both assembly language and C.
Be sure that the disassembly is as good as possible. But there are no 
miracles. You do get labels and cross-references, but the names are 
meaningless. Fortunately, just press L to rename a label and it will 
change everywhere. Same in the C decompilation, you can rename 
functions, parameters, variables, etc. For code using structs (such as 
basepage), it's quite unreadable. But as soon as you define the actual 
struct and correctly specify the type of the variables, the 
decompilation becomes completely usable, and you're able to understand 
the algorithms.

And this works really well, thanks to the hard work of Thorsten on the 
reconstruction of TOS 1.4 sources. Even if there are some important 
differences, the major code base is similar, when not identical. Of 
course, the addresses of the internal functions are different. But after 
renaming some labels, it's just like a puzzle: highly addictive. With 
more labels, you are able to identify more functions, and so on. So 
after my initial bugfix, I continued to add labels. And finally, I found 
most major functions of BIOS/XBIOS/BDOS/VDI. Bad luck with AES/Desktop, 
because due to the infamous Line-F obfuscation (to reduce code size), 
Ghidra is lost. Maybe something could be done with a proper script. 
Again another topic.

Anyway, as I disassembled most of the TOS 1.00, and added a lot of 
labels and structs from Thorsten's sources, I considered it was worth to 
share this work. It can help a lot to find bugs, and understand things 
from the origins. As that 40-years old TOS has been considered as 
abandonware for a long time, it shouldn't be a problem to put that 
disassembly and related documentation on GitHub.

I don't plan to work much more on that project. Or maybe, occasionally. 
But other people may have additional needs, to disassemble other parts, 
etc. So this needs to be a collaborative project.

This is why I've created a new GitHub Organization to hold that project. 
I named it DisasTOS, meaning "Disassembly of TOS, and more". Currently, 
it only holds this single TOS 1.0 project. But this could work equally 
well for TOS 4.04 for example. Or even some user programs such as 
FOLDRXXX.PRG for example. My idea is to easily give write access to the 
DisasTOS organization, so many developers can contribute. Between 
disassembly and documentation, there is much to do.

So if people are interested, here is a new toy. Feel free to contribute. 
Really, it is worth to learn Ghidra. I won't do much more myself on that 
topic.

Just one more thing:
Unfortunately, Ghidra projects can't be easily shared. They actually 
can, but that requires a Ghidra Server. And we don't have one. If this 
project becomes popular, we could consider to setup a Guidra Server 
somewhere. It just needs to be able to run Java, and a Ghidra instance. 
But for now, let's start like this. What I have set up is really not 
convenient, but that's a starting point. Basically, Ghidra projects can 
be archived into a GAR archive. I've put such archive in the GitHub 
project, so any developer must unpack/work/repack/push the archive. As 
it is a binary file, it doesn't support multiple concurrent 
modifications. So a only single user can work on the project as the same 
time. That's a severe restriction. The only solution seems to be usage 
of a Ghidra Server. We will see if we finally need that.

Enjoy!

-- 
Vincent Rivière

Re: [Freemint-discuss] Gluestik

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

On Wed, 18 Dec 2024 at 14:01, Thorsten Otto via Freemint-discuss <
fre...@li...> wrote:

> In the link command, just as before? ;)
>
Ah, right. I completely overlooked the $(LD) line.

Thanks.

-- 
http://mikro.atari.org

Re: [Freemint-discuss] Gluestik

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

On Mittwoch, 18. Dezember 2024 00:03:09 CET Miro Kropáček wrote:
> I wouldn't know where to put this in the new Makefile structure.

In the link command, just as before? ;)

Done now.

Re: [Freemint-discuss] Gluestik

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

On Mon, 16 Dec 2024 at 00:23, Jo Even Skarstein via Freemint-discuss <
fre...@li...> wrote:

>
> The build before this commit works:
>
>
> https://github.com/freemint/freemint/commit/81fb50786aa0aaf939733c0e5005e648a12de84f

And for a good reason: this commit removes Makefile.objs which also
contained an important detail: linking with "-Wl,--mprg-flags,0x17". Except
gluestik this also applies to mgw.

Thorsten, can you fix this? I wouldn't know where to put this in the new
Makefile structure.

-- 
http://mikro.atari.org

Re: [Freemint-discuss] SpareMiNT top crashes on recent kernels

[Mark D. <mdu...@at...>]

I actually ported a much newer procps-ng and ported all those apps...

But yours is nicer

On 12/15/24 2:59 PM, Jo Even Skarstein via Freemint-discuss wrote:
> On Fri, 2023-12-08 at 21:41 +0100, Jo Even Skarstein wrote:
>> The old SpareMiNT top crashes with a bus error on recent kernels.
>>
>> https://freemint.github.io/sparemint/sparemint/html/packages/pstop.html
> I wrote my own simple "top", it might be of use for others:
>
> https://atari.joska.no/jtop/
>
> Jo Even
>
>
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss

Re: [Freemint-discuss] Gluestik

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

The build before this commit works:

https://github.com/freemint/freemint/commit/81fb50786aa0aaf939733c0e5005e648a12de84f

Jo Even

On Sun, 15 Dec 2024 23:12:01 +0100, "Miro Kropáček" <mir...@gm...> wrote:

>> Hi Jo,
>>
>> I'm currently away from my Atari gear but I remember having the same
>> experience -- a couple of months ago I wiped my old FreeMiNT setup and to
>> my surprise, I haven't been able to get a stable networking setup since
>> then.
>>
>> Not that I tried very hard. But I did try changing to the very same litchi
>> version I had been using for so long and imagine my surprise when it didn't
>> work either.
>>
>> So I'm wondering whether there was something changed in gluestik.prg or in
>> some network code in the last few months.
>>
>> I'll try to take a closer look on Monday but feel free to bisect the
>> failing build from the snapshots download in the meantime.
>>
>> Dňa ne 15. 12. 2024, 22:44 Jo Even Skarstein via Freemint-discuss <
>> fre...@li...> napísal(a):
>>
>> > I've recently made a small game
>> > (https://www.atari-forum.com/viewtopic.php?t=44483) that use the STiK
>> > API. The rather old gluestik.prg I had appeared to be a debug version,
>> > so I tried gluestik from the latest snapshot. Unfortunately there seems
>> > to be a problem with this, any application that tries to initialise the
>> > STiK API crashes immediately. In addition to my own game I have tried
>> > Litchi and Troll, which both use the STiK resolver. They all crash with
>> > a bus error.
>> >
>> > Jo Even
>> >
>> >
>> > _______________________________________________
>> > Freemint-discuss mailing list
>> > Fre...@li...
>> > https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>> >

Re: [Freemint-discuss] Gluestik

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

Hi Jo,

I'm currently away from my Atari gear but I remember having the same
experience -- a couple of months ago I wiped my old FreeMiNT setup and to
my surprise, I haven't been able to get a stable networking setup since
then.

Not that I tried very hard. But I did try changing to the very same litchi
version I had been using for so long and imagine my surprise when it didn't
work either.

So I'm wondering whether there was something changed in gluestik.prg or in
some network code in the last few months.

I'll try to take a closer look on Monday but feel free to bisect the
failing build from the snapshots download in the meantime.

Dňa ne 15. 12. 2024, 22:44 Jo Even Skarstein via Freemint-discuss <
fre...@li...> napísal(a):

> I've recently made a small game
> (https://www.atari-forum.com/viewtopic.php?t=44483) that use the STiK
> API. The rather old gluestik.prg I had appeared to be a debug version,
> so I tried gluestik from the latest snapshot. Unfortunately there seems
> to be a problem with this, any application that tries to initialise the
> STiK API crashes immediately. In addition to my own game I have tried
> Litchi and Troll, which both use the STiK resolver. They all crash with
> a bus error.
>
> Jo Even
>
>
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>

[Freemint-discuss] Gluestik

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

I've recently made a small game
(https://www.atari-forum.com/viewtopic.php?t=44483) that use the STiK
API. The rather old gluestik.prg I had appeared to be a debug version,
so I tried gluestik from the latest snapshot. Unfortunately there seems
to be a problem with this, any application that tries to initialise the
STiK API crashes immediately. In addition to my own game I have tried
Litchi and Troll, which both use the STiK resolver. They all crash with
a bus error.

Jo Even

Re: [Freemint-discuss] SpareMiNT top crashes on recent kernels

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

On Fri, 2023-12-08 at 21:41 +0100, Jo Even Skarstein wrote:
> The old SpareMiNT top crashes with a bus error on recent kernels.
> 
> https://freemint.github.io/sparemint/sparemint/html/packages/pstop.html

I wrote my own simple "top", it might be of use for others:

https://atari.joska.no/jtop/

Jo Even

Re: [Freemint-discuss] ELF

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

There is a native freepascal compiler as well.

https://build.alb42.de/fpcbin/

⁣Peter​

On 5 Dec 2024, 05:53, at 05:53, Thorsten Otto via Freemint-discuss <fre...@li...> wrote:
>On Dienstag, 3. Dezember 2024 14:28:01 CET Peter Slegg via
>Freemint-discuss 
>wrote:
>> I've been playing with freepascal. Could it support the same format ?
>
>Freepascal only uses the assembler & linker from the gcc toolchain, so
>there 
>won't be much benefit in using the elf toolchains. And normally, it
>uses VASM 
>for this purpose, which already supports elf.
>
>I also wonder why you need a native gcc for this (although that is
>available). 
>AFAIK freepascal is only available as cross-compiler.
>
>
>
>------------------------------------------------------------------------
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Freemint-discuss mailing list
>Fre...@li...
>https://lists.sourceforge.net/lists/listinfo/freemint-discuss

Re: [Freemint-discuss] ELF

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

On Dienstag, 3. Dezember 2024 14:28:01 CET Peter Slegg via Freemint-discuss 
wrote:
> I've been playing with freepascal. Could it support the same format ?

Freepascal only uses the assembler & linker from the gcc toolchain, so there 
won't be much benefit in using the elf toolchains. And normally, it uses VASM 
for this purpose, which already supports elf.

I also wonder why you need a native gcc for this (although that is available). 
AFAIK freepascal is only available as cross-compiler.

Re: [Freemint-discuss] ELF

[WongCK <won...@ya...>]

 Yes, I have been using native  ELF gcc for my programs.All are working as advertised.
    On Tuesday, 3 December 2024 at 09:28:31 pm SGT, Peter Slegg via Freemint-discuss <fre...@li...> wrote:  
 
 
Is there a native gcc compiler that produces the (mint) elf binaries ?

Other native tools like gdb ?

I've been playing with freepascal. Could it support the same format ?



PeterOn 3 Dec 2024, at 12:59, "Miro Kropáček" <mir...@gm...> wrote:
On Tue, 3 Dec 2024 at 13:15, Peter Slegg via Freemint-discuss <fre...@li...> wrote:
With Christmas just around the corner, I thought it time to ask how is Elf coming along :-)

Anything specific you have in mind? I've been using the ELF compiler for nearly a year, (native and finally working) debugger included.
-- 
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
  

[Freemint-discuss] Fdisk

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

Hi,

Over the weekend I had some hdd problems, thankfully fixed now, but I had a look for fdisk and see version 1.0 was ported back in 2000.

It runs but expects the drive to be in /dev so it cannot do anything.

Is there any workaround for this ?

⁣Peter​

Re: [Freemint-discuss] ELF

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

On Tue, 3 Dec 2024 at 14:28, Peter Slegg via Freemint-discuss <
fre...@li...> wrote:

> Is there a native gcc compiler that produces the (mint) elf binaries ?
>
Not an official release (I have to do it one day...) but Thorsten already
offers such binaries: https://tho-otto.de/crossmint.php.

Other native tools like gdb ?
>
Sure:
http://vincent.riviere.free.fr/soft/m68k-atari-mintelf/archives/mint/gdb.


> I've been playing with freepascal. Could it support the same format ?
>
I guess you will have to ask FreePascal authors.

-- 
http://mikro.atari.org