Bugs in Z80 8EE

Hi, Vitaly! DL>> tested the following. protsy: DL>> Goldstar Z8400A 1990 DL>> SGS Z8400AB1 '85 DL>> ZILOG Z0840004PSC 90 DL>> ZILOG Z8400A '84 DL>> KR1858VM3 1995 (Soviet CMOS) VV> SHARP LH0080B 91 DL>> on all processors, the OUTI command affects the C flag. VV> similar DL>> it was not possible to detect a pattern, although with the same DL>> data is always the same result on all processors. VV> The pattern of changing the C flag is simple (if I haven’t screwed it up): VV>OUTI VV> sets flag C as: VV> LD A,(HL) VV>OUTI VV> ADD A,L wow! how did you guess? Well, you have to shoot yourself - like that break the crooked pattern :-) All the best. Dmitry. ..LD..X-TRADE..

Let your enemies, Vitaly, die without sons! 09-11-98 at 08:28:00 Vitaly Vidmirov ═> Dmitry Lomov: [in trash] DL>> you'll find out - it will be possible to launch a shock, I won't be lazy, I'll do it VV> Hello. It turns out that we no longer remember the makeshift branded cars... VV> It turns out that everyone skipped the moment when I posted temporary posts here and VV> description of the cause of glitches, such as I<#80. There are no words. Pachemu everything, daragoy? === the hat has sunk into oblivion === I was prompted to write this manuscript by the desire to clarify this the question is still not entirely clear to many, although in principle, I still don't understand some things... In the process of writing, I found both evidence of power dealers of a branded car, and the dock to Lunterovsky was investigated spec emulator (Z80). Okay, that's enough entry per capita for us! The makeshift is different for 48k and 128k cars. For 48 car: int │ (*) │ │16│ ╔═════════════════╗──│─── │ 64 ║ ║ │ │48│ ║ ███▓▓▓▒▒▒░░░──║──│──────── ║ ███▓▓▓▒▒▒░░░ ║ │ │ ║24 ███<128>▒░░░24║48│ │ 192 ║<> ███▓▓▓▒▒▒░░░<>║<>│ │ ║ ███▓▓▓▒▒▒░░░ ║ │ │ ║ ███▓▓▓▒▒▒░░░──║──│─── ║ ║ │ │ ╚═════════════════╝ │ │ 56 │ │ │ └────────────────────┘───312 lines x 224 bars = 69888 For 128 car: int │ (*) │ │ ╔═════════════════╗ │ │ 63 ║ ║ │ │ ║ ███▓▓▓▒▒▒░░░──║──│────── ║ ███▓▓▓▒▒▒░░░ ║ │ │ ║LB ███<128>▒░░░RB║HR│ │ 192 ║<> ███▓▓▓▒▒▒░░░<>║<>│ │ ║ ███▓▓▓▒▒▒░░░ ║ │ │ ║ ███▓▓▓▒▒▒░░░──║──│─── ║ ║ │ │ ╚═════════════════╝ │ │ 56 │ │ │ └────────────────────┘─── 311 lines x 228 bars = 70908 LB+RB+HR=100 I don't know more exact values. In the dock for the Lunter emulator it was written that the first byte the screen will be displayed 14364 clock cycles (in 128k) after the appearance int. That. The ULA begins forming the screen at point (*). First it displays the middle part of the screen (or border), then the border, then the beam returns, then the border returns. Screen data sampling is performed every 4 clock cycles (the screen byte and attribute are read). The border color also changes every 4 beats. ULA with 16k of lower memory and 32k of upper memory do not work depending. If the processor wants to read or write to the lower memory, it slows down if the ULA is also reading. As far as I understand, this is achieved by using 2 address buses ca and data, which are nevertheless connected to each other through resistors. Lower memory works 15-30% slower, especially if the sizePost a program there, and ULA in the 128th machine gives the processor more freedom in access to these 16k than 48th. fast memory: 70908 -> 128/+2/+2a/+3 slow memory: ~58640 -> 128/+2 ~65135 -> +2a/+3 Oddly enough, IN (#FE) slows down the processor until ULA will give the result. On average, the command "IN A,(#FE)" takes 12.15 bars, instead of the required 11. If the Z80 reads from a non-existent port, then the contents are read data buses. And because ULA does not stop, and ~62% of the time is under- When constructing a screen, bytes appear on the data bus with screen and attributes. The processor reads on its data bus what appears on the ULA data bus. ULA does not digest the interrupt vector below #8000 one by one Reason: During cycle M1 (opcode extraction), the processor outputs address bus to the low part the contents of the register R, and to the high part - contents I (for memory regeneration). At I=#40-7F, ULA is buggy, and thinks that the processor wants to read a byte from the lower 16k. ULA cannot cope with such a reading frequency and misses a byte which is intended for constructing a screen. And instead of this byte the previous one is used, which leads to the appearance of “snow” on screen. 48k/128/+2 spectra still work, and +2a/+3 are doomed to collapse. Hmm... It seems like I didn't mess anything up, but who knows? There is a certain Vectron toy that I certainly haven't seen, butit uses the hardware feature described above... And the last question is the page port. At 128/+2 out (#FD),#10/#50 works exactly like out (#0D),#10/#50 Out works on +2a/+3 (#FD),#50 That's it. If I flashed lameness somewhere, excuse me... kind of like evil Vitalik AKA Dark / X-Trade -+- SMM version 1.08 + Origin: Oops... Where am I? (500:812/18.16) In my archive. :E Best wishes, Oleg aka Ruiner.

Hello, hello Dmitry! One day, in the chilly summer, something around (11-11-98/00:16:00) Dmitry Lomov once wrote to Vitaly Vidmirov... DL>>> on all processors, the OUTI command affects the C flag. VV>> The pattern of changing the C flag is simple (if I haven’t screwed it up): [ ] DL> wow! how did you guess? Well, you have to shoot yourself - like this DL> break the crooked pattern :-) I wrote a test program and ran it with different parameters... Which is what I did for 3 hours, after which I realized that: 1. C (0) = ld a,(hl):inc hl:add a,l 2. N (1) = most significant bit (hl) 3. Flags s,5,3 are a _composition_ of the corresponding B and L bits. The essence of the composition could not be established. It won't be superfluous Note that these flags are affected by the number after the decrement/increment. 4. P/V(2) acts as in paragraph 3, but changes in a tricky way patterns: 1,0,0,1,0,1,1,0. Those. 3 least significant bits register L(B) in accordance with this plate set p/v. 5. H seems to appear only with N (or C) I don’t remember. I don’t see any practical application of items 3-5, except maybe anti-emulator protection ;) evil Vitalik AKA Dark/X-Trade