Re: [hatari-devel] SCC support

[Thomas Huth <th.huth@xxxxxxxxx>]

On 21/05/2021 00.27, Eero Tamminen wrote:
> Hi,
>
> On 18.5.2021 22.57, Thomas Huth wrote:
> > Am Tue, 18 May 2021 00:55:27 +0300
> > schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> > > Debug macros were a mix of different things, so I
> > > converted them to SCC trace and DEBUG & WARN level
> > > log outputs.
> > >
> > > I also removed Init()/UnInit() debug output and
> > > added output to reset functions (and removed superfluous "inline"
> > > from one static function).
> > >
> > > Does the mapping in the attached patch look reasonable enough to push?
> >
> > Yes, looks fine to me at a first glance.
> >
> > > (Only testing I did for it was EmuTOS boot on TT
> > > & Linux boot on Falcon.)
>
> Thanks, I've pushed that commit.

FYI, looks like this caused a build failure in the MinGW CI job:

https://gitlab.com/huth/hatari/-/jobs/1281046052

> > > Btw. There's also another, preliminary patch
> > > that sorts trace options for trace help output.
> > >
> > > Any objections on that?
> >
> > Should the #defines in log.h get sorted accordingly?
>
> I thought about that, but then the values would
> need to be changed accordingly, *every* time one
> adds new trace define.
>
> Generating the trace mask values solves that, but
> I couldn't get it work as well with CMake as I would have liked, and 
> currently requires AWK
> (so for Windows, the generated file probably
> needs to be in git too).
>
> See attached patch.   Comments?

I agree with Nicolas, let's keep away from autogenerating them / adding more 
dependencies on external tools.

So if we want to re-order the defines, too, maybe it's best to go through an 
intermediate step with an enum instead, i.e.:

enum {
	...
	TRACE_VIDEO_SYNC_BIT,
	TRACE_VIDEO_RES_BIT,
	TRACE_VIDEO_COLOR_BIT,
	...
};

and then:

#define	TRACE_VIDEO_SYNC	 (1 << TRACE_VIDEO_SYNC_BIT)
#define	TRACE_VIDEO_RES 	 (1 << TRACE_VIDEO_RES_BIT)
#define	TRACE_VIDEO_COLOR	 (1 << TRACE_VIDEO_COLOR_BIT)
etc.

What do you think?

 Thomas