Preview version of Hatari 1.8 with STX support

[npomarede]

Hello

I committed my changes to the dev source tree to include the Pasti support for Hatari.
This is the first open source version of an STX decoder in an emulator, work based on docs collected by Dr CoolZic, ppetari and sarnau, as well as from my own disassembling of pasti.prg.
This means STX support for Linux, OSX and even Android

This is no official pasti from its author Ijor, but hopefully it should work with all images (I tested 100-200 of them) and in case some STX files are not working, it should be fixable

You can compile the sources for linux / osx or get some prebuilt windows binaries here http://antarctica.no/~hatari/latest/windows/ (use "hatari.exe" and you will also need to put a tos.img file in the downloaded directory).

Please test and report any possible problem before Hatari 1.8 release, including TOS version and RAM config, also check the game works under Steem too (for many STX games, it's recommended to use TOS 1.02 or 1.04)

Nicolas

[jok]

Hooray! Thanks, this is really really good news for us non-Windows users, because handling with a Window VM just to get an ST emulator running for Pasti/IPF support was quite of weird.

I am testing some homemade Pastis the next days, if there are any problems, I will report.

[alexh]

Very nice work. Looking forward to trying it.

Presumably no write support? So the Dragonflight PaSTi images are still (practically) unusable?

You may remember that they are used as install disks and are used to make game disks from blanks.

The game disks have a weaker form of copy protection (obviously one the ST can write) but one not supported by any emulator using .ST files for the blanks.

viewtopic.php?f=47&t=7054
http://atari-forum.com/viewtopic.php?f=94&t=26557

[npomarede]

Very nice work. Looking forward to trying it.
Presumably no write support? So the Dragonflight PaSTi images are still (practically) unusable?

No, no write support at the moment, will see later

[squall]

This is awesome work Nicolas!

I just did a quick merge from the latest source into the Android port and tried out a small stx (moon patrol) and it works great!
I'll do some more testing on the weekend, but it's looking good so far.

Thanks to all the people who worked on getting stx support working.

[simonsunnyboy]

Awesome work!

Games I booted and played for a few minutes sofar from my collection:
- Thundercats
- Axel's Magic Hammer
- Joe Blade (downloaded somewhere, others are imaged from my originals)
- Rick Dangerous (level select version)
- Lethal Xcess (screen flickers, not a PASTI issue as discussed on the mailing list)

I will check more from my collection in the upcoming days. Ofcourse i did not play those games through all paces to the end, just boot and start one or two games...

I used STE 4MB TOS2.06 configuration sofar.

[squall]

Not directly related to Pasti support, but the save states don't seem to be restoring the fdc states correctly.

It works the first time you do a restore, but if you try restoring the same save state again without restarting Hatari, the disc fails to load.
I tried this on the Win32 link above, and with ST, TOS 1.02 and various menu disks.

Eg.
- Save a memory state on the menu screen of a disc (eg Automation 000)
- Restore the memory state and try loading a game on the menu - Game loads correctly
- Restore the memory state again and try loading the same game - resets back to gem desktop.

[npomarede]

Does it happen only with .ST/.MSA images or .STX ?

[squall]

It happens with all formats, ST/MSA as well as STX.

[npomarede]

It happens with all formats, ST/MSA as well as STX.

There was a problem in the order variables were restored and FDC considered all drives were empty.
This is now fixed in HG dev sources with rev #5149.
Thanks for reporting this.

[squall]

Thanks for the fix, it works now

[catmando]

Sound good, will check it out.

[npomarede]

New preview version available :
I added the possibility to write sectors to an STX image. For now, new sectors are only kept in RAM and content will be lost on exit (similar to pasti.dll)
But they will be saved in memory snapshot though, so they will be restored when a memory snapshot is reloaded.

If you know a game that saves high scores on disk, please test this :
- enter a high score
- save memory snapshot
- exit Hatari and restore memory snapshot : modified high scores should be restored

Links :
- windows exe http://antarctica.no/~hatari/latest/windows/
- sources http://hg.tuxfamily.org/mercurialroot/hatari/hatari/summary

[theelf]

Hi!

I tried, to see if this version have better scroll than last one, and it just crash when loading TOS

My PC is a AMD Athlon 1ghz


In my desktop, that have a C2D, works OK. The debug version works in the athlon, but maybe because is a debug, have a lot of problem with games

[LameLefty]

New preview version available :
I added the possibility to write sectors to an STX image. For now, new sectors are only kept in RAM and content will be lost on exit (similar to pasti.dll)
But they will be saved in memory snapshot though, so they will be restored when a memory snapshot is reloaded.

If you know a game that saves high scores on disk, please test this :
- enter a high score
- save memory snapshot
- exit Hatari and restore memory snapshot : modified high scores should be restored

Links :
- windows exe http://antarctica.no/~hatari/latest/windows/
- sources http://hg.tuxfamily.org/mercurialroot/hatari/hatari/summary

I'm glad to see STX support being added to Hatari, as that's the only currently-maintained ST emulator available for OS X. I don't mind downloading the sources and building it myself, but I've never downloaded from a tuxfamily site before. Is there a link for a tarball or zip archive of the source rather than a whole bunch of individual files? I suspect I must be missing something here ...

Thanks!

[npomarede]

I'm glad to see STX support being added to Hatari, as that's the only currently-maintained ST emulator available for OS X. I don't mind downloading the sources and building it myself, but I've never downloaded from a tuxfamily site before. Is there a link for a tarball or zip archive of the source rather than a whole bunch of individual files? I suspect I must be missing something here ...
Thanks!

For now, only sources are available by using mercurial; but it's really easy to get a local copy, just run :

Code: Select all

hg clone http://hg.tuxfamily.org/mercurialroot/hatari/hatari

When Hatari 1.8 will be released (in 1 or 2 weeks max hopefully), tar.gz file will be available too.

[npomarede]

New preview version available :
I added the possibility to write sectors to an STX image. For now, new sectors are only kept in RAM and content will be lost on exit (similar to pasti.dll)
But they will be saved in memory snapshot though, so they will be restored when a memory snapshot is reloaded.

Links :
- windows exe http://antarctica.no/~hatari/latest/windows/
- sources http://hg.tuxfamily.org/mercurialroot/hatari/hatari/summary

Release is coming soon, new test version available, this time with support for storing writes to an STX file in an external file !

Modifications are stored in a new file format I named ".wd1772". This is a rather simple but extensible format capable of storing all writes to sectors or tracks, with precise timing informations (the timing informations in this file are "simpler" than plain STX for example, because we only store data that can be written by a WD1772, so no variable bitcell or fuzzy bits)
For each .stx file, a .wd1772 file will be created when changes are made. The .wd1772 file will only contain the new data. This means that when reading from a .stx file, we 1st look for the data in the .wd1772 file, and if not found we use the original data from the .stx file.

Only limitation at the moment is that the STX file should not be inside a ZIP file to save the data into a .wd1772 file (that because the .wd1772 full filename is based on the inserted disk, by replacing .stx with .wd1772)

Please test it with games saving high scores (note : Platoon won't work as it uses "write track" too) and report problems before final release of Hatari 1.8

Nicolas

[Steven Seagal]

Hmm, this is not HFE.
I was harassed about it in the "STW" thread, so I'm waiting for criticism.

[npomarede]

Hmm, this is not HFE.
I was harassed about it in the "STW" thread, so I'm waiting for criticism.

You were not harassed, I tried to point that the format you described was lacking some fields to uniquely identify sectors (for example physical head and side).
I don't want to save data in MFM when writing to STX, I don't think it's necessary, so HFE format is not needed.
Maybe Hatari will support later an MFM file format, but for now, I just want to store the data written in sectors/tracks by the FDC. Just storing bytes is accurate enough in that case.

[Hippy Dave]

Hmm, this is not HFE.
I was harassed about it in the "STW" thread, so I'm waiting for criticism.

It is my opinion that .wd1772 is some sort of Hatari/Pasti save-state much like
the other Hatari debug save-state file. These files may create problems for
Hatari users as they are New And Improved Hatari extra-data.
(Disclaimer: New and improved may be New and Improved at any time)

[npomarede]

The internal content of .wd1772 is more or less close to internal save file, but it's also more modular.
The .wd1772 contains some version/revision values as well as some flexible sectors/tracks blocks.
So you can save as little as 1 single sector, or a whole disk if you like.
Unlike save state, the .wd1772 files will be compatible between all versions of Hatari. Maybe it will evolve later, but for now it's just about saving sectors or tracks for disk with more complex layour than a simple ST/MSA file.

[Steven Seagal]

You were not harassed, I tried to point that the format you described was lacking some fields to uniquely identify sectors (for example physical head and side).

Here you're talking of "STG" ghost disks, where your remark was appropriate, not "STW" where I got immediate requests for HFE support. I'm surprised people don't request it now.

[npomarede]

For STW, you said you wanted to uses MFM to store data, that's why I said several format already existed to store MFM data and could be reused in Steem (the one from HxC, but also the one used in MAME/MESS for which I gave a link to the source).
In Hatari, I don't wan't to use MFM to save writes, I don't think it's necessary. So HFE is not a candidate, what I want to save is closer to STX.

[Maartau]

Cool job ...