Houston, we have an image!

Any discussions related to the creation of new hardware or software for the ZX80 or ZX81
User avatar
PokeMon
Posts: 2264
Joined: Sat Sep 17, 2011 6:48 pm

Re: Houston, we have an image!

Post by PokeMon »

RetroTechie wrote:
PokeMon wrote:The counter can be reset / preloaded only in full size not partly. :shock:
No you're wrong, it's perfectly possible to reset a counter partly.
Now you are nitpicking, your last post wasn't helpful at all. :shock:
As I told before, my first preload pulse was at least 50ns, my actual preload pulse is 308ns (one clock period).
We are not talking about "spikes" ... :roll:
User avatar
PokeMon
Posts: 2264
Joined: Sat Sep 17, 2011 6:48 pm

Re: Houston, we have an image!

Post by PokeMon »

So I found the problem, depending on the ZX80 schematics / construction.

When enabling/disabling NMI's and automatic horizontal syncs, the flipflops for hsync are creating (possible accidently) additional sync pulses.
In the picture you can see the "mixed" syncs with syncs from ZX80 board and syncs from NMI generator in the above signal and the on/off switch of NMI in the signal below.
At each NMI generator switch (on and off) there is an unordinary additional sync pulse.
IMG_6322k.JPG
IMG_6322k.JPG (61.49 KiB) Viewed 3639 times

I managed to suppress these pulses and the screen looks a bit better now.

But I think I have also problems with vertical sync in SLOW mode as the two half pictures are not correct together.
In the last line you can see the cursor or the message with the lower part (about 6 scanlines) first and the upper part (about 2 scanlines) after.

Any idea what that exactly is and how to find out / solve this problem ?
Maybe instructions what to measure exactly.
Unfortunately I don't have a counter item here, so very difficult to count the scanlines for me ... :?

Screen after loading:
IMG_6323k.JPG
IMG_6323k.JPG (71.09 KiB) Viewed 3639 times

Listing of program:
IMG_6324k.JPG
IMG_6324k.JPG (95.38 KiB) Viewed 3639 times
User avatar
PokeMon
Posts: 2264
Joined: Sat Sep 17, 2011 6:48 pm

NMI generator - some comments to Grant Searle's solution

Post by PokeMon »

Well it took me a long time to work on the NMI generator board.
I thought first it can not work or there have to be different behaviours but after I read the article from Martin, who build up these boards and assured they are working properly I tried to give it a second chance. Measured all signals. But same problems before. Then read again (more carefully) how he "integrated" it into a ZX80 board and I got it. Oh my dear ! :roll:

But there are some more problems with my board / solution which need more components, more space, will be more expensive with a doubtful value. So I decided against realising it this way by the second time.

First a few words to Grant Searle's implementation. It's a bit like crunching a ZX80 board. Don't know if someone really would upgrade an exisiting (original !) ZX80 with that stuff, cut wires, solder a dozen of cable wires. So I looked at the schematics of Grant
http://searle.hostei.com/grant/zx80/zx80nmi.html
and took the signals needed (listed) onto a 16 pin connector on my ZX80Core board. As I want to remix sync signals and video signal on my board, I decided against it because I thought I did not need a disabling of the sync signals after checking it and don't neet disabling video logic. Will come back later to this.

What I missed (and this should really described better on the page) is that the SYNC OUT is not just a SYNC OUT but has to either cut a connection from IC19 or remove IC19. This is described in section "connecting" NMI generator to the ZX80. Now it comes clear to me, why Grant and Martin don't have problems with wrong scanline counter. Couldn't this described in more detail and not just to name the signal SYNC OUT but show the "implementation" like for sync logic disable and video logic disable. :shock:

I now could save the problem while updating the connector but there are still more problems which are partly solved, partly not and there is too much hardware necessary for this gimmick. I will replace it better with the video deluxe module which need only a video signal and power, maybe divorced sync and video components make it little bit easier (which could be adapted with trimmers like in the ZX81CCB).

Take a look at the schematics:
zx80_sync1.jpg
zx80_sync1.jpg (29.42 KiB) Viewed 3596 times
1. There have been horizontal sync disturbing pulses which are created from IC 19.
The problem is, every Low pulse on /IORQ makes a Preset at IC18 which creates a sync pulse two M1 cycles later. This take effect on every IN, every OUT and every INT ACK (interrupt acknowlede cycle). I took two solutions for myself, first disabling the sync pulses during the NMI periods (NMI on). But this is not enough as the NMI off instruction creates a sync pulse as well which is delayed two M1 cycles - so will occur when NMI is already off! So a second filter is needed, suppressing all sync pulses created from an OUT instruction with a R/C filter.

