FreeMiNT STE and Hatari

[MegaSTEarian]

Are these builds (https://www.atari-forum.com/viewtopic.php?f=126&t=40651) supposed to run with Hatari? I'm having issues starting the STE one with either STE or MegaSTE configuration (68000/16MHz/68882/4 or 14MB RAM/TOS2.06)
Seems like an access issue to me
What can I do?

Screen Shot 2021-06-30 at 18.12.46.png

[czietz]

Did you use an emulated ACSI HD image? Regular FreeMiNT builds do not work with GEMDOS drive emulation.

[MegaSTEarian]

ah, no, I used GEMDOS. Will try with an image
A bit problematic to copy the data in a new image though

[czietz]

Fortunately, Hatari comes with the "atari-hd-image.sh" shell script precisely for such situations:
https://git.tuxfamily.org/hatari/hatari ... d-image.sh

Requires some "unixy" shell (Linux, WSL, Cygwin, ...), Python3 and GNU mtools.

[MegaSTEarian]

Will fire a Linux VM and give it a try, thanks

[OL]

Are these builds (https://www.atari-forum.com/viewtopic.php?f=126&t=40651) supposed to run with Hatari? I'm having issues starting the STE one with either STE or MegaSTE configuration (68000/16MHz/68882/4 or 14MB RAM/TOS2.06)
Seems like an access issue to me
What can I do?

Screen Shot 2021-06-30 at 18.12.46.png

Just use this archive, it do what you are expecting to do, directly on hostfs with Mint

http://myaes.lutece.net/telechargement/myhatari.zip

Olivier

[MegaSTEarian]

Are these builds (https://www.atari-forum.com/viewtopic.php?f=126&t=40651) supposed to run with Hatari? I'm having issues starting the STE one with either STE or MegaSTE configuration (68000/16MHz/68882/4 or 14MB RAM/TOS2.06)
Seems like an access issue to me
What can I do?

Screen Shot 2021-06-30 at 18.12.46.png

Just use this archive, it do what you are expecting to do, directly on hostfs with Mint

http://myaes.lutece.net/telechargement/myhatari.zip

Olivier

Works with STE/MEgaSTE config? I wanted to test a config that would allow me to use on my physical STE and MegaSTE

[MegaSTEarian]

Are these builds (https://www.atari-forum.com/viewtopic.php?f=126&t=40651) supposed to run with Hatari? I'm having issues starting the STE one with either STE or MegaSTE configuration (68000/16MHz/68882/4 or 14MB RAM/TOS2.06)
Seems like an access issue to me
What can I do?

Screen Shot 2021-06-30 at 18.12.46.png

Just use this archive, it do what you are expecting to do, directly on hostfs with Mint

http://myaes.lutece.net/telechargement/myhatari.zip

Olivier

Works with STE/MEgaSTE config? I wanted to test a config that would allow me to use on my physical STE and MegaSTE

Tested with Hatari works
How do I change the language in the Accessories loaded?


Now I need to test it on real hardware. A normal copy to the HD will suffice, right?

[OL]

Just use this archive, it do what you are expecting to do, directly on hostfs with Mint

http://myaes.lutece.net/telechargement/myhatari.zip

Olivier

Works with STE/MEgaSTE config? I wanted to test a config that would allow me to use on my physical STE and MegaSTE

Tested with Hatari works
How do I change the language in the Accessories loaded?


Now I need to test it on real hardware. A normal copy to the HD will suffice, right?

I not put accessory in this configuration, I think keyboard should be TOS keyboard without change, AES language is by default set to 0 so US but you can change it in /gemsys/myaes/myaes.cnf modifying "language" value but generally no software look at it.

This config should work from hard disk C (never tested), Mint is a bit special as it use TOSFS rather a loaded driver, so access drive is through TOS rom.
You can update as you want configuration and test as it is on hostf with Hatari.

Have fun

Olivier

[czietz]

Did you use an emulated ACSI HD image? Regular FreeMiNT builds do not work with GEMDOS drive emulation.

I've now contributed a fix to FreeMiNT to make them run under Hatari's GEMDOS HD emulation, starting with freemint-1-19-b44c975e-000-st_ste.zip (or any later snapshot, of course). You have to use a special MiNT kernel, though. To do so, after unpacking the zip archive, delete the "normal" kernel mint000.prg and rename minthat.prg (included in the snapshot zip archive, as well) to mint000.prg.

PS: This kernel is not required when running FreeMiNT from an emulated ACSI/IDE/SCSI hard disk image ‒ this was already possible before; minthat.prg is needed only for GEMDOS HD emulation!

[MegaSTEarian]

Did you use an emulated ACSI HD image? Regular FreeMiNT builds do not work with GEMDOS drive emulation.

I've now contributed a fix to FreeMiNT to make them run under Hatari's GEMDOS HD emulation, starting with freemint-1-19-b44c975e-000-st_ste.zip (or any later snapshot, of course). You have to use a special MiNT kernel, though. To do so, after unpacking the zip archive, delete the "normal" kernel mint000.prg and rename minthat.prg (included in the snapshot zip archive, as well) to mint000.prg.

PS: This kernel is not required when running FreeMiNT from an emulated ACSI/IDE/SCSI hard disk image ‒ this was already possible before; minthat.prg is needed only for GEMDOS HD emulation!

Cheers, this sounds really cool.

[Eero Tamminen]

I've now contributed a fix to FreeMiNT to make them run under Hatari's GEMDOS HD emulation, starting with freemint-1-19-b44c975e-000-st_ste.zip

I haven't tried it yet, but maybe you could tell a bit what that workaround / fix was?

(Is TOSFS still maintained, or did it it never get to upstream from the branch where Helmut was maintaining it?)

[czietz]

I've now contributed a fix to FreeMiNT to make them run under Hatari's GEMDOS HD emulation, starting with freemint-1-19-b44c975e-000-st_ste.zip

I haven't tried it yet, but maybe you could tell a bit what that workaround / fix was?

Even though when built with OLDTOSFS FreeMiNT uses GEMDOS functions (hooked by Hatari) to access the drive, it still checked for media change using the Mediach() BIOS function. With Hatari's GEMDOS emulation, there is not BIOS device for C:, so Mediach() returns an error ("device not found"). FreeMiNT would see that error and every access to a GEMDOS-emulated C: drive would fail. There even was already code in FreeMiNT to handle this situation, but it was only applied to drives D: and up, not to drive C:. This is now changed for kernels compiled with OLDTOSFS. See https://github.com/freemint/freemint/co ... 650c2852d4.

(Is TOSFS still maintained, or did it it never get to upstream from the branch where Helmut was maintaining it?)

That's a question best asked to the FreeMiNT maintainers.

[OL]

I've now contributed a fix to FreeMiNT to make them run under Hatari's GEMDOS HD emulation, starting with freemint-1-19-b44c975e-000-st_ste.zip

I haven't tried it yet, but maybe you could tell a bit what that workaround / fix was?

Even though when built with OLDTOSFS FreeMiNT uses GEMDOS functions (hooked by Hatari) to access the drive, it still checked for media change using the Mediach() BIOS function. With Hatari's GEMDOS emulation, there is not BIOS device for C:, so Mediach() returns an error ("device not found"). FreeMiNT would see that error and every access to a GEMDOS-emulated C: drive would fail. There even was already code in FreeMiNT to handle this situation, but it was only applied to drives D: and up, not to drive C:. This is now changed for kernels compiled with OLDTOSFS. See https://github.com/freemint/freemint/co ... 650c2852d4.

(Is TOSFS still maintained, or did it it never get to upstream from the branch where Helmut was maintaining it?)

That's a question best asked to the FreeMiNT maintainers.

Very cool, thanks

[OL]

I've now contributed a fix to FreeMiNT to make them run under Hatari's GEMDOS HD emulation, starting with freemint-1-19-b44c975e-000-st_ste.zip

I haven't tried it yet, but maybe you could tell a bit what that workaround / fix was?

Even though when built with OLDTOSFS FreeMiNT uses GEMDOS functions (hooked by Hatari) to access the drive, it still checked for media change using the Mediach() BIOS function. With Hatari's GEMDOS emulation, there is not BIOS device for C:, so Mediach() returns an error ("device not found"). FreeMiNT would see that error and every access to a GEMDOS-emulated C: drive would fail. There even was already code in FreeMiNT to handle this situation, but it was only applied to drives D: and up, not to drive C:. This is now changed for kernels compiled with OLDTOSFS. See https://github.com/freemint/freemint/co ... 650c2852d4.

(Is TOSFS still maintained, or did it it never get to upstream from the branch where Helmut was maintaining it?)

That's a question best asked to the FreeMiNT maintainers.

I confirm it work, but why this version with MyAES load so much the system ? A lost of around 30% compare to Helmut branch, it's huge
I try to see if with XaAES it is the same but for the moment I failed to start kernel

OL

[joska]

How do you measure the performance loss?

But yes, the current kernels are too slow for 8MHz systems, to such a degree that you'll loose keypresses when typing fast. I have put the 68000-version of VanillaMiNT on hold because of this.

[OL]

How do you measure the performance loss?

But yes, the current kernels are too slow for 8MHz systems, to such a degree that you'll loose keypresses when typing fast. I have put the 68000-version of VanillaMiNT on hold because of this.

Even if slow you should not lost keypressed!

I test the lost with Kronos, I take result of 68k perf (need launch opengl test (it take around 10 minutes!) a result of 1 is an ST at 8Mhz under TOS, it not use any system call and is not dependant from video, and with this Mint version I have under MyAES (I would like to see with XaAES ) under Helmut version I have 0.823 but under this version I have 0.498 ! I have verified under TOS 68000 8Mhz under Hatari give 1,008 so emulation is good.
Now I think have found a solution, looks like it is link to Kernel slice I put in mint.cnf: KERN_SLICES=16 then result is 0.883 !

If you do a test under Hatari with Kronos please not do disk test, Hatari gemdos hostfs emulation failed Kronos create in infinite loop file with size 0!

Olivier

Add note KERN_SLICES=16 is too high for teal time, I check a better adjustment result
KERN_SLICES=10 real time ok, result : 0.828 but AES is a bit slower than with Helmut version
KERN_SLICES=12 real time ok result : 0.851 and AES not far from Helmut version a bit slower (around 5%)