|Re: [hatari-devel] Hatari/EmuTOS Conflict|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] Hatari/EmuTOS Conflict
- From: Vincent Rivière <vincent.riviere@xxxxxxxxxxx>
- Date: Wed, 12 Jun 2013 00:46:11 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=euYeQ+VAyjdzPnWeYQLCmHv/ZzRF4Iu/mB5X6fFBsBY=; b=YA0MEQoZBLqqrt7FXnnbBdIvCv71VfiXugFUWRhPraVRbqEeccD5ifTlBRnQgPZei3 qNcabcGSSYruowQYOILkZHSkzZIwTt/GBq6aiGdkTnK6dGRjB7XuoX/Tv+L7gx3I2W5Y 1W7WFSWffVNju5OI+xs5vosKvclM1s/DLclgA8fxXMw6d+8U26UE3oUIV2iSDSB2secD yaTqyWgM5nh9FvJc5WUho9obsODuTNCLynH/P4xbpFFgwFVC+s6z5+E1lD6TgD3GhUw4 qQaE84/3pPmqhRXDVvovWz+s6g5dte3bcevpKE/DOYvpTp0SeXyUGRtaL7Q6t8v7k+iH SdHw==
On 11/06/2013 01:03, Nicolas Pomarède wrote:
I don't see any problem in this part, acia reset is correctly detected and
emutos-cvs-20130604 boots with functional mouse/keyboard, even without the
patch I added to force acia at 9600 bauds on cold start.
Here're the traces :
acia ikbd write fffc00 cr=0x03 video_cyc=59888 452@117 pc=e06b1a instr_cycle 16
acia ikbd write cr data=0x03 VBL=53 HBL=117
acia ikbd master reset VBL=53 HBL=117
-> reset is made
acia ikbd write fffc00 cr=0x96 video_cyc=59912 476@117 pc=e06b20 instr_cycle 16
acia ikbd write cr data=0x96 VBL=53 HBL=117
acia ikbd start timer divider=64 cpu_cycles=1024 VBL=53 HBL=117
-> acia is initialized at 9600 bauds
Even if it works, this looks like a bug in EmuTOS.
The ACIA speed should be initialized before sending bytes, isn't it?
But there's a problem in Emutos : we can see it still sends 0x1a and 0x12
*during* the reset, which is not correct, it should send them after getting
a 0xf0 or 0xf1 from the ikbd.
I wrote ikbd_readb() especially to avoid this situation.
static UBYTE ikbd_readb(void)
unsigned int i;
/* We have to use a timeout to avoid waiting forever
* if the keyboard is unplugged. The standard value is 300 ms.
for (i = 0; i < 300; i++)
if (ikbd_acia.ctrl & ACIA_RDRF)
return 0; /* bogus value when timeout */
return 0; /* bogus value */
If it returns before the byte is received, either the test of the ACIA
status bit is wrong, or the function timeouts. Maybe the timeout value is
not adjusted correctly. Also as I told you, in those early stages
delay_loop(loopcount_1_msec) is not accurate and will not wait enough time
if he CPU is faster than expected.
By looking at the disassembly, the bit 0 of 0xfffffc00 is correctly tested
in the loop.
Is this version of Emutos CVS really compiled with CONF_WITH_IKBD_ACIA ?
Yes, proven by the disassembly.
Maybe this line should be enabled :
560 #if DBG_KBD
561 kprintf("ikbd_version = 0x%02x\n", ikbd_version);
To see if emutos really received 0xf1 or 0xf0, or bypassed the test.
I will setup a test environment (latest Hatari, EmuTOS, MIDI debugging...),
but I'm currently very busy. Anyway, I will need to find the time to look at
that before the next Hatari/EmuTOS release.