Re: [hatari-devel] SCC register handling on TT

[Thomas Huth <th.huth@xxxxxx>]

Am Sun, 27 Nov 2016 19:51:13 +0200
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:

> Hi,
> 
> When looking at SCC register handling in relation to:
> http://www.atari-forum.com/viewtopic.php?f=51&t=29989&p=306208#p306208
> 
> Hatari isn't yet emulating SCC, but I started to wonder
> about Hatari's handling of non-implemented SCC registers...
> 
>  From what I see from ioMem*.c sources on SCC regs access:
> * ST & STE bus error
>    -> corresponds to bus error tester results  
> * Deliberately voided for Falcon STE compat mode (ioMem.c)
>    -> corresponds to bus error tester results  
> * Deliberately voided for normal Falcon mode (ioMemTabFalcon.c)
>    -> corresponds to bus error tester results  
> * Bus error for TT
>    -> does NOT correspond to bus error tester results  
> 	$FF8C20 - $FF8C80
> 	$FF8C90 - $FF8E01
> 
> Is above interpretation right?

I think so, yes.

> Thomas, does above bus error test mean that $FF8C80
> generates bus error or not (i.e. is the output range
> inclusive or exclusive or range end)?

IIRC the right hand side of the entries in the bus error tester output
do _not_ generate a bus error anymore. So $FF8C80 should not generate a
bus error.

The TT IO memory region has never been fixed for proper bus error
accuracy, mainly since quite a bit of emulation is still missing.

For example, only disabling the bus errors in the SCC IO memory region
without providing real emulation is a kind of double-edged sword - some
programs might suddenly run, but others that use bus errors for
detecting the presence of the SCC might stop working, because they
suddenly think that the SCC is there and depend on the right behavior
of the registers which is not emulated yet.

So the really right way to fix this: Implement proper SCC emulation!
(and to get this right, you also might need to implement proper
emulation of the second MFP of the TT). ... can of worms ... ;-)

 Thomas