Re: [hatari-devel] Happy birthday, Hatari!

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Hi,

I guess it's my turn to say few words of my Atari + Hatari involvement. :-)


I had been using Atari, a plain STfm with 4MB + mono monitor quite long time, until late nineties.

By that time I had used MiNT (with Jürgen Lock's vconsole) quite a while, lastly to develop WWS (W Window System) for MiNT with Kay Römer and Thorsten Scherer when I was at the university, but eventually I switched to Linux.

(If Kay Römer's name isn't familiar, I think he did most of early MiNT networking stuff, and later one of the early Linux CORBA implementations.)


I had tried PacifiST on DOS, and used STonX on Linux, but due to their issues, I was looking for something better.

I think I started using Hatari somewhere around v0.45. I contributed some minor things to Hatari before Thomas took me as a developer.

When Nokia nixed its last Linux (phone) product projects in 2012, I had been doing Linux system performance analysis there for many years, and I missed similar tools for optimizing SW for Atari. So when I was unemployed for a while after that, I had a lot time to write Hatari profiler. That's the Hatari contribution that I'm most proud of.

Happily Douglas Little had just started to look again into BadMood (Doom I/II Atari Falcon port + renderer rewrite), so I had somebody with a lot of experience both in optimizing m68k & 560001 code at assembly level, and with console performance analysis tools, to test Hatari profiler and give feedback on it.

First Atari-forum / BadMood post on profiler is here:
https://www.atari-forum.com/viewtopic.php?p=223894#p223894

But IMHO the whole main BadMood thread is pretty good read for somebody who's into optimizing stuff (profiler posts starts from page 5):
https://www.atari-forum.com/viewtopic.php?f=68&t=24561

Without Douglas' feedback, Hatari profiler would have lacked many features, and probably been buggier too. And without Hatari CPU/DSP profiler, progress on BadMood performance would have likely been much slower.

Conditional breakpoints feature Nicolas had asked to be added to debugger before that, was also a great combination with the profiler, as with some additional changes I was able to completely automate BadMood profiling.

With that automation, one needed just to start Doom recording playback, and profiler produced automatically annotated assembly + cycle & instruction call graphs for slowest CPU and DSP frames of the whole BadMood game play recording.


I don't think anybody's used the profiler that extensively since Douglas stopped working on BadMood and his Quake / CounterStrike port...


The main things I like about Hatari is being able to try out Atari stuff that I wasn't able to run on my old STfm (STE and Falcon games + demos), and it (along with EmuTOS) helping the Atari related SW & HW projects.

I think e.g. Till Harbaum who developed the original MiST, used Hatari to emulated rest of the stuff that his HW didn't emulate yet:
https://www.atari-forum.com/viewtopic.php?t=24583


	- Eero

On 21.3.2021 11.13, Laurent Sallafranque wrote:
That's an excellent and very interesting story.

Thanks a lot Thomas to share it for us.

I think it could be published in atari's forums at the birthday date for other atarian entousiasts.


3 Things for me :

- did I tell you that I'm working with the guy that wrote Pacifist ? We discovered each other in a meeting (my Atari sticker on my laptop helped to ice break and we started to speak about the atari world) ;)


- I've digged into my story with Hatari and I've just discovered that my collaboration with the team started in april 2008 (time flies so fast) :)


- For my part : I add 2 Atari ST and then a Falcon back in the old days. I left everything for studies and forgot the Atari world until march 2008. I thought about emulation to take up with the Atari world. As a huge fan and user of Linux since ages, I searched for a compatible emulator for this OS. I found Hatari.  2 things I immediately liked were that it worked "out of the box" and the open source spirit of the project.

I started to play with the emulator by testing my old ST code and I tried some old code I wrote back in 1994 - 1995 for Falcon. The 68030 part was working, but not the DSP part. I'm also a fan of Audio Fun Machine, and I started to dream that this program could revive one day.

