Reading write only port...

[Lone]

Hello,


I recently came accross a curious piece of code, which basically doest the following :


ld bc,&f792
[/size]out[/color][/size] (c),c[/size](... some stuff, without any IO or interrupt)[/size]ld bc,&f792[/size]in a, (c)[/size]How can we know what is returned here ?[/size]If I just try the following [/size]10 out &f792[/size]20 print inp (&f792)[/size]it displays 127 (consistently)[/size]Do you have the same result ? can we have a clue about what is returned her ?

[arnoldemu]

reading ppi control port is crazy!

I've done tests on this and my test shows that you can't rely on any specific value being returned.

It's value depends on 1) the last value written to the ppi control port (on asic ppi)
2) OR the model of 8255 used in your CPC (amstrad chose to use various 8255 models).

So where did you find this code?

Reading of a write only port can do various things:
- on type 4 crtc, it writes the value on the bus into the crtc! Yes, doing a read does a write because Amstrad chose not to decode if it was read or write!
- sometimes you get bus values, sometimes you get 255.

[arnoldemu]

EDIT: Newer notes give a strange result I need to re-check:

8255 in kc compact for example:


;;
;; kcc:
;; shows 0 for 0-&c
;; &7f for &0d and &0e
;; &40 for &0f to &1b
;; &00 for &1c
;; &40 for &1d to &2b
;; &00 for &2c
;; &40 for &2d to &3b
;; &00 for &3c
;; &40 for &3d to &4b
;; &00 for &4c
;; &40 for &4d to &5b
;; &00 for &5c
;; &40 for &5d to &6b
;; &00 for &6c
;; &40 for &6d to &7b
;; &00 for &7c
;; &40 for &7d to &7f
;; &00 for &80,&81,&82
;; &0a for &83
;; &00 for &84 to &89
;; &8a is &10
;; &8b is &1a
;; &00 for &8c to &92
;; &0a for &93
;; &00 for &94 to &99
;; &9a is &10
;; &9b is &1a
;; &00 for &9c to &a2
;; &02 for &a3
;; &00 for &a4 to &a9
;; &aa is &10
;; &ab is &12
;; &00 for &ac to  &b1
;; &b2 is &20
;; &b3 is &22
;; &00 for &b4 to  &b9
;; &ba is &20
;; &bb is &22
;; &00 for &bc to  &c1
;; &c2 is &20
;; &c3 is &22
;; &00 for &c4 to  &c9
;; &ca is &20
;; &cb is &22
;; &00 for &cc to  &d1
;; &d2 is &20
;; &d3 is &22
;; &00 for &d4 to  &d9
;; &da is &20
;; &db is &22
;; same pattern until &ff

[Lone]

I found this on "Skate wars" tape.
[attachurl=2]


You can find this with a breakpoint on &1053


Here is the disassembly code :
[attachimg=2]


Obviously, we dont want the AND A to set the Zero flag. Here what's on 86f0


86EF    01 92 F7           LD BC, &F792
86F2    ED 49               OUT (C),C
....


So, AND A setting the Z flag will just replace the LD BC, &F792 with a LD BC, &F782. Which would not set Entry A of PPI to true, and so the following keayboard test would fail.


I dont really see here what's the author just wanted to check....

[arnoldemu]

there is tape reading code near.

I do not understand what the code is doing

I will need to do more testing on cpc. Perhaps this explains some weird numbers I see when reading from this port.

[TFM]

IMHO that's a nice way to omit to scan an key which is actually not pressed.

[arnoldemu]

IMHO that's a nice way to omit to scan an key which is actually not pressed.

interesting. I will be able to confirm that with my tests.

[arnoldemu]

On Plus:

The value you read  from the PPI control port depends on the value you write to it.

If value_written<0x080 you read back 0.
if ((value_written & 0x010)==0x010) you read back 0x0ff otherwise you read back &00.

Interestingly that bit is the one that defines if port A is input or output.

if set port A is input.
if clear port A is output.

here, if set it's 0x0ff, if clear it's 0x00.

[Lone]

Really interesting, thanks for the tests.


Despite all of these, I don't see what's the point her : In some case (where 0 i sreturned), the game will not be able to see what key are pressed. Which is uncommon for a protection (and I don't see where it can assume that it's not an original game).


Maybe it's just a bug that was never found (maybe because it works in most case ?)