This is not needed when the SYNC IN is not used at all. But I need this signal for the vertical sync. In fact as all is synchronously running with the counter I simply mixed the NMI pulses and the HSYNC pulses (let's say all unfiltered sync pulses) from the ZX80 (IC19).

2. Every (disturbing and regularly) horizontal Sync caused a "+1" for the scanline counter. That was my problem with the crunched lines. This is more complex and I will give some further comments to it at the end. So as Grant advices to bend out pin 1 of IC21 (which is harmless described as simple SYNC OUT), this will not change the scanline counter or let's better say in a way that it is "0" when picture is displayed. This was a long part working on with ZX81 ROM listing and my oscilloscope. It could be easily solved by either software change in ROM or by resetting or "triggering" the counter regularly. Need some pins (1 or 2/3) on my connector to do this.

3. There was a distortion always in the first line of screen of about 3 to 4 pixels. This comes from different sync signal start when created from the 393 counter and created from the INT ACK cycle with IC19. On Grant's solution this is not a problem as he did not use the horizontal syncs at all but only the syncs created form the 393 counter. On the second screen line this effect disappears as TV synchronises to the new point of time (beginning of scanline). In fact the creation of the sync should be moved by 4 clock cycles to the left (on counter=12 instead of 16) but I decided more simpler to use a variable R/C combination and a trimmer to delay the HSYNC created from ZX80. This way the picture (1st line) can be moved half pixel wise as well. :mrgreen:

4. The counter problem. This doesn't appear on Grant's solution as he cutted the connection of pin 1 IC21 and bend this to the regularly sync.
There is also a difference between SLOW and FAST mode display and if a program is running or not and how long the execution takes. This is really complex and one of the main reasons decided me against realizing it this way.

There are 2 variants of picture generation in the ZX81 ROM.
a) FAST mode display
This is done with the VSYNC (reading keyboard), end of VSYNC by OUT ($FF),A. The NMI lines are created by software (execution of pseudo video code creating sync pulses) and there is one special line for SYNC the video output with the NMI/WAIT hardware (T-state synchronisation). The end of the VSYNC pulse does not create any additional sync pulse due to the "Clear state", pin 1 IC 19. The execution of the 55 NMI line plus 1 T-State-SYNC line create always HSYNC pulses and will trigger the counter. So after 56 counts the 3 bit counter is 0 (7x8=56). This is by the way not just a coincidence why the MARGIN values are choosen as 55 for UK(european) version and 31 for US version (4x8=32).

b) SLOW mode display
Here the problem begins and the behaviour depends on wether it is ba) in input mode or bb) in running programs mode.

ba) SLOW mode with input mode (K cursor)
The screen starts same way with VSYNC pulse first, created with keyboad input, end of VSYNC with OUT ($FF),A. Then enable NMI generator with OUT ($FE),A and after 55 line disable NMI generator with OUT ($FD),A. Then the T-state-SYNC line is executed. Then the pictures begins.
So the scanline counter is reset after VSYNC pulse, the OUT ($FF),A does not trigger the counter as described above and the two other OUT instructions and the T-state-SYNC line will trigger the counter and set it's value to 3 when the picture display begins. Too bad. :?

bb) SLOW mode with running mode
This is more complex and depends also on the program itself. Lets look at the BASIC interpreter. This will execute line by line and after each line it checks wether BREAK key pressed or not with IN A,($FE). This will by the way start a "VSYNC pulse" of variable length (depending on the point of time in execution) in the NMI on phase. The NMI off will reset this additional VSYNC with no counter triggering. The T-State SYNC line will trigger it to 1 but this will normally appear as valid picture with normal characters (first scanline always empty). Only if you use reverse characters you can see this effect.

But if this happen appears on the time needed for program execution. Long running USR programs or maybe complicate calculations in a BASIC line can be produce this effect with scanline counter set to 3 as well, resulting in a crunched screen.


Last but not least I have still a problem with a short black line appearing on chars 5 to 10 in the very first line of the screen, which is the T-State SYNC visible on screen. This is visible only under condition bb) when enough time to generate additional VSYNC pulses. I am not motivated to investigate this in more detail, just as hint for someone.


One more comment to Grant's video logic disable:

