Re: [hatari-devel] Hatari/EmuTOS Conflict

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

On 12/06/2013 23:21, Vincent Rivière wrote:
> Le 12/06/2013 21:12, Nicolas Pomarède a écrit :
> > Now, Emutos should be correct regarding the byte to expect after a soft
> > reset, and Hatari should be correct regarding the serial line's state
> > just
> > after a cold start.
>
> Amazing analysis and bugfix!!
>
> Hatari and EmuTOS are now more accurate than ever :-)
>
> BTW: Can we be sure that on real hardware the cold boot 0xf1 is not
> received by the ACIA?
> As I said previously, Atari TOS just waits a fixed time after sending
> 0x80 0x01. If 2 bytes arrives, I guess that it causes an receiver
> overrun, and no one notices...

My guess is that the serial is really not working on first cold start, 
so 0xf1 will be lost (it all depends on when you reset the acia, the 
sooner you do it, the more you might be able to receive this 0xf1 ; in 
fact, you need to init the acia before ikbd sends a byte, which would 
require to init the acia nearly as soon as emutos starts).

And even if you receive a 1st 0xf1 and don't read it, you will loose the 
next byte, which is also a 0xf1 (in response to the soft reset you 
sent), so in the end you read 0xf1 in all cases.

> I thought that checking the RDRF bit before reading the data register
> was a good idea to do clean things, but maybe I was wrong...

No, it's the good thing to do ; if you don't test RDRF before doing a 
read, you might read the same byte several times, and you won't be able 
to know if it's because the ikbd really sent several times the same 
bytes, or if it's because fffc02 didn't change.

> So I wonder if the current EmuTOS still works fine on cold boot on real
> hardware.

To know this, it would be interesting to make a debug version of emutos 
that init as usual but that also prints all received bytes from the ikbd 
(each time RDRF is set) during the first 2 seconds of the boot for example.
Assuming you don't touch the keyboard or mouse, you will be able to 
exactly see what the real hardware is sending, and if we get 1 or 2 0xf1.

If printing is not an option, those bytes could be written in a safe 
place in RAM, to be read later when boot is complete.


Nicolas