[hatari-devel] Hatari memories - part 2 (was: Happy birthday, Hatari!)

[Thomas Huth <th.huth@xxxxxxxxx>]

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=13142

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