Re: [hatari-devel] hatari tt scc emulation

[Thomas Huth <th.huth@xxxxxxxxx>]

Am Tue, 18 Jul 2017 01:32:50 +0300
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:

> Hi,
> 
> On 07/17/2017 08:19 PM, Christian Zietz wrote:
> > Uwe Seimet schrieb:  
> >>> As I had already written, MiNT does not directly access the
> >>> registers in  
> >>
> >> I know, but MiNT *could* before using TOS code that requires the
> >> respective hardware to be present. The more operating-system like a
> >> software is, the more it makes sense to use a low-level approach
> >> for certain things.  
> >
> > While this maybe can be argued in the case of MiNT, the reported
> > issue affects *every* application that uses TOS functions to access
> > the TT's serial ports. I.e. most terminal programs will be
> > affected. I don't think one should require an application -- that
> > runs perfectly on a real TT -- to jump through additional hoops,
> > just to be compatible to Hatari. Especially if said application is
> > even programmed "cleany", i.e. only using TOS functions. That's not
> > the point of an emulator, imho.
> >
> > It is of course perfectly OK that Hatari (for the time being?)
> > doesn't support every bit of hardware; but applications should not
> > crash, particularly if they don't DIRECTLY access that unsupported
> > hardware.  
> 
> I guess the options in descending order of desirability are:
> 1. Implement TT SCC / MFP support

That's the best option, indeed.

> 2. Make Hatari patch Rsconf() in TOS 3.x not to crash until 1) is done

You'd need some TOS patches for this ... could be a valid option, I
guess.

> 3. Use incorrect SCC register handling to avoid the crashes

Please don't do this - that just changes the problem into a different
one. I'm pretty sure somebody will then complain in a year or two "my
hardware detection in my program XY does not work right since you're
not generating bus errors for hardware that you do not emulate"! ...
We've had that in the past already...

 Thomas