Re: [hatari-devel] new acia / ikbd emulation

[laurent.sallafranque@xxxxxxx]

Hi,

I'm currently in hollidays.

Thanks a lot for the acia emulation, nice work.

Does this mean that now, it'll be easy to add the 6301 emulator I started last year ?
(I think it will be easier now).

I'll have to give a closer look to your code for the DSP, as the DSP Host <---> CPU and the DSP SSI <---> CPU are also parallel and serial interfaces. (one is running at 8 Mhz too).

Maybe there are some ideas to share for the both chips.

Best regards

Laurent


----- Mail original -----
De: "Nicolas Pomarède" <npomarede@xxxxxxxxxxxx>
À: hatari-devel@xxxxxxxxxxxxxxxxxxx
Envoyé: Mercredi 31 Octobre 2012 00:34:21
Objet: [hatari-devel] new acia / ikbd emulation

Hello

as explained in a recent thread, the ikbd.c code in Hatari is getting 
more and more complex, adding special cases (sometimes hacks) for 
uncommon situations, which often leads to regressions, due to never 
fully implementing the full acia behaviour.

So, I added a whole new acia.c that handles a full emulation of the 
MC6850 ACIA at the bit level.
All registers and status bits should be correctly emulated, along with a 
very precise transfer model, emulating the serial transfers at the bit 
level, with control for start/stop bits, parity, overrun, IRQ 
conditions, ...

Basically, transfering a bit between the ACIA and the IKBD at 7812.5 
bauds takes 1024 cycles for a 68000 running at 8 MHz.
This might looks a little overkill to emulate transfers at the bit 
level, but when looking at the datasheet, some status bits are changed 
during the transfer, not when the transfer is completed, so timings 
really matter.

On the other side, I added a more basic Serial Communication Interface 
in ikbd.c, to receive/send bits with the ACIA, using the same start/stop 
bits.

So, the ACIA and the IKBD are now using a real serial protocol to 
communicate with each other. As long as they correctly stay "in sync", 
this should not cause problems. In case of error, a framing error is 
triggered.

Both the ACIA and the SCI emulate the Transfer Shift Register and 
Receive Shift Register, which act as a double buffer and allow to 
process a 2nd byte as soon as the 1st byte is written in an empty TDR.

A lot of code was cleaned in the ikbd.c, including a rewrite of the 
custom ikbd handler (based on the hd6301 disassembly).

I didn't rewrite the MIDI code, but it could be done to use the 2nd ACIA 
without too much trouble (but is it required now, do we have problem 
with midi ?)


To avoid regressions, I tested various demos/games that caused problems 
in the past : Overdrive Demo, Pandemonium Demo, V8 Music disk, Froggies 
Over The Fence Demo, Dragonnels Demo, Platoon, Fokker.prg, Carrier 
Command, UUS John Young, Hammerfist, Hades Nebula, Yogi Bear, ...

Still not working (not related to ACIA) : F29 Retaliator.


Don't hesitate to test the above games/demos yourself or any other 
program known to have problem with ikbd.


Nicolas