|Re: [hatari-devel] new acia / ikbd emulation|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
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.
----- Mail original -----
De: "Nicolas Pomarède" <npomarede@xxxxxxxxxxxx>
Envoyé: Mercredi 31 Octobre 2012 00:34:21
Objet: [hatari-devel] new acia / ikbd emulation
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
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
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
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
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.