That's about the time I told to myself I could contribute to Hatari development and I started by the DSP emulation (logical choice as I had never coded anything for the DSP before and I nearly didn't know anything about this chipset) ;)

My goal was to learn DSP coding, code a little demo for Falcon (I never released one in the old days, so it was not too late to code one), and improve Hatari. My first attemps to debug Patrice Mandin's code gave good results : after a few instructions fix, I managed to have the very first DSP Falcon demo running (it was SPHERE.PRG in june 2008) and 3DWORLD.PRG a few days later.

After a long debugging (and more demos working), I started to implement the missing parts of the DSP emulation (DIV instruction, PORT C, 2 channel Port-B, interrupts, Roundind code, ...) and more demos worked. But there was still no sound as the Falcon crossbar was not implemented. So I added this also and improved some other parts of the emulator here and there when I found something to fix.

I still take a lot of pleasure to code things for the Falcon and to code under Hatari here and there with all the team.

I really appreciate how you gave me your trust back in 2008 and the result is now great (the Falcon is better and better emulated after each version).

Thank you all.

Regards

Laurent

------> under is my very first mail to a certain Thothy, 02 april 2008 17:55  <---------------------------

Hello Mr Thothy,

First of all, I want to thank you very much for Hatari, it's a great program.

I present me : my name is laurent Sallafranque, French (sorry for my poor English), 34 years old. I used to have an Atari 520 stf, a 1040 ste ans a falcon030 (all sold 10 years ago, shame on me !!) I coded the "faith demo" with chuck in 1993 (I belonged to Dune demo group).

Why do I write you ? I would like to help (if it's possible) in the hatari project.

I fixed me a goal : to have AFP like programs work on hatari (DSP sound emulation working).
I've taken the last source release on CVS.

I've started to add DSP SSI emulation (nothing works better actually).
- DSP.H : I've added the SSI registers and bits definition (#define DSP_SSI_xxx )

- DSP.C : I've just added the initialization of SSI registers in DSP_Reset method.

- DSP_CPU.C : added the SSI interrupts in dsp_postexecute_interrupts method.
(not completely finished yet, I still have to emulate the interruption flag

I've also started to have a close look at the actual DSP code emulation :
- I activated the ENABLE_DSP_EMU flag, and started a few tests :

I realized that DSP registers are only read once at emulator initialization and never refreshed later. But Dsp change the state of these registries each time datas are sent, receives, ... I've added a method in ioMem.c (I should have added it in ioMem_tabFalcon I think) to refresh dsp host registers when a IoMem_bget() is done in the dsp memory zone. I called it IoMem_RefreshDspIOMemory()

I've also added the 3 next lines into every IoMem_Xget() method (it's probably not the best way to do this, but I
don't know hatari code enough at this stage).
#if ENABLE_DSP_EMU
IoMem_RefreshDspIOMemory(addr);
#endif

I think it's a preliminary to get all the Dsp registry IO values before emulate them into the DSP.

I send you the few modification in the attached zip for if you find them interesting.

I would need to look closely to the dsp code and also help and open discussion with you all before doing more code.

Do you think I could help you in the hatari project ?

Sincerely,

Laurent

PS : I tried to compile the very last CVS version, I've got the following error :
dlgScreen.c: In function ‘Dialog_ScreenDlg’:
dlgScreen.c:176: erreur: ‘CNF_SCREEN’ has no member named ‘FrameSkips’
dlgScreen.c:184: erreur: ‘CNF_SCREEN’ has no member named ‘MonitorType’
dlgScreen.c:299: erreur: ‘CNF_SCREEN’ has no member named ‘FrameSkips’
dlgScreen.c:307: erreur: ‘CNF_SCREEN’ has no member named ‘MonitorType’
make[1]: *** [dlgScreen.o] Erreur 1

I've kept the cvs version from 3 days ago to make my tests.

-------------------------------------------------------------------------------------------------------------------------------------------




Le 21/03/2021 à 09:00, Thomas Huth a écrit :
  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.





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/