CIA-A DDRA fixed I/O bits direction

[ross]

Another thread where I was undecided whether to write in support.WinUAE or in the Coders.Asm/Hardware section.

This time this section won

I'm debugging an old game, that only work in KS1.x and only in some configurations, in an attempt to patch it (a not so simple job).
A game from 1987/88 that mix system code and hardware banging.
It use system to open multiple screens then mess with copper list to switch between them..
If you drag the main screen, after a while, game crash.

Original programmer, in an attempt to prevent this, used a strange method:

	move.b	#$43,($BFE201)

So DDRA(/FIR0) as an output.

WinUAE take /FIR0 as usual and screen dragging is permitted (and crash).
How a real machine behave?
Is the left mouse button really inhibited in this way or is it the programmer who's completely wrong?

Thanks.

[Toni Wilen]

If fire/mouse left button is output and data is high: button press will pull it down and reading pin state returns zero. When not pressed, it returns back programmed state. (IO pin is designed to work this way, there is no danger of damage.)

But there is at least one known CIA variant (that did not exists in 1987/88) where data register written value is always returned if output=1 when register is read. Actual pin state is ignored.

So there is possibility there are other CIAs with same "feature".

Does the game work if you tick advanced chipset "CIA 391078-01" checkbox?

[aros-sg]

Bone Cruncher?

[ross]

Originally Posted by Toni Wilen

Does the game work if you tick advanced chipset "CIA 391078-01" checkbox?

Yes, it works!

Thanks for the detailed information.
So a CIA variant existed 1987/88

Originally Posted by aros-sg

Bone Cruncher?

Yep

[Toni Wilen]

Same variant can't exist in 87/88 because it is SMD chip, first used in A600.

Also HRM says reading IO port will always return current state of pin, regardless of data direction.

Need to do some more tests..

391078-01 8520 has the "bug". 391078-02 8520 again works as documented (some A1200s and A4000s have -01, some -02). Perhaps there are also DIP 8520s that have same "bug".

EDIT: "original" discussion: http://eab.abime.net/showthread.php?t=88434

[ross]

HOL report as a 1988 game: http://hol.abime.net/182

But inside main executable there is (c) 1987 and the game intro is dated november 1987.
No evidence for the main exe because no original available.
Anyway probably programmed between these years.

There is a write to $bfe201 at start and then only a few read from $bfe001.

Yes, so it seems that in fact there are some DIP 8520s that have same bug.

Originally Posted by Toni Wilen

EDIT: "original" discussion: http://eab.abime.net/showthread.php?t=88434

Thanks for the link, very interesting.

[Toni Wilen]

I tested my A1000 and unexpectedly it has "buggy" CIA! (I thought it was SMD bug only so I didn't do any DIP CIA tests previously..)

MOS 8520A-1 0786 S

Different later DIP CIAs from A500s (all not buggy):

CSG 8520A-1 2991.

CSG 318029-03 8520PD 4291 24

CSG 8520 A-1 0391 24

CSG 8520A-1 0590 24

Still to test: 89 dated 8520.

So apparently early CIAs are also "buggy", later ones work as documented, then for some reason first SMD CIAs have same bug. Perhaps they accidentally based it on original design?

Test program is linked in above linked thread. (press joystick button, check output: **** **** = ok, **-* **-* = "bug")

EDIT: Even the very first HRM (1985) mentions that CIA IO pins always reads pin state, regardless of data direction.