Реверс-инжиниринг Z80

[goodboy]

а меня интересует недокументированная команда #ED71 OUT (C),0
и вроде так она выполняется на NMOS, на CMOS в порт засылается #FF

[Advertiser]

[Titus]

а меня интересует недокументированная команда #ED71 OUT (C),0
и вроде так она выполняется на NMOS, на CMOS в порт засылается #FF

Да, надо с ней разобраться.
Но думаю, что там все просто. Ни один регистр не выдается на шину, и она остается заряженной до логической 1. А так как линия инверсная, вот и получается в итоге 0.
Но проверю.

- - - Добавлено - - -

Titus, не мог бы ты добавить в свой тест поддержку обнаружения бага Zilog NMOS, который приводит к сбросу флага P/V при приеме маскируемого прерывания во время выполнения команд ld a,{i|r}?

Где подробно описан этот баг?

[goodboy]

https://web.archive.org/web/20141208...hive.ru/id/465

[Titus]

https://web.archive.org/web/20141208...hive.ru/id/465

Это немного староватая информация.
Я о новых, современных исследованиях)

[Deadly]

иследуй что то полезное:
LDI CPI INI OUTI
LDD CPD IND OUTD
LDIR CPIR INIR OTIR
LDDR CPDR INDR OTDR

[goodboy]

OUTD

тут я помню что сначала уменьшается B, а потом идёт вывод в порт.
во многих справочниках указан обратный порядок.

[org]

Милорд, народ требует зрелищ! Где схемота, где картинки чипов? То что вы делаете последние несколько страниц - это вообще Clean Room эксперименты, которые вполне можно считать за оффтоп и удостоить отдельного топика. ХВМ прав тем что вы отходите от темы и потом тут найти что-то полезное будет сложно.

[Titus]

Милорд, народ требует зрелищ! Где схемота, где картинки чипов?

Вообще-то я выкладывал в теме и потранзисторную схему, и схему логическую.

[ZjoyKiLer]

Это немного староватая информация.
Я о новых, современных исследованиях)

Ты можешь протестировать его с помощью Visual Z80 Remix: https://floooh.github.io/visualz80remix/

http://z80.info/zip/ZilogProductSpec...ook129-143.pdf (Стр. 130)

Q: I don't seem to get the correct state of the interrupts when using the LD A,l and LD A,R instructions to read the state of IFF2. Why is this? How can I get around this?

A: On CMOS Z80 CPU, we've fixed this problem. On NMOS Z80 CPU, in certain narrowly defined circumstances, the Z80 CPU interrupt enable latch, IFF2, does not necessarily reflect the true interrupt status. The two instructions LD A,R and LD A,l copy the state of interrupt enable latch (IFF2) into the parity flag and modifies the accumulator contents (See table 7.0.1 in the Z80 CPU technical manual for details). Thus, it is possible to determine whether interrupts are enabled or disabled at the time that the instruction is executed. This facility is necessary to save the complete state of the machine. However, if an interrupt is accepted by the CPU during the execution of the instruction -- implying that the interrupts must be enabled -- the P/V flag is cleared. This incorrectly asserts that interrupts were disabled at the time the instruction was executed.

Zilog (1989-01). "Z80 Family Data Book", Стр. 412-413

https://zxe.io/depot/documents/techn...29%28en%29.pdf

Q: I don't seem to get the correct state of the interrupts when using the LO A,I arid LO A,R instructions to read the state of IFF2. Why is this? How can I get around this?

A: On CMOS Z80 CPU, we've fixed this problem. On NMOS Z80 CPU, in certain narrowly defined circumstances, the Z80 CPU interrupt enable latch, IFF2, does not necessarily reflect the true interrupt status. The two instructions LO A,R and LO A,I copy the state of interrupt enable latch (IFF2) into the parity flag and modifies the accumulator contents (See table 7.0.1 in the Z80 CPU technical manual for details). Thus, it is possible to determine whether interrupts are enabled or disabled atthetime that the instruction is executed. This facility is necessary to save the complete state of the machine. However, if an interrupt is accepted by the CPU during the execution of the instruction -- implying that the interrupts must be enabled -- the PN flag is cleared. This incorrectly asserts that interrupts were disabled at the time the instruction was executed.

