|Re: [hatari-devel] Hatari/EmuTOS Conflict|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
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
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
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.