Hatari emulation problems, how to fix them ?

Started by Petari, 08-10-2022, 10:55:11

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Petari

It is now clear for me that there are few emulation problems with Hatari, and it stays for latest versions too. I described Fopen trap #1 call problem in other thread (about DOCs problems) .
But real problem is Hatari team attitude. And I guess that some error reports were caused by Hatari's not exactly faithful emulation of TOS. Plus by fact that those who wrote it did not mention details, so on what did ran it. Concrete problem is not working game saves under Hatari.
Now, it can be solved (and is actually) by some workaround. But there are other emulation problems too.
And I don't expect that Hatari team will change their approach.
Well, since it is open source, changes can be done by anyone experienced in C, Atari ST TOS programming.
Myself made some changes in Steem 3.2 (after they published sources). But since it I really did not anything in C. Pretty much rusted now with. And I guess that Hatari source is for some total different C compiler. 
Best would be if someone go in doing really TOS compatible Hatari emulator. So, GEMDOS hard disk emulation faithful to it as much possible. And there are some other errors - like LFN conversion to 8.3 filenames - that can be done better.  And what I really would like to see:  some much better settings solution. For instance Steem 3.2 has separated menu layouts for Linux and for Windows . So, in Win version to have some usual Windows menus, dialogs. That will make it more popular too, I'm sure.  And last but not least:  please, not EmuTOS as default OS ! :-) It is even worse case of not being TOS compatible. We want to run good old Atari SW in 99% time.  If I want new SW, I don't need Atari, it's emulators. Except supporting SW, of course :-)
  •  

Petari

While I worked on updating hard disk image with games (size 3.5 GB) - and sadly, only Hatari is good for that - or using USB reader with Windows , Total Commander for file copies (it can be set to not use Windows LFN).
Steem and Steem SSE have size limits (1 and 2 GB) .
So, I used latest Hatari 2.4.1 Windows 64 . And experienced bugs - yes, they are bugs in exact meaning of that term:
If there are in DIR for GEMDOS emulation files with names like:  GAMELIST.TXT,  GAMELISTOKT14.TXT, GAMELISTSEP24.TXT  it all will appear under emulated Atari as just GAMELIST.TXT - 3 times .  Then I copied wanted file by looking it's length - and surprise - Hatari copied other file ! So, only reliable way is to avoid LFN.  Steem 3.2 (from like 2006) does it much better - it shows LFN names like GAME~001.TXT, GAME~002.TXT ...  As Total Commander does when is set to not use LFN .
 And one more:  when I finished with all updates of hard disk image went on saving that state - to avoid getting in settings when start Hatari again, to be there at next start. And when clicked on Restore - Memory state , got message that save is incompatible with this Hatari version - while made it with it. And some bad characters lower, like *`.<   .
Well, all this mean for me that they don't care really for compatibility with original TOS versions. What is visible by pushing EmuTOS wherever can - it is set as default in Hatari. Sure, when I will want to use some better OS than TOS maybe I will use not only better OS, but better HW too - like 5000x faster PC, with like 3000x more RAM .
  •