Some interesting (For some people) facts about ZX81
andy
challenge, I have discovered a few interesting things about our beloved
little machine.
so i had the problem where the image in fast mode is shifted to the right a
bit, after many frustrating hours of code checking and clock cycles counting
i could not quite pin down the problem still sure it was my coding at fault.
So out comes the scope and a real ZX81 issue 1 board 2C184E ULA, and found
the following :-
Hsync's and NMI pulses are 16 Clockcycles, NOT 15 as i always thought.
There are 39 clock cycles after the end of Hsync before the first 2 bits of
video is output
there are 24 clock cycles after the last video bit before the start of
Hsync.
hence 16+39+128(video bits)+24 = 207.
and now the most interesting bit that fixes the problem in the emulator.
The Vsync pulse, which is controlled by software ends when the ZX81 executes
the OUT ($FF),A instruction at memory location $277 which should take 11
clock cycles.
originally i had the vsync (in software) ending at the start of this 11
clock cycles, which with hindsight is completely wrong, so a look at the z80
technical specs shows that the /IORQ line is not active until the 2nd cycles
of the third machine cycles for this instruction (M1 op-code-fetch 4 clocks,
M2 operand-fetch 3 clocks, M3 IO-write 4 clocks [T1,T2, forced Tw, T3) so i
re-jigged the code and things improved but it was not perfect, back to the
Real ZX81 and a few frustrating minutes later (a dual timebase scope would
have nailed it in seconds) because i could not get the trace to lock on the
vsync at a high enough speed to see the /IORQ at the same time and what
should i find ?
Vsync ends on the rising edge of /IORQ of the OUT ($FE),A instruction this
was totally unexpected for me, so that means v sync actually now end on
falling edge of the last clock cycle.
Another re-jig of my code, easier than the first re-jig since i only count
clockcycles once for the in and out instructions. and all is well Slow and
Fast displays are now in the same place.
Regards Andy.
Brian Gaff
run cp/m on, and your post blew a few cobwebs off of a discussion similar to
this about slight differences in how the z80 worked from how the
manufacturer said it worked. Mostly timing things, but yes, they did affect
all sorts of stuff when one tried to emulate the hardware.
My brain hurts just reading your desscription....
Brian
--
Brian Gaff - bri...@blueyonder.co.uk
Note:- In order to reduce spam, any email without 'Brian Gaff'
in the display name may be lost.
Blind user, so no pictures please!
"andy" <an...@zx-81.co.uk> wrote in message
news:ExFUj.135$Nk5...@newsfe15.ams2...
Woodster
>Another re-jig of my code, easier than the first re-jig since i only count
>clockcycles once for the in and out instructions. and all is well Slow and
>Fast displays are now in the same place.
Cool. Now your next project is to discover where flag bits 5+3 come
from for the SCF and CCF opcodes because they certainly don't come
from the A register (on an NEC clone at least) like the docs say.
Get to it! ;)
andy
"Woodster" <woody.603176...@ntlworld.com> wrote in message
news:93p624dmu1idatq62...@4ax.com...
i'll see what i can do think i have an NEC z80 knocking round in a spectrum
somewhere, might be From MEMPTR which i have only very recently found out
about and am in the process of implementing in my emulation,
it IS very tedious making your own core emulation routine especially when
your a novice programmer like me, this is by far the most complicated thing
i have ever attempted, it sure aint pretty but once its stable-ish i'll
release a beta. I think the main reason for doing it besides i like a good
challenge was been a NOOB when it comes to 'C' i couldn;t quite get my head
round how other core emulations where working so using someone else's GPLed
core was no good to me, beside it's good fun learning 'C', and other
emulators lacked the some feature i am after such as a real time memory
explorer instead of having to either do a snapshot and open it with another
piece of software, i also wanted a debugger that shows past code as well as
upcoming code, also to show the effect of the next instruction without
actually executing it, so you get a before and after look at the registers
if you know what i mean.
Andy
>
> Get to it! ;)
andy
on a real ZX81 i have already established where the active video signal
occurs on each scan line in terms of clock cycles in relation to the end of
the Hsync pulse but i decided to break it down further and after meticulous
study am proud to present :- '' 64 uS in the life of a ZX81 Scan Line ! ''
If we call the first Clock cycle immediatly after the end of Hsync Cycle 0
(zero) this is what we get
0 very last cycle of POP DE
----------
1
2
3 RET Z
4
5
----------
6
7
8
9
10
11
12 JR $0041
13
14
15
16
17
----------
18
19
20 ED PREFIX
21
----------
22
23
24 LD R,A
25
26
----------
27
28
29 EI
30
----------
31
32
33 JP (HL)
34
----------
35
36
37 FIRST FORCED NOP
38
---------- PIXEL DATA STARTS HERE ON RISING EDGE OF CYCLE 39.
39
40
41 SECOND FORCED NOP
42
----------
.
. MORE NOPS
. AND MORE VIDEO
.
.
----------
159
160
161 THIRTY SECOND FORCED NOP
162
----------
163
164
165 HALT
166
---------- PIXEL DATA STOPS HERE ON FALLING EDGE OF CYCLE 166
167
168 CPU FAKE NOP (CPU IS HALTED)
169______ INT HAPPENS BETWEEN 169 AND 170
170
----------
171
172
173
174
175
176
177 INTERRUPT ACKNOWLEDGE
178
179
180
181
182
183
----------
184
185
186 DEC C
187
----------
188
189________HSYNC STARTS HERE BETWEEN 189 AND 190
190
191
192
193 JP NZ $0045
194
195
196
197
----------
198
199
200
201
203 POP DE
204
205
206________ HSYNC ENDS HERE BETWEEN 206 AND 0
0
----------
This information was obtained by carefull study of the M1 signal in relation
to the video signal and then matching the M1 timmings with the instructions
that should be executed during a scan line.
Regards Andy
Woodster
>
>"Woodster" <woody.603176...@ntlworld.com> wrote in message
>news:93p624dmu1idatq62...@4ax.com...
>> On Thu, 8 May 2008 17:05:54 +0100, "andy" <an...@zx-81.co.uk> wrote:
>>
>> Cool. Now your next project is to discover where flag bits 5+3 come
>> from for the SCF and CCF opcodes because they certainly don't come
>> from the A register (on an NEC clone at least) like the docs say.
>
>i'll see what i can do think i have an NEC z80 knocking round in a spectrum
>somewhere, might be From MEMPTR which i have only very recently found out
>about and am in the process of implementing in my emulation
Nope, those bits aren't from MEMPTR. They're more to do with the IR
register pair than anything else. The only thing is that there's
something else at work breaking up any evolving pattern and I can't
figure out what it is. I did think it might be the temp acc. register
but loading that with various values doesn't appear to make any
difference suggesting it plays any part.
andy
Might i ask how you are testing this ?
my preliminary tests using the following code give the expected results
:START LD A,FF
:LOOP CALL JUMP ;SETS MEMPTR TO A KNOWN VALUE
:JUMP NOP
:TEST SCF ;INSTRUCTION TO TEST
DEC A
JR NZ, LOOP
:END RET
this was run on a +3 using Hisofts monp3 and tried with 3 different CPU's
1. Mostek (c) tc8637
mk3880n-4
z80-cpu
2. zilog
z8400a ps
z80a
8412
3. nec japan 8239x5
d780c -1
each and every time results where as expected
Regards Andy.
Woodster
[b3/5 of Flags in SCF]
>Might i ask how you are testing this ?
>my preliminary tests using the following code give the expected results
Firstly I'm back to believing that b3 is a straight copy of A again!
For bit 5, if bit 5 of F (before SCF) is set and bit 5 of A, bit 5 of
F is set after the opcode. The same is not always true if bit 5 of F
is clear before the opcode executes, even if bit 5 of A is set.
I & R registers also play a part. I know changes in the I register
value change the pattern of results moreso than changes in R. I have
no idea what is actually happening with those register values though.
Furthermore, there's also something unknown playing a part too.
Whatever that is, it is affected by the thermal state of the CPU. It
affects things far more when cool, and much less so after warming.
Confused? It's been frazzling my brain for a few weeks now!
Anyhow, to get a better understanding of what happens, you need to run
a loop which runs SCF for all possible input values for both A and F,
then grab the values of F after the opcode. You'll start to see a
pattern emerging (barring the small effect of the unknown I referred
to earlier), then change I and/or R and watch yet another pattern, and
another...
Of course this might be specific to the NEC D780-C1. Maybe the Zilogs
(and even other NECs) might simply copy them from A.
Currently I've got it down to something like this:
b5 = (A & 32) & ((F OR (something to do with IR) OR (unknown)) & 32)
And that's no good to anyone!
:D
andy
have you asked the Russians ??? they seem to know everything !
in the mean time i'll rewrite some code to set the F, and IR to a known
value before hand.
i'm sure a long long time ago i read soemwhere about certain NEC PD780 had a
bug with the refresh that stopped some games working correctly on the
spectrums
i wonder if this is related to that ? wish i could find whereever i read it,
(maybe i just dreamed it).. LOL
Andy
andy
ORG 32768
DI
LD BC,0
LD DE,0
LP LD A,B
LD I,A
LD A,C
LD R,A
PUSH DE
PUSH DE
POP AF
AND A,40 ; REPLACE WITH 8 , OR 32 TO TEST JUST BIT 3 OR 5
LD H,A ; STORE PREDICTED RESULT
POP AF
SCF ;INSTRUCTION UNDER TEST
PUSH AF
LD A,H
POP HL ; GET THE RESULT INTO L
LD H,A
LD A,L
AND 40 ;REPLACE WITH 8, OR 32 TO TEST JUST BIT 3 OR 5
CP H
JR NZ,FLT
DEC DE
LD A,E
OR D
JR NZ,LP
DEC BC
LD A,C
OR B
JR NZ.LP
EI
RET ;SUCCESS ALL COMBOS OK
FLT LD A,B
LD (STR),A
LD A,C
LD (STR+1),A
LD A,D
LD (STR+2),A
LD A,E
LD (STR+3),A
EI
RET ; FAILED :(
STR DB 0,0,0,0
and guess what monp3 SUCKS !!
i can single step and it doesn;t fail
but run it and it does very early on !
on both bits 5 and 3 even when tested separatly
so next thing is to start cycling just register at a time and recording the
result 256 vals at a time
this could be a long job !
now the question is why hasn;t this been spotted before ?
Andy
andy
> On Fri, 9 May 2008 20:33:10 +0100, "andy" <an...@zx-81.co.uk> wrote:
>
> [b3/5 of Flags in SCF]
>
>>Might i ask how you are testing this ?
>>my preliminary tests using the following code give the expected results
>
> Firstly I'm back to believing that b3 is a straight copy of A again!
My tests have revealed that whilst most of the time this hold true under
certain test conditions it is not always so.
>
> For bit 5, if bit 5 of F (before SCF) is set and bit 5 of A, bit 5 of
> F is set after the opcode. The same is not always true if bit 5 of F
> is clear before the opcode executes, even if bit 5 of A is set.
>
> I & R registers also play a part. I know changes in the I register
> value change the pattern of results moreso than changes in R. I have
> no idea what is actually happening with those register values though.
> Furthermore, there's also something unknown playing a part too.
> Whatever that is, it is affected by the thermal state of the CPU. It
> affects things far more when cool, and much less so after warming.
Temparature AND indeed varying the supply voltage affects this unknown
quantity also.
in some test conditions i found the results where almost random for Bit 5
however placing a 10K pull down resistor on D5 (direct to cpu) almost made
this randomness go away but certainly has an effect. also when you have AF
set so that randomness is produced, usually when IR has nearly all of its
bits set low, then when you increase the number of bits in IR set high
(doesn't seem to matter which bits) then 3 bits high seems to be the
threshold, as when 4 bits or more are set the output is nearly alway set
(for the same AF conditions)
What can we draw from these findings ? well it seems that sometimes the
input to Bit 5 when the Flag register is modified seem to be left in some
state of limbo, (internally tristated maybe?) and depending on the loading
of other circuits within the CPU, or temparature changes, or supply voltage
changes, can affect the result.
It maybe that we can never truly emulate these bits for these instructions
Mostly i have been using NEC processor in a TS1500, after that using the
same NEC processor in issue 1 ZX81 and the results are different again !
much less random i think this is to do with the fact that zx81 data lines
are always loaded by resistors where as in the TS1500 they are buffered.
Well It's been a fun 48 hours but I've had enough now
>
> Confused? It's been frazzling my brain for a few weeks now!
YEP very !
>
> Anyhow, to get a better understanding of what happens, you need to run
> a loop which runs SCF for all possible input values for both A and F,
> then grab the values of F after the opcode. You'll start to see a
> pattern emerging (barring the small effect of the unknown I referred
> to earlier), then change I and/or R and watch yet another pattern, and
> another...
here is the code i ended up running
0001 0000
0002 0000 ;;
0003 0000 ;; Compile with "tasm -80 -b program.asm program.p"
0004 0000 ;;
0005 0000
0006 0000 #define TPORT $BF ;the port number
0007 0000
0008 0000 #define CDFLAG 16443 ;system var
0009 0000
0010 0000 #define DEBOUNCE 16423 ;systen var
0011 0000
0012 0000 #define TEST_BREAK $0F46
0013 0000
0014 0000 #define DB .byte
0015 0000 #define db .byte ; TASM cross-assembler definitions
0016 0000 #define dw .word
0017 0000 #define DW .word
0018 0000 #define ds .block
0019 0000 #define org .org
0020 0000 #define end .end
0021 0000
0022 4009 org $4009
0023 4009
0024 4009 ;= System variables
============================================
0025 4009
0026 4009 00 db 0 ;VERSN
0027 400A 00 00 dw 0 ;E_PPC
0028 400C FD 46 dw dfile ;D_FILE
0029 400E FE 46 dw dfile+1 ;DF_CC
0030 4010 16 47 dw var ;VARS
0031 4012 00 00 dw 0 ;DEST
0032 4014 17 47 dw var+1 ;E_LINE
0033 4016 16 47 dw last-1 ;CH_ADD
0034 4018 00 00 dw 0 ;X_PTR
0035 401A 17 47 dw last ;STKBOT
0036 401C 17 47 dw last ;STKEND
0037 401E 00 db 0 ;BERG
0038 401F 5D 40 dw membot ;MEM
0039 4021 00 db 0 ;not used
0040 4022 02 db 2 ;DF_SZ
0041 4023 01 00 dw 1 ;S_TOP
0042 4025 FF FF FF db $FF,$FF,$FF ;LAST_K
0043 4028 37 db 55 ;MARGIN
0044 4029 FD 46 dw dfile ;NXTLIN
0045 402B 00 00 dw 0 ;OLDPPC
0046 402D 00 db 0 ;FLAGX
0047 402E 00 00 dw 0 ;STRLEN
0048 4030 8D 0C dw $0C8D ;T_ADDR
0049 4032 00 00 dw 0 ;SEED
0050 4034 FF FF dw $FFFF ;FRAMES
0051 4036 00 00 db 0,0 ;COORDS
0052 4038 BC db $BC ;PR_CC
0053 4039 21 18 db 33,24 ;S_POSN
0054 403B 40 db 01000000B ;CDFLAG
0055 403C ds 33 ;Print buffer
0056 405D membot:
0057 405D ds 30 ;Calculator´s memory area
0058 407B ds 2 ;not used
0059 407D
0060 407D ;= First BASIC line, asm code
==================================
0061 407D
0062 407D line0:
0063 407D 00 00 db 0,0
0064 407F 7C 06 dw dfile-$-2
0065 4081 EA db $ea ; REM
0066 4082
0067 4082 ;====================================
0068 4082 ; MY CODE STARTS
0069 4082
0070 4082 ; REMEBER TO RUN IN FAST MODE !
0071 4082
0072 4082 START
0073 4082 F3 DI
0074 4083 21 FC 40 LD HL,RESULT
0075 4086 3A F7 40 LP2 LD A,(IVAL)
0076 4089 ED 47 LD I,A
0077 408B 3A F8 40 LD A,(FVAL)
0078 408E 4F LD C,A
0079 408F 06 00 LD B,0 ;THIS IS THE INITIAL TEST VALUE FOR A
0080 4091
0081 4091 ; LD HL,RESULT
0082 4091
0083 4091
0084 4091
0085 4091 C5 LOOP PUSH BC ;TEST VALUE FOR AF ON STACK
0086 4092 78 LD A,B
0087 4093
chnage the following code to get your predicted value in
the D register (Don't use BC or HL)
0088 4093 PRE ;;POP AF ;ONLY 1 VAL STILL ON STACK
0089 4093 B1 OR C ;A OR F (SO EVEN IF BITS 3 AND 5 ARE
RESET (IN A) BUT ALREADY SET IN F)
0090 4094 E6 28 AND $28 ;A NOWHAS ONLY BITS 5 AND 3
0091 4096 57 LD D,A ;STORE IN D
0092 4097
load R to a known value at each itteration (also sets
MEMPTR)
0093 4097 3A F9 40 LD A,(RVAL)
0094 409A ED 4F LD R,A ;R+1
0095 409C F1 POP AF ;TEST VALUE IN AF, R+ 2
0096 409D
0097 409D 37 TEST SCF ;INSTRUCTION TO TEST (flags before or
after R incremented ? (R+3 or maybe +4)
next bit moves some bytes around without using BC or HL
0098 409E 7A LD A,D ;PREDICTED FLAG BITS 5 + 3 IN A, WAS IN D
0099 409F
0100 409F F5 PUSH AF ;SAVE FLAGS WE DON;T CARE ABOUT A NOW
0101 40A0 D1 POP DE ;GET FLAGS
0102 40A1 ; AT THID POINT PRE IS IN A, FLAGS IN E
0103 40A1 57 LD D,A ; PRE IN D AGAIN
0104 40A2 7B LD A,E ;FLAGS IN A
0105 40A3 E6 28 AND $28 ;ONLY KEEP BITS 5 + 3
0106 40A5
0107 40A5 BA CP D ;COMPARE WITH D
0108 40A6 20 25 JR NZ,FAIL ; NOT AS EXPECTED !
0109 40A8
0110 40A8
0111 40A8 04 LP3 INC B
0112 40A9 C2 91 40 JP NZ,LOOP ;INNER LOOP
0113 40AC
0114 40AC 3A F8 40 LD A,(FVAL)
0115 40AF 3C INC A
0116 40B0 32 F8 40 LD (FVAL),A
0117 40B3 C2 86 40 JP NZ,LP2 ;SECOND LEVEL
0118 40B6
0119 40B6 3A F7 40 LD A,(IVAL)
0120 40B9 3C INC A
0121 40BA 32 F7 40 LD (IVAL),A
0122 40BD C2 86 40 JP NZ,LP2 ;THIRD LEVEL
0129 40C0 SUCCESS
0130 40C0 3E 1E LD A,$1E
0131 40C2 ED 47 LD I,A ;RESTORE I REGISTER
0132 40C4 21 00 00 LD HL,0
0133 40C7 E5 PUSH HL
0134 40C8 C1 POP BC
0135 40C9 22 FA 40 LD (SUC),HL
0136 40CC C9 RET
0137 40CD
0138 40CD FAIL ; HERE WE SAVE THE VALUES (6 BYTES)
RETRIEVED LATER ON IN BASIC PROGRAM
0139 40CD ; BC IS THE AF VALUE
0140 40CD ; IVAL AND RVAL ARE IN MEMORY
0141 40CD 77 LD (HL),A ;ACTUAL
0142 40CE 23 INC HL
0143 40CF 72 LD (HL),D ;PREDICTED
0144 40D0 23 INC HL
0145 40D1 70 LD (HL),B
0146 40D2 23 INC HL
0147 40D3 71 LD (HL),C
0148 40D4 23 INC HL
0149 40D5 3A F7 40 LD A,(IVAL)
0150 40D8 77 LD (HL),A
0151 40D9 23 INC HL
0152 40DA 3A F9 40 LD A,(RVAL)
0153 40DD 77 LD (HL),A
0154 40DE 23 INC HL
0155 40DF 11 FC 46 LD DE,RESEND ;END OF THE RESULT MEMORY BLOCK
0156 40E2 A7 AND A ;CLEAR CARRY
0157 40E3 E5 PUSH HL
0158 40E4 ED 52 SBC HL,DE ;HL REACHED THE END YET ?
0159 40E6 E1 POP HL
0160 40E7 C2 A8 40 JP NZ,LP3 ;NO CARRY ON
0161 40EA
0162 40EA 3E 1E LD A,$1E
0163 40EC ED 47 LD I,A
0164 40EE 21 FF FF LD HL,65535
0165 40F1 E5 PUSH HL
0166 40F2 C1 POP BC
0167 40F3 22 FA 40 LD (SUC),HL
0168 40F6 C9 RET
0169 40F7
0170 40F7
0171 40F7
0172 40F7 00 IVAL DB 0
0173 40F8 00 FVAL DB 0
0174 40F9 00 RVAL DB 0
0175 40FA
0176 40FA
0177 40FA 00 00 SUC DW 0
0178 40FC
0179 40FC RESULT .block 1536
0180 46FC RESEND
0181 46FC
0182 46FC
0183 46FC ; MY CODE ENDS
0184 46FC ;====================================
0185 46FC
0186 46FC 76 db $76 ;N/L
0187 46FD
0188 46FD ;- Display
file --------------------------------------------
0189 46FD
0190 46FD dfile:
0191 46FD 76 db $76
0192 46FE 767676767676 db $76,$76,$76,$76,$76,$76,$76,$76
0192 4704 7676
0193 4706 767676767676 db $76,$76,$76,$76,$76,$76,$76,$76
0193 470C 7676
0194 470E 767676767676 db $76,$76,$76,$76,$76,$76,$76,$76
0194 4714 7676
0195 4716
0196 4716 ;-
BASIC-Variables ----------------------------------------
0197 4716
0198 4716 var:
0199 4716 80 db $80
0200 4717
0201 4717 ;- End of program area ----------------------------
0202 4717
0203 4717 last:
0204 4717
0205 4717 end tasm: Number of errors = 0
>
> Of course this might be specific to the NEC D780-C1. Maybe the Zilogs
> (and even other NECs) might simply copy them from A.
>
> Currently I've got it down to something like this:
> b5 = (A & 32) & ((F OR (something to do with IR) OR (unknown)) & 32)
>
> And that's no good to anyone!
>
> :D
Regards Andy
Woodster
[snip code]
>i can single step and it doesn;t fail
>but run it and it does very early on !
>on both bits 5 and 3 even when tested separatly
>
>so next thing is to start cycling just register at a time and recording the
>result 256 vals at a time
>this could be a long job !
And, for me at least, running the code with the same register values
repeatedly can still give different results due to this unknown part
of the equation.
>now the question is why hasn;t this been spotted before ?
Stuart Brady first discovered it and mentioned it in the tech wiki:
<http://scratchpad.wikia.com/wiki/Z80>
The results on the Zilog chip were different to those from the NEC but
it'd be interesting to see this retested on the Zilog with different
I/R register values to see if there's still some oddities happening in
those CPUs.
One other thing on the NEC is that if you pair groups of CCF/SCF (did
I mention CCF behaves the same?), then bits 5+3 are simply copies from
A, AFAICT.
My latest z80tests code uses CCF/SCF opcodes for the SCF test, and
SCF/CCF for the CCF test and gives the expected result.
<http://homepage.ntlworld.com/mark.woodmass/z80tests.tap>
It appears that inserting any opcode between these pair of opcodes
that alter the flags in any way brings back the strange behaviour
again.
Woodster
>Temparature AND indeed varying the supply voltage affects this unknown
>quantity also.
>in some test conditions i found the results where almost random for Bit 5
>however placing a 10K pull down resistor on D5 (direct to cpu) almost made
>this randomness go away but certainly has an effect. also when you have AF
>set so that randomness is produced, usually when IR has nearly all of its
>bits set low, then when you increase the number of bits in IR set high
>(doesn't seem to matter which bits) then 3 bits high seems to be the
>threshold, as when 4 bits or more are set the output is nearly alway set
>(for the same AF conditions)
>
>What can we draw from these findings ? well it seems that sometimes the
>input to Bit 5 when the Flag register is modified seem to be left in some
>state of limbo, (internally tristated maybe?) and depending on the loading
>of other circuits within the CPU, or temparature changes, or supply voltage
>changes, can affect the result.
>
>It maybe that we can never truly emulate these bits for these instructions
>
>Mostly i have been using NEC processor in a TS1500, after that using the
>same NEC processor in issue 1 ZX81 and the results are different again !
>much less random i think this is to do with the fact that zx81 data lines
>are always loaded by resistors where as in the TS1500 they are buffered.
>
>Well It's been a fun 48 hours but I've had enough now
Well, as long as you had fun :)
Your discoveries have, of course, helped me decide to leave my current
5+3 flags behaviour as-is!
Cheers for looking at this.