Re: [hatari-devel] Upstream / downstream code in Hatari

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi Andreas,

On 21.8.2025 21.07, Andreas Grabher wrote:
> > Am 21.08.2025 um 15:35 schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> > Before it's applied, I'd like to know which parts of Hatari are:
> > - Used as-is
> > - Modified
> > - Ignored
> >
> > In Previous, so that I can document both upstream[1] and downstream[2] project considerations in Hatari "coding.txt".  Andreas?
>
> All files not mentioned below are either ignored or highly modified and not synced. Only .c files mentioned. Corresponding .h files have same status.

Thanks, this is very detailed!

It's quite a long list though, so I'm not completely sure how / what of 
this to put to coding.txt, but let's see.  It's anyway interesting to 
hear how Hatari code gets used!

> Identical or only minor differences:
> configure
> cmake (dir) except for config-cmake.h due to Previous’ different components
> src/cfgopts.c
> src/cpu (dir) except for memory.c and hatari-glue.c, which are highly modified

Out of curiosity, do you build src/cpu/ with WINUAE_FOR_HATARI enabled?

> src/debug (dir) except for console.c, natfeats.c, profilecpu.c, profiledsp.c symbols.c, symbols-common.c (ignored or highly modified) and debugcpu.c (modified - Hatari specific code removed)

You don't have any need for profiling or debug symbols and backtraces 
(which needs both of those functionalities)?

I don't think profiler has anything Atari specific except handling and 
printing of memory area limits, which is very small part of it.

It needs symbols though, but while binary symbol formats are Atari 
specific, the ASCII one (used with profile post-processor) is not, and I 
think you can just ignore (ifdef out) rest.


> src/falcon (dir) directory renamed to dsp; crossbar.c, microphone.c, nvram.c and videl.c ignored
> src/file.c
> src/gui-osx/paths.m
> src/gui-sdl/CMakeLists.txt
> src/gui-sdl/dlgAlert.c
> src/gui-sdl/dlgFileSelect.c

I would guess that NeXT users don't use fsel ZIP browsing functionality 
that much.  It's been there long time, but I'm not sure whether I've 
never used it myself, as all my (floppy) image files are separate.

> src/gui-sdl/font10x16.bmp
> src/gui-sdl/font10x16.h
> src/gui-sdl/font5x8.bmp
> src/gui-sdl/font5x8.h
> src/gui-sdl/sdlgui.c
> src/gui-win (dir)
> src/paths.c (just some renaming Hatari -> Previous of externally visible strings/paths)
> src/str.c (identical down to Str_UnEscape, rest is ignored)

NeXT supports just 7-bit ASCII file names and does not need conversion 
of 8-bit characters?

> src/unzip.c
> src/zip.c
>
>
> Modified:
> CMakeLists.txt (Previous has additional components and still some C++ code, although I translated most of it to C recently)
> src/change.c (Previous has different options)
> src/CMakeLists.txt (same as CMakeLists.txt)
> src/configuration.c (same as src/change.c)
> src/dialog.c (Previous adds dialogs that prompt user for files not found)
> src/gui-sdl/dlgKeyboard.c (shortcut selection mostly identical, other things differ heavily)
> src/gui-sdl/dlgMain.c (different dialogs, but same structure)
> src/shortcut.c (different shortcuts, but same logic)
> src/statusbar.c (different indicators, but mostly same logic)
>
> > Andreas, how you're developing Previous and keeping track of Hatari if you're not using Git?
> ...
> I download the diffs and add them using patch. Most commits are not relevant for Previous. So I pre-select what I need.

Applying each relevant commit from Hatari sources by hand, sounds rather 
laborious.

But with this large set of differences, handling git rebase conflicts 
could also be quite a lot of work, especially when list of change 
commits stacked on top of the upstream code grows (so at some point it 
would be more work unless those changes could be upstreamed).

What version control you're using for Previous code?


	- Eero