ACIA timings

A place to discuss current and future developments for STeem

Moderators: Mug UK, Steem Authors, Moderator Team

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1811
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed

ACIA timings

Postby Steven Seagal » Sat Jun 21, 2014 8:30 am

In Steem SSE there was a problem with the mouse speed when the 6301 low level emulation is used.
I thought it could be related to wrong timings, but now I found a way to get better mouse movement with the same timings, so maybe they're right. Below is part of Steem doc. Noticeable is that delays are longer than they should be, and this for one case, Froggies over the Fence. And there's a hack in Hatari for it as well:

Code: Select all

/* TODO : an extra delay of 7000 cycles is necessary to have $81 and $80*/
/* received after the overrun condition was cleared at the 68000 level.   */
/* Does it mean some timings are wrong with acia/ikbd ?         */

Not sure the delay is the same as in Steem (70 ACIA cycles), but it's the same idea.
In the text below RDRS and TDRS are the shift registers for ACIA's in (RDR) and out respectively (TDR).

ACIA <--> IKBD timings
Data is transmitted at 7812.5 bauds between the ACIA and the HD6301.
7812.5 bit/s, 10bits should translate into 1280 ACIA cycles/byte
(Even less if we should count 8 bits: 1024).

In Steem, we must use 1350 cycles instead, that is 70 cycles more,
or Froggies menu won't work well.
No improvement in ACIA emu could lower this number, so we try and
justify it instead ;)

When the CPU sends $4, IKBD sends 4 bytes.
With adapted timing, 2 bytes are ignored due to ACIA OVR, the
program uses the 2 remaining bytes and it works.
With theoretical timings, 3 bytes are ignored and it's broken.

Possible explanation: there's starting & finishing delay for each byte,
because copying TDR to TDRS and RDRS to RDR takes some time in both chips,
maybe more in one that the other.

For example:

Code: Select all

ACIA/IKBD transfer

Baud                          7812.5
#bits                             10
bytes/s                         781.25

ACIA frequency               1000000
ACIA cycles/byte                1280

TDR->TDRS delay                   25
in CPU cycles                    200 (value OK for Nightdawn and Hades Nebula)
RDRS->RDR delay                   25
in CPU cycles                    200

ACIA cycles/byte                1330

MC68000 real frequency       8021248
MC68000 used frequency       8000000
ratio                       1.002656

ACIA cycles/byte          1333.53248
More delay in 6301?             16.5
ACIA cycles/byte          1350.03248 (value OK for Froggies over the Fence)
MC68000 cycles/byte      10800.25984

This is speculative.
Anyway, a difference of 70 ACIA cycles isn't too terrible. It looked worse
before because
- WinSTon/Hatari used a "measured" value of 7200 (CPU cycles)
That was the older versions. In current version of Hatari there's a low level
emulation of the ACIA, but we notice a hack for Froggies in it as well, where
the timings are made longer than theory.
- 7812.5 baud is ambiguous, it isn't clear that you must add control bits to
get real speed.
In the CIA we learned that ST ruled
Steem SSE:

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1811
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed

Re: ACIA timings

Postby Steven Seagal » Tue Dec 01, 2015 6:33 pm

There never was any discussion here, but I found a case where the theoretical timing of 1280 HD6301 cycles per byte is asserted: Snork/Defulloir. The demo checks the data register every 20 scanlines.
For Froggies, there will now be a hack in Steem that prolongs it in case of overrun.
There's no real basis for it.
This means the justification for longer timing in 1st post is bogus.

(note: HD6301 cycles, not ACIA, it was a mistake)
In the CIA we learned that ST ruled
Steem SSE:

Social Media


Return to “Development”

Who is online

Users browsing this forum: No registered users and 1 guest