A little bit later than anticipated, but here's finally the second part
of my Hatari memories:
Before continuing with the history, I should maybe also talk about the
name of Hatari here - I think I did that here and there in the past
already, but this definitely belongs to here, too: I've simply chosen
name "Hatari" as a kind of play on words with regards to my surname.
"Hut" in German means "hat" in English. I think I already knew in 2001
that there is also a movie with the same title, but IIRC I only watched
it some years later. So to make it clear: I'm *not* a fan of big game
hunting. And of course I couldn't foresee that there would be an
Islandic music band with the same name many years later...
Ok, the first part ended with version 0.30 in 2003, so let's continue
here: IIRC the following Hatari versions 'til 0.60 didn't have that
many spectacular new features, just lots of bug fixing and small
improvements, Matthias contributed the first version of the
manual.html, and Eero started contributing first small patches in 2004.
With Hatari 0.70, I started experimenting with adding new machine
types, i.e. the STE, by allowing TOS 1.06 and TOS 1.62 to run. As a
start, it's mostly enough to emulate the correct "bus error" behavior
for the I/O memory region of the corresponding machine, so that TOS
does not crash anymore when trying to access an I/O register of the STE
that was not available on the ST yet. Version 0.80 then featured the
first real emulation of STE hardware, like the STE palette, STE
shifter, DMA sound and the extended joystick ports, which was quite a
huge milestone again.
But there was still one thing where Hatari was quite bad with:
Emulation of the ST sync scrolling techniques and other effects that
required 100% cycle accuracy. Compared to other emulators on Linux like
STonX, Hatari was of course already the king of the ring, since the
basic timing of the CPU instructions was good enough for most cases:
The (original) UAE CPU core provided the information about the amount
of cycles for each instruction after emulation of that instruction had
been finished. But for sync scrolling, you need more - you need to know
the exact point in time *during* the emulation of an instruction to
know when e.g. the write accesses to the video shifter register happen.
IIRC I already started looking at the WinUAE CPU core at one point in
time, but adapting it to Hatari was a huge task, so I abandonded it at
that point in time again (spoiler: the idea came back later again), so
apart from improving some heuristics for the sync scrolling techniques
in Hatari here and there, getting sync scrolling etc. done properly in
Hatari sounded like a pretty much impossible task at that point in
time. In November 2005, I got a mail from a guy called "Nicolas
Pomarede" where he showed his interest in improving the cycle accuracy
of Hatari. We then exchanged some mails and he mentioned "I had a
closer look at the source, and as I begin to understand it, I think I
might be able to patch some functions to gain better accuracy." The
mail thread ceased shortly after and I already thought that would be
all and he lost interest again... Oh well, you might already know that
this assumption was completely wrong ;-)
Meanwhile Hatari continued to evolve, version 0.90 introduced support
for the TT TOS ROM images, and version 0.95 even introduced basic
support for the Falcon already - by adapting the Videl and NVRAM
emulation code from Aranym (written in C++) to Hatari (written in plain
C). DSP emulation was still missing, so this was not too useful yet,
but still, yet another big milestone in becoming a universal 68k Atari
emulator.
Now, if you're the author of a rather new project that starts with 0.x
version numbers, you end up at one point in time with the question when
to release version 1.0. Since 1.0 should of course be the "perfect"
release, shouldn't it? I already started thinking about how many
releases I wanted to do before 1.0, i.e. 0.96, 0.97, etc. and what
"goal" I wanted to have with 1.0 - when Nicolas suddenly showed up
again in January 2008 and announced his work here:
https://www.atari-forum.com/viewtopic.php?f=51&t=13142Nicolas didn't give up his ideas, but was working on this on his own
for more than two years! I remember that my jaw dropped when I was
seeing this in action - so many graphic effects were suddenly working
which I hardly believed to see in Hatari any time soon! So my decision
was clear: Once this is integrated in the main Hatari sources, this
will be version 1.0. Since our source trees diverged of course a little
bit in the course of time, this took of course some efforts, but after
I merged the basic code and saw the good quality of the changes, it was
clear to me that Nicolas would be an excellent addition to the Hatari
team, so I provided him with direct access to the CVS repository pretty
soon. In March 2008, when the integration was finished and other
pending issues were resolved, it was finally time to release Hatari 1.0.
And version 1.0 is a good point for ending this part of the Hatari
story. There is of course still much more to tell, but that has to wait
for another weekend with some spare minutes...
Cheers,
Thomas
Am Sun, 21 Mar 2021 09:00:09 +0100
schrieb Thomas Huth <
th.huth@xxxxxxxxx>:
Happy birthday, Hatari!
According to Hatari's doc/release-notes.txt file, the very first
version of Hatari, version 0.01, has been released 20 years ago, on
the 21st of May 2001. To celebrate the birthday, I'd like to
reminisce a little bit about the beginning...
I don't remember clearly, but I think the basic idea of the need of a
cycle-accurate emulator for Linux already started in the year 2000. I
was just 21 years old and just started my studies at the University of
Ulm. I already had Linux on my hard disk and I really liked it. But
for some things, you still needed to boot Windows 98 from your second
partition. Cycle accurate Atari ST emulation was one of these things.
On Linux, there was basically just STonX (see the website
http://www.complang.tuwien.ac.at/nino/stonx.html for the original
version), which did not see a new release since 1997. While STonX was
quite fine for running GEM applications with a decent speed, it
completely lacked cycle accuracy for the CPU emulation, so most old
games and demos either ran too fast or not at all, not to mention
things like color raster or border effects or even Spectrum 512
screens. There were two more Atari ST emulators around for Linux, one
called FAST (which later got renamed to CaSTaway, for details see
http://castaway.sourceforge.net/), but that was also completely
unmaintained and rather incomplete at that point in time, and one
called Osis, which had a completely different goal, though (it was an
emulator for GEM applications only, without the need for a TOS ROM -
see https://web.archive.org/web/20010210005756/http://osis.nocrew.org/
for details), so the situation on Linux felt rather frustrating after
having seen emulators like PaCifiST, WinSTon and STew on Windows (IIRC
STeem was also already available on Windows, but not yet on Linux).
Then at one point in time, I noticed that the author of WinSTon had
released the source code of his emulator (which still can be found on
https://sourceforge.net/projects/winston/). And the source code was
written in well-documented C. Well, it was wrapped in C++ files since
it had been written with Microsoft's Visual-C++ Suite, but apart from
some small C++ specialties, the code was mostly normal C. Apart from
the CPU emulation itself - that was written in x86 assembly, using the
syntax of the Microsoft compiler, of course. Since I hardly knew any
x86 assembly at that point in time and that assembly syntax was quite
different to the GNU one, this was completely useless for me on Linux.
So I was thinking about replacing the CPU core with a different one.
Initially I was thinking of the Starscream CPU core since that was
quite popular in other emulators at that point in time. But that was
also completely written in assembly, so it would have been harder to
debug and not portable to other CPU architectures. Fortunately, I
notice that the Amiga emulator UAE featured a good, cycle-accurate CPU
core that was written in portable C code, so I decided to use that.
During the break between the first and second semester of my studies,
in early 2001, I did not have much exams yet, so I had some spare time
which I used to make the WinSTon code compilable on Linux. Bit by bit,
I disabled all Windows-specific code in the sources, and rewrote some
functions that looked important to use POSIX file handling instead. On
the 21st of March 2021, I reached a point where all files that looked
necessary were finally compiling on Linux, too (i.e. I ditched the
files that only were used for the Windows GUI and thus very far from
being portable anyway), and I also copied the UAE CPU core sources
into the tree, without really wiring it up yet. I was so happy to get
to this point where the sources at least compiled that I even dared to
label it as version 0.01 already, though nothing was working yet, it
was really just a "compile test". But apperently I was on the right
track, indeed, since one week of intense hacking later, I was already
able to boot TOS 1.00 up to the desktop in the emulator. That was
version 0.02, still no keyboard and mouse yet, but seeing the desktop
was certainly a huge motivation to continue.
I also wanted to share my work very early already, so I've put the
early versions on my private website already. I wasn't able to find
version 0.01 or 0.02 in any of my backups anymore, but I've found a
backup of version 0.03, so if you're interested, this is how the
website looked at that point in time:
http://hatari.tuxfamily.org/archive/hatari-0.03/hatari_e.html
... and if you're brave, you can even download the source code and try
to make it compile and run on new systems again (beware, it won't run
out-of-the box! You have to add -lm to the linker and -fcommon to the
CMPLRFLAGS, and increase INTERCEPT_WORKSPACE_SIZE quite a bit).
In the following weeks and month, the project slowly took off. There
were some contributions by others who got curious, and in late May
2001, Hatari even got a proper CVS repository on SourceForge (see
https://sourceforge.net/projects/hatari/ - the CVS repo has been shut
down nowadays, but you can still download the early tarballs starting
with v0.05 there).
In the course of time, I then rewrote bit by bit the disabled
Windows-specific parts in the sources, finally also getting sound
support and stuff like the Spectrum 512 screen rendering support
working on Linux, too, and increased bit by bit the integration of the
UAE CPU core with the rest of the WinSTon-ased sources, but it took
until version 0.30 in 2003 until one nasty bug in the interrupt / SR
handling was finally fixed (it was the bug that got fixed in commit
https://git.tuxfamily.org/hatari/hatari.git/commit/?id=a2313ce7c755fea9
if I remember clearly, a bug that caused random crashes while moving
the mouse, for example), so that my original dream of having a usable
cycle-accurate Atari ST emulator for Linux finally came true at that
point in time, I think.
So that were my memories of the very early days... Of course a lot of
additional stuff has happened in the course of time, but for this mail
here it's enough of sentimentality, I think (but I can continue maybe
next weekend if you liked this kind of memory dumps, or maybe Nicolas,
Eero, Laurent or anybody else could share some memories about the
Hatari history, too).
Enjoy,
Thomas