This is mostly not needed at all as pixels will be generated only when A15 is high. This is in fact video picture display. During the NMI's there is no execution and (normally) no access to data with A15 high. It could maybe produce some visible pixel information when we have a special ZX80 with more than 16k RAM. So usually this gate is surely obsolete.
Last edited by PokeMon on Fri Jul 05, 2013 6:07 pm, edited 4 times in total.
User avatar
PokeMon
Posts: 2264
Joined: Sat Sep 17, 2011 6:48 pm

ZX81 TV picture display in (more) detail

Post by PokeMon »

Ever asked how the vertical and horizontal sync are realized in detail and how it matches to video standard ?
This is not very exactly explained in the ZX81 ROM listing.

Lets start with the VSYNC pulse. It's duration is more or less 6 horizontal lines, about 384 microseconds. But for now we count only lines.
So it's now 6.

Code: Select all

0277: [0277] D3 FF                              OUT     ($FF),A         ; end the TV frame synchronization pulse.
                                        
0279: [0279] 2A 0C 40                           LD      HL,($400C)      ; (12) set HL to the Display File from D_FILE
027C: [027C] CB FC                              SET     7,H             ; (8) set bit 15 to address the echo display.
                                        
027E: [027E] CD 92 02                           CALL    L0292           ; (17) routine DISPLAY-3 displays the top set 
                                                                        ; of blank lines.
VSYNC is ended with OUT ($FF),A and next the top margin lines are printed. 55 for UK version.
So the line counter is now at 61.

Code: Select all

0074: [0074] 2A 0C 40                           LD      HL,($400C)      ; (16) fetch start of Display File from D_FILE
                                                                        ;      points to the HALT at beginning.
0077: [0077] CB FC                              SET     7,H             ; (8) point to upper 32K 'echo display file'
                                        
0079: [0079] 76                                 HALT                    ; (1) HALT synchronizes with NMI.  

007A: [007A] D3 FD                              OUT     ($FD),A         ; (11) Stop the NMI generator.
                                        
007C: [007C] DD E9                              JP      (IX)            ; (8) forward to L0281 (after top) or L028F
After 55 margin lines the T-State SYNC is initiated from the NMI routine as well, after continue with picture generation.
So line counter is now at 62.

Code: Select all

0281: [0281] ED 5F                      L0281:  LD      A,R             ; (9)  Harmless Nonsensical Timing or something
                                                                        ;      very clever?
0283: [0283] 01 01 19                           LD      BC,$1901        ; (10) 25 lines, 1 scanline in first.
0286: [0286] 3E F5                              LD      A,$F5           ; (7)  This value will be loaded into R and 
                                                                        ; ensures that the cycle starts at the right 
                                                                        ; part of the display  - after 32nd character 
                                                                        ; position.
                                        
0288: [0288] CD B5 02                           CALL    L02B5           ; (17) routine DISPLAY-5 completes the current 
                                                                        ; blank line and then generates the display of 
                                                                        ; the live picture using INT interrupts
                                                                        ; The final interrupt returns to the next 
                                                                        ; address.
So the video generation is continued. The picture normally contains 24 rows with 8 scanlines per row, so 192 lines in TV world. But it completes the current line and BC register is loaded with one more scanline ($1901 instead of $1808). So in fact 193 lines are displayed ! And it ends with an additional INT ACK because the routine at $0038 checks end of display AFTER displaying 193 lines and the first margin line appears with the next NMI which extends 193,1 lines to 194. And by the way, thats why an collapsed DFILE consists of 25 NEWLINE instead of 24 or an expanded DFILE starts with a NEWLINE character as well.
Line counter is now at 256.

Code: Select all

028B: [028B] 2B                         L028B:  DEC     HL              ; point HL to the last NEWLINE/HALT.
                                        
028C: [028C] CD 92 02                           CALL    L0292           ; routine DISPLAY-3 displays the bottom set of
                                                                        ; blank lines.
                                        
                                        ; ---
                                        
                                        ;; R-IX-2
028F: [028F] C3 29 02                   L028F:  JP      L0229           ; JUMP back to DISPLAY-1
Now again 55 (bottom margin) lines are generated plus again 1 T-State SYNC line (not really needed but used).
So line counter is now at 312.
After a new FRAME begins with VSYNC.

Well in fact the TV display is divided a bit more complex. Normally the picture has 25 full frames which are devided into two half frames, called odd and even frame. The position of the frames are coded with more complex VSYNC pulses, normally it is not just one longe pulse like from the ZX80 or ZX81. So the standard give 25 pictures interlaced with 625 lines, divided into two frames with 312,5 lines. This is a difference but the TV's are tolerant enough to take the signal, resulting in a little bit faster frame rate. The deviation is 0,16%.
The duration of 1 line is 64us (microseconds) which matches 1 second after 25 "full" frames: 64us*625*25 = 1 second

