|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: Tue, 18 May 2021 19:57:06 +0000
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1621367828; bh=0c4LI7HsvJT2w+riLP/kb0+xGq8+maqJgrUZ4NTZtyg=; h=Date:From:To:Subject:From; b=ZToEC9XpW+qSyw2qvchibVY5hQ9IKLgWgJNqVOclHCVL8zSDXDpE2R/GxUCrj0+Yx l6HnomM5G6tFzNuEnhwHNyf4Jj1G4DoDxMKC5918Z3emdIdUO0+Wd7aJlLOVfGkb7t zyL7itTkNi6UktQBWWdkYxIr+M0fIWu/IBqLHDBUCCQMUf29lx6mdF9JtsRtdwfdYk PwkaIGLUP9aDxm5PB3tkaIHKoYyXxw6hQh0cQ4id8rLIiQVv+3cc1oC3bbKWNlLGC+ VXoNmsUFYG7PnWasCmrF+VvYqwilyg6mOea/8yzg48IGMDo1icig+eLQSYi+nGJ2ND 44Vdu6bEbrvJg==
Am Tue, 18 May 2021 00:55:27 +0300
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> Hi Thomas,
> On 15.5.2021 14.01, Thomas Huth wrote:
> > I'm currently not working on the SCC code anymore. It was just a
> > quick-n-dirty adaption of the SCC code from Aranym to get rid of
> > the bus error problem that we had with the TT IO memory map. The
> > current status is just enough for outputting some bytes. Interrupts
> > have not been wired up yet, and the D(bug()) stuff is also just
> > there because it has been copied over from Aranym. If someone wants
> > to work on this code and implement interrupts or rework the debug
> > printing, be my guest, I currently don't have any local
> > modifications to that file.
> 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.)
> 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?