ZX81+35 Clone

[chernandezba]

Well another question... Hsync counter is generated after an INT ack. But when is generated an INT ack? After a Maskable interrupt? Or also after a nmi?

[Andy Rea]

int-ack ( M1 and IORQ low at the same time) is only generated from a maskable interrupt , the NMI response is different as it always jumps to $66

regards Andy

z80 manual http://www.zilog.com/appnotes_download. ... 5Ca1pnPT0=

[PokeMon]

Well another question... Hsync counter is generated after an INT ack. But when is generated an INT ack? After a Maskable interrupt? Or also after a nmi?

Don't mix up NMI and INT.

INT is accepted only when enabled via EI instruction first and automatically disabled after accepting the interrupt (to avoid nested interrupts). It may be enabled again inside the INT routine if wanted but this is not used in ZX81 rom. The INT ACK (interrupt acknowledge cycle) is executed to show devices that the interrupt has occured AND was accepted, this is signaled with M1 and IORQ active (low).

In ZX81 schematics A6 is connected with the INT input of the cpu which may confuse on the first view. As the INT is only sampled on the 3rd clock cycle of M1 cycle (if I am not wrong) this has no effect on normal addresses but on the refresh address placed during refresh cycle. So the R register is automatically incremented during video display till zero (A6=0=INT) and then the interrupt routine called (if interrupts enabled).

[chernandezba]

Ok. Thanks a lot!

[RetroTechie]

From the Z80 CPU Product Specification:

Interrupt Request/Acknowledge Cycle. The CPU samples the interrupt signal with the rising edge of the last clock cycle at the end of any instruction (Figure 8). When an interrupt is accepted, a special /M1 cycle is generated. During the /M1 cycle, /IORQ becomes active (instead of /MREQ) to indicate that the interrupting device can place an 8-bit vector on the data bus. The CPU automatically adds two Wait states to this cycle.

Note the "last clock cycle" and "any". That is: according to this documentation, A6 on the bus @ that time can come from part of an instruction other than refresh address in an /M1 cycle, like address where a regular read/write takes place.

So it would really depend on what instruction is being processed. Further of note:
* That 8-bit vector is only used for interrupt mode 0 or 2. I don't think the ZX81 uses this vector, read: it'll be using interrupt mode 1 which ignores it and calls a fixed address (0038h).
* NMI response doesn't include this interrupt acknowledge cycle.

[1024MAK]

Correct, the ZX81 and ZX Spectrum use mode 1 and jump to the routine in ROM at 0038 hex.

Mark

[1024MAK]

The Undocumented Z80 Documented

Sean Young
Version 0.91, 18th September, 2005

5.5 Where interrupts are accepted

During execution of instructions, interrupts won’t be accepted. Only between instructions. This is also true for prefixed instructions.

Directly after an EI or DI instruction, interrupts aren’t accepted. They’re accepted again after the instruction after the EI (RET in the following example). So for example, look at this MSX2 routine that reads a scanline from the keyboard:

LD C,A
DI
IN A,(0AAh)
AND 0F0h
ADD A,C
OUT (0AAh),A
EI
IN A,(0A9h)
RET
You can assume that there never is an interrupt after the EI, before the IN A,(0A9h) — which would be a problem because the MSX interrupt routine reads the keyboard too.

Using this feature of EI, it is possible to check whether it is true that interrupts are never accepted during instructions:

DI

make sure INT is active

EI

insert instruction to test

INT:

store PC where INT was accepted

RET

And yes, for all instructions, including the prefixed ones, interrupts are never accepted during an instruction. Only after the tested instruction. Remember that block instructions simply re- execute themselves (by decreasing the PC with 2) so an interrupt is accepted after each iteration.

Another predictable test is this: at the “insert instruction to test” insert a large sequence of EI instructions. Of course, during execution of the EI instructions, no interrupts are accepted.

But now for the interesting stuff. ED or CB make up instructions, so interrupts are accepted after them. But DD and FD are prefixes, which only slightly affects the next opcode. If you test a large sequence of DDs or FDs, the same happens as with the EI instruction: no interrupts are accepted during the execution of these sequences.

This makes sense, if you think of DD and FD as a prefix which set the “use IX instead of HL” or “use IY instead of HL” flag. If an interrupt was accepted after DD or FD, this flag information would be lost, and:

DD 21 00 00 LD IX,0
could be interpreted as a simple LD HL,0 if the interrupt was after the last DD. Which never happens, so the implementation is correct. Although I haven’t tested this, as I imagine the same holds for NMI interrupts.

Mark

[PokeMon]

Well - didn't had this in my mind.
The reason why the INT control with fixed wired A6 works is because the sequence

Code: Select all

EI
JP (HL)

is used to start the display line. INT is accepted (if present) on the instruction following JP (HL) which has to contain valid display code, means forced NOP instructions or the HALT instruction at the end of the line.

The enable interrupt instruction sets both interrupt enable flip flops (IFFI
and IFF2) to a logic 1, allowing recognition of any maskable interrupt. Note
that during the execution of this instruction and the following instruction,
maskable interrupts are disabled.

I think this is done to make the RETI instruction work as expected and to avoid stack overflow with (unwanted) nested interrupts. If INT is still kept low, it would call another ISR without ending the routine. With the sequence EI, RETI the return is executed prior to the next interrupt service which won't attack the stack regardless how long INT line is kept low.

[mahjongg]

Hello, I'm mahjongg the author of this ZX81 clone, thanks for looking at the schematics of it, and for the tip.
If I understand it correctly the frame counter should not be reset/synchronised by the VSYNC signal, but by the interrupt acknowledgment (INTACK) signal which is /M1 AND /IORQ, meaning I need a single NOR port to generate it.
I'm willing to add the NOR, but I'm not convinced its a good idea to do so, it will influence the timing of the generated video signal by removing the number of cycles taken up by the VSYNC signal, because compared to the VSYNC signal INTACK is very short. In fact the current timing means that the total cycles used for a frame is the number of cycles of the frame counter PLUS the length of the VSYNC signal.
As you can see I added a "front/back porch" generator to the frame counter to add the (originally missing) front/back porch, and this front/back porch should be generated AFTER the end of VSYNC signal, which will now happen as the frame counter is released at the end of VSYNC, but if the actual VSYNC is generated while the frame counter is already running my front porch logic will fail.
I have to carefully study this again, by reading the ZX81 source code disassembled book to see what is actually expected that the ULA does.

Also, the "VSYNC holds the frame counter/horizontal sync counter" idea is not invented by me, at least two different other ZX81 clones, and a ULA remake use the exact same logic.

So I ask if this is really a good idea to do this, and can I (need I) to modify the front/back porch generator? and how?
As its now the front/back porch will be generated for the first sixteen cycles after the frame counter is released.

p.s. post edited to make clear that I meant the front porch, not the (irrelevant) back porch, and that I also meant the horizontal sync counter.

[1024MAK]

Welcome to the forum mahjongg

I have been reading you web page about your ZX81 clone...

Do keep at it, it makes some very interesting reading

Mark