Now lets take a look at the horizontal lines.
This is even not very well explained in the ROMs how 1 line matches exactly 64us (207 clock cycles).
In fact it is only 63,7 us and exactly one clock cycle is missing. 208 clock cycles would give exactly 64us at 3.25 MHz speed. So this is a deviation of 0,5% which can be handled by the TVs but I ask myself if it wouldn't have been possible by Sinclair to realize a 208 clock cycle display.

But let's start with the INT ($38), during active picture generation (the 192 lines, 24 rows).

Code: Select all

0038: [0038] 0D                         L0038:  DEC     C               ; (4)  decrement C - the scan line counter.
0039: [0039] C2 45 00                           JP      NZ,L0045        ; (10/10) JUMP forward if not zero to SCAN-LINE
                                        
003C: [003C] E1                                 POP     HL              ; (10) point to start of next row in display 
                                                                        ;      file.
                                        
003D: [003D] 05                                 DEC     B               ; (4)  decrement the row counter. (4)
003E: [003E] C8                                 RET     Z               ; (11/5) return when picture complete to L028B
                                                                        ;      with interrupts disabled.
                                        
003F: [003F] CB D9                              SET     3,C             ; (8)  Load the scan line counter with eight.  
                                                                        ;      Note. LD C,$08 is 7 clock cycles which 
                                                                        ;      is way too fast.
                                        
                                        ; ->
                                        
                                        ;; WAIT-INT
0041: [0041] ED 4F                      L0041:  LD      R,A             ; (9) Load R with initial rising value $DD.
                                        
0043: [0043] FB                                 EI                      ; (4) Enable Interrupts.  [ R is now $DE ].
                                        
0044: [0044] E9                                 JP      (HL)            ; (4) jump to the echo display file in upper
                                                                        ;     memory and execute characters $00 - $3F 
                                                                        ;     as NOP instructions.  The video hardware 
                                                                        ;     is able to read these characters and, 
                                                                        ;     with the I register is able to convert 
                                                                        ;     the character bitmaps in this ROM into a 
                                                                        ;     line of bytes. Eventually the NEWLINE/HALT
                                                                        ;     will be encountered before R reaches $FF. 
                                                                        ;     It is however the transition from $FF to 
                                                                        ;     $80 that triggers the next interrupt.
                                                                        ;     [ The Refresh register is now $DF ]
                                        
                                        ; ---
                                        
                                        ;; SCAN-LINE
0045: [0045] D1                         L0045:  POP     DE              ; (10) discard the address after NEWLINE as the 
                                                                        ;      same text line has to be done again
                                                                        ;      eight times. 
                                        
0046: [0046] C8                                 RET     Z               ; (5)  Harmless Nonsensical Timing.
                                                                        ;      (condition never met)
                                        
0047: [0047] 18 F8                              JR      L0041           ; (12) back to WAIT-INT
It takes 58 cycles after INT ACK to start with video code execution. R Register is $DE (not $DF like stated) and interrupt occurs when R Register is 00 !.
So the 32 characters are executed first. After 32 characters R is still $FE so the following HALT is executed anyway and an additional NOP !
So it is in fact 33 characters which are executed plus one additional NOP caused from the HALT instruction.
After the NOP the interrupt acknowledge take place.

Code: Select all

                                        ;; WAIT-INT
0041: [0041] ED 4F                      L0041:  LD      R,A             ; (9) Load R with initial rising value $DD.
                                        
0043: [0043] FB                                 EI                      ; (4) Enable Interrupts.  [ R is now $DE ].
                                        
0044: [0044] E9                                 JP      (HL)            ; (4) jump to the echo display file in upper
                                                                        ;     memory and execute characters $00 - $3F 
                                                                        ;     as NOP instructions.  The video hardware 
                                                                        ;     is able to read these characters and, 
                                                                        ;     with the I register is able to convert 
                                                                        ;     the character bitmaps in this ROM into a 
                                                                        ;     line of bytes. Eventually the NEWLINE/HALT
                                                                        ;     will be encountered before R reaches $FF. 
                                                                        ;     It is however the transition from $FF to 
                                                                        ;     $80 that triggers the next interrupt.
                                                                        ;     [ The Refresh register is now $DF ]
