|Re: [hatari-devel] SCC support|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] SCC support
- From: Thomas Huth <th.huth@xxxxxxxxx>
- Date: Fri, 21 May 2021 10:30:04 +0000
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1621593005; bh=BtZF9wxVkAuYyaiVXmATroj6Mz0vqC554k5BGE9sWYw=; h=Subject:To:From:Date:From; b=pPJLupvAMSJOkuLEVvkLShyZ5LZG8We60f0Lq0xrr1Y5DZX/uVH2dAyKFDohjsvOX 4cYmDAk5Q2+k3/YdV1y95FDD4+ISYG/dOe152KccI9LwaT4onOdGMR8ktk1aznDG/V OMsGjLE2mx8djskVjA8sK3BTzK4YM7ge2WzO9/2t06w0qecaJa/er7mLndbNed5IQU Pe6QNmA6dB/cjGHXIsFLRiXS6jhEf5mjoqbVfbLEBYeLGcVHvO+B2K0re2E3Knjz56 /3WFKXfhtZiaKz6LwyBgU+65BRvZpv1+XDEz8LXhBTOPrq74g/oej+dUc52DCh9ZIv c/CQPjZaZHWMw==
On 21/05/2021 00.27, Eero Tamminen wrote:
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
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:
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.:
#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)
What do you think?