This paradox can be traced to the internal timing of the CPU. The problem is that the interrupt flip-flop (IFF2) is cleared before it is actually transferred to the PN flag. The state of the interrupt enable latch is not copied into the parity flag until after the interrupt time, occurring during the execution of the instruction, has been accepted. Since the acceptance of the interrupt automatically clears the interrupt enable latch, the parity flag is also cleared, despite the fact that interrupts were enabled when the instruction started executing.

A neat solution to this anomaly relies on the fact that at least one item--the old PC value -- is saved on the stack when an interrupt is accepted. The "next entry" position on the stack (the word below the address currently held in the stack pointer) may be cleared before execution of LO A, I (or LD A,R). If that zero value has changed by the time that the next instruction in the routine is executed, then an interrupt must have been accepted. This implies that interrupts were enabled,. even if the state of the parity flag suggests that they were not. Of course, if the parity flag is found to be set after LO A,R (LO A,I) has been executed, there is no need to check the stack top. Interrupts are definitely enabled if the parity flag is in this state.

Two routines are listed here. Both return carry clear if interrupts are enabled, set otherwise. Both corrupt the A register; it does not contain the value in the I (or R) register on exit The status of all flags except the carry flag are undefined on exit.

The first routine may be loaded anywhere in memory except "page zero" -- 0000h to 00FFh. This small restriction comes about because the routine checks only the most significant byte of the "next" stack entry. This byte will be non-zero afteran interrupt has occurred if and only if the routine itself is not on page zero. The second routine tests both bytes of the "nexf' entry and, therefore, overcomes this restriction.

Caution, these routines presume that the service routine for any acceptable interrupt will re-enable interrupts before it terminates. This is almost always the case. They may not return the correct result if an interrupt service routine, which does not re-enable interrupts, is entered after the execution of LD A,I (or LD A,R).

Listing 1 : This routine may not be loaded in page zero
        (OOOOh to OOFFh).

GETIFF:
        XOR A    ;C flag, acc. := O
        PUSH AF  ;stack bottom := OOxxh
        POP AF   ;Restore SP
        LD A,I   ;P flag := IFF2
        RET PE   ;Exit if enabled
        DEC SP   ;May be disabled.
        DEC SP   ;Has stack bottom been
        POP AF   ;overwritten ?
        AND A    ;If not OOxxh, INTs were
        RET NZ   ;actually enabled.
        SCF      ;Otherwise, they really are
        RET      ;disabled.
        END

Listing 2: This routine may be loaded anywhere in memory.

GETIFF:
        PUSH HL  ;Save HL contents
        XOR A    ;C flag, acc. := 0
        LD H,A   ;HL :=0000h
        LD L,A
        PUSH HL  ;Stack bottom := OOOOh
        POP HL   ;Restore SP
        LD A,I   ;P flag := IFF2
        JP PE,
           POPHL ;Exit if isn't enabled
        DEC SP   ;May be disabled.
        DEC SP   ;Let's see if stack bottom
        POP HL   ;is still OOOOh.
        LD A,H   ;Are any bits set in H
        OR L     ;or in L?
        POP HL   ;Restore old contents.
        RET NZ   ;HL <> O : isn't enabled.
        SCF      ;Otherwise, they really are
        RET      ;disabled.
POPHL:
        POP HL   ;Exit when P flag is
        RET      ;set by LD A,I
        END

[Titus]

Ты можешь протестировать его с помощью Visual Z80 Remix: https://floooh.github.io/visualz80remix/

Мне не нужно его тестировать на модели, мне нужно теоретическое описание, чтобы проверить, почему оно так происходит по схеме реверса.

Кстати, на основе чего создан visualz80remix? На основе Z80 Explorer'а?