So the comment in line 0043 is quite imprecise. R is not $DE in fact it is $DD and incremented before the next refrehs begins (probably R register is incremented or loaded with LD R,A command during the (following) M1 cycle).

So we have now 34 characters to execute (32 chars + HALT/NEWLINE + NOP) = 34*4=136 cycles.
So 58 cycles to start up, all in all now 194 cycles.
An interrupt acknowlede is following, this is an M1 cycle with two additional wait states, so 6 cycles instead of 4 cycles.
Now we have exactly 200 cycles.

What now happens depends a bit on the interrupt mode, we are using IM1 which is exactly a shortcut to RST $38.
A restart instruction is stated with 11 cycles while it is overlapping the INT ACK cycle. In fact the next M1 cycle starts 7 clock cycles after the INT ACK.

So we have additional 7 clock cycles after INT ACK which include 2 normal write cycles (writing PC to stack).
Don't know what the hell the CPU does in the 1 remaining additional clock cycle as there are enough cycles in the INT ACK to load the PC register. Maybe a small break before the exhausting and urgent INT service routine. :roll: :mrgreen:
User avatar
siggi
Posts: 988
Joined: Thu May 08, 2008 9:30 am
Location: Wetterau, Germany
Contact:

Re: ZX81 TV picture display in (more) detail

Post by siggi »

PokeMon wrote: So we have additional 7 clock cycles after INT ACK which include 2 normal write cycles (writing PC to stack).
Don't know what the hell the CPU does in the 1 remaining additional clock cycle as there are enough cycles in the INT ACK to load the PC register. Maybe a small break before the exhausting and urgent INT service routine. :roll: :mrgreen:
No. The Z80 datasheet says:

"Interrupt Request/Acknowledge Cycle
Figure 9 illustrates the timing associated with an interrupt cycle. The CPU
samples the interrupt signal (INT) with the rising edge of the last clock at the
end of any instruction. The signal is not accepted if the internal CPU
software controlled interrupt enable flip-flop is not set or if the BUSREQ
signal is active. When the signal is accepted, a special M1 cycle is
generated. During this special M1 cycle, the IORQ signal becomes active
(instead of the normal MREQ) to indicate that the interrupting device can
place an 8-bit vector on the data bus. Two wait states are automatically
added to this cycle. These states are added so that a ripple priority interrupt
scheme can be easily implemented. The two wait states allow sufficient time
for the ripple signals to stabilize and identify which
I/O device must insert the response vector.
Refer to Chapter 6 for details on
how the interrupt response vector is utilized by the CPU.
"
INT-ACK.jpg
INT-ACK.jpg (71.76 KiB) Viewed 3558 times
HTH Siggi
My ZX81 web-server: online since 2007, running since dec. 2020 using ZeddyNet hardware
http://zx81.ddns.net/ZxTeaM
User avatar
PokeMon
Posts: 2264
Joined: Sat Sep 17, 2011 6:48 pm

Re: Houston, we have an image!

Post by PokeMon »

Yes and now what ?
I described nothing else and there is no contradiction to my post.

The INT ACK is a special M1 cycle with /IORQ instead of /MREQ and has 2 wait states and a refresh cycle and takes 6 clock cycles.
So what NO ?
Or what do you want to tell the community exactly ? :roll:
User avatar
Andy Rea
Posts: 1606
Joined: Fri May 09, 2008 2:48 pm
Location: Planet Earth
Contact:

Re: Houston, we have an image!

Post by Andy Rea »

as i understood it, the interrupt acknowledge is just like a normal M1 fetch with 2 additional (or more should the device requesting the interrupt hold the wait line even longer) and the Vector present on the data lines at the end of the waits is loaded to the low byte of PC and I is transferred to the high byte of PC, and for IM1 the above action still takes place but the data bus is ignored and PC is loaded with $0038.... My guess is it was done that was to re-use parts of the interrupt circuitry and thus reducing complexity of the Z80 design.

Regards
what's that Smell.... smells like fresh flux and solder fumes...
User avatar
PokeMon
Posts: 2264
Joined: Sat Sep 17, 2011 6:48 pm

Re: Houston, we have an image!

Post by PokeMon »

Yes exactly, nothing else as I described before. ;)
The IM1 is a special IM0 with predefined (fixed) instruction byte RST $38.
Mode 1
When this mode is selected by the programmer, the CPU responds to an
interrupt by executing a restart to location 0038H. Thus, the response is
identical to that for a non-maskable interrupt except that the call location is
0038H instead of 0066H. The number of cycles required to complete the
restart instruction is two more than normal due to the two added wait states.
And for IM0 note this statement:
The number of clock cycles necessary to execute this instruction is two
more than the normal number for the instruction.
This is due to the two added wait states for the INT ACK cycle which is in fact a special M1 cycle. In IM1 it is the instruction RST $38 which take 11 cycles normally or 13 cycles when executed as following an interrupt and where the first 6 cycles are already the INT ACK cycle as a specialized M1 cycle.
User avatar
siggi
Posts: 988
Joined: Thu May 08, 2008 9:30 am
Location: Wetterau, Germany
Contact:

Re: Houston, we have an image!

Post by siggi »

Andy Rea wrote:as i understood it, the interrupt acknowledge is just like a normal M1 fetch with 2 additional (or more should the device requesting the interrupt hold the wait line even longer) and the Vector present on the data lines at the end of the waits is loaded to the low byte of PC and I is transferred to the high byte of PC,
No, the vector is not loaded to PC, because it is the pointer to an address (maybe in a table) holding the address to be loaded into PC. Thus something like that is done during IM2 int-ack and processing (IV should be the "interrupt vector register")
/* I is already set by LD I,A before and points to the address table */
ld V, (vector from device)
call (IV)

So there are 2 more memory read cycles necessary to fetch the address of the interrupt routine from a table in memory using IV (which might appear as wait-states in other interrupt modes)

Siggi
My ZX81 web-server: online since 2007, running since dec. 2020 using ZeddyNet hardware
http://zx81.ddns.net/ZxTeaM
User avatar
PokeMon
Posts: 2264
Joined: Sat Sep 17, 2011 6:48 pm

Re: Houston, we have an image!

Post by PokeMon »

siggi wrote: No, the vector is not loaded to PC, because it is the pointer to an address (maybe in a table) holding the address to be loaded into PC. Thus something like that is done during IM2 int-ack and processing (IV should be the "interrupt vector register")
/* I is already set by LD I,A before and points to the address table */
ld V, (vector from device)
call (IV)
This information is correct. It is a little bit like the x86 processors interrupt table on page 0 which allows 256 ISRs choosen from an 8 bit vector (which is multiplied by 4). This is valid for the real mode (DOS). The Z80 concept is a bit more flexible as it is not restricted to page 0, the table can be anywhere in the memory area (I register points to the start of table). The Z80 supports only the upper 7 bits of the vector, the bit 0 is ignored and set to 0. The address in the table will be then used to continue with the ISR. So the Z80 supports up to 128 interrupt vectors in IM2. In the protected mode, the x86 supports as well a IDT (interrupt description table) which can be anywhere in memory and simply switched for different tasks.


siggi wrote: So there are 2 more memory read cycles necessary to fetch the address of the interrupt routine from a table in memory using IV (which might appear as wait-states in other interrupt modes)
Here you are wrong in interpreting IM2. First the vector is fetched at the end (!) of the last wait state, second two clock cycles are definetly not enough time to fetch a 16 bit address from memory (2 full read cylces are necessart for the lower and upper part of the address). You posted the picture yourself above. ;) The reason for adding two wait states is to allow to implement a daisy chain of interrupts / interrupt controller for more complex systems. In my eyes this is not really needed but arbitrary from the developers.

Image


In fact the IM2 has an execution time of 19 cycles, which is 6 cycles for the INT ACK, one cycle small break as well :mrgreen: and then 2 memory write cylces to save the program counter und 2 memory read cycles to read the new address for the program counter. In fact it isn't stated in detail if the INT ACK cycle is 7 cycles long or maybe 6 cycles followed by a intermediate cycle (small break :mrgreen: ). I myself didn't measure out if the refresh cycle is 3 clock cycles long in this special case, unfortunately the timing diagram is not complete in this detail. Maybe someone can investigate this next time to have more clarity in this point. ;)

Here the statement in the user manual UM008005-0205.
When the interrupting device supplies the lower portion of the pointer, the
CPU automatically pushes the program counter onto the stack, obtains the
starting address from the table, and performs a jump to this address. This
mode of response requires 19 clock periods to complete (seven to fetch the
lower eight bits from the interrupting device, six to save the program
counter, and six to obtain the jump address).
The Z80 peripheral devices include a daisy-chain priority interrupt structure
that automatically supplies the programmed vector to the CPU during
interrupt acknowledge. Refer to the Z80 CPU Peripherals User Manual for
more complete information.
Post Reply