I have had a look at a fully functional zx81 in particular the wait pin on the z80. In slow mode, negative going pulses on the wait pin but to my surprise the pulses do not fall to ground, instead from 5V to around 1.5V in depth.
So what I did was include some emitter degeneration resistance on the t synchro bjt (Re=150R), the situation has improved somewhat, now when I press reset I get a corrupted 'K' and the top right hand corner of the screen is corrupted(in slow mode only). Using the keyboard only, I can switch between slow and fast modes and back again and it always boots up in slow mode and the cpu appears to be stable. So, I'm still scratching my head as to why the corruption on screen,in slow mode, but it's a step closer towards a working zx81. I am starting to believe the ula isn't 100% high/low low/high digital.
- Posts: 2999
- Joined: Mon Sep 26, 2011 10:56 am
- Location: Looking forward to summer in Somerset, UK...
Sinclair used a ZTX313, which Ferranti describe as a "high speed switching transistor". In the data sheet, they say that these are specifically designed for high speed switching applications and are also useful where very short storage times and low capacitance are required." They give a figure of 13ns for the max. storage time, and 18ns for max. turn-off time.
In the real world of "TTL" interfaces and devices, it's not that uncommon for logic levels to be a bit near their maximum tolerance. But 1.5V is even a bit high for that. The Zilog data sheet for an NMOS Z80 CPU specifies a low (VIL) as between -0.3V and 0.8V.
Actually, you are right, with the transistor removed completely from circuit there is no change in screen characteristics in slow mode. I've tried a very wide range of resistor/cap. values and the best result I can get is without the wait states altogether.Very frustrating.1024MAK wrote:Are you sure that the transistor actually switches off fast enough?
When completely removed, there is no sync at all which gives distortions as well.commie wrote: Actually, you are right, with the transistor removed completely from circuit there is no change in screen characteristics in slow mode.
You can do it with a simple OR Gate (74HCT32) while feeding HALT and NMI as input and connect its output to WAIT. Then WAIT is activated if both going low (NMI during HALT) and released on the rising edge of NMI which would be perfect. This way you have automatically included the WHY WAIT logic from Wilf Rigter which gives a speed increase of about 10% to the simple transistor logic as well.
http://www.user.dccnet.com/wrigter/inde ... 81WAIT.htm
Hi PokeMon,PokeMon wrote: from Wilf Rigter
Nice interesting circuit that you have brought to the forum attention, thanks for that. I tested the two bjt latch and it does indeed work very well. Now my zx81 prototype boots straight into slow mode and I can switch from slow to fast mode and back again using just the keyboard. However, unfortunately I'm still stuck on my original problem that is the top right hand corner of the screen is corrupted along with the 'k' cursor.
I'm using Wilf Rigter's 32k ram decoder, it too works well.
Cheers for now
There is a mismatch of 4 lines. Don't know the circuit of Retrotechie, I think he can point to the possible error. The scanline counter overdrives A0-A2 during refresh period to address the char rom. The scanline counter (0-7 pointing to every scanline of a character) must be reset at beginning of the picture / end of nmi period. The FAST mode does this all in software - so this is a hardware/logic issue of your CPLD or FPGA.
The other point is, that the line length is not set correctly resp. is too short. You can see that when the picture ends (after the last cursor line) that there is probably 1 pixel too less so that end of line moves step for step in the visible picture. This length is normally 207 clock cycles long (308ns clock * 207=63.7us) while the horizontal syncs are shorter than 64us (if present at all during NMI time). The horizontal sync is created in software during picture display with the HALT instruction (NEWLINE) at the end of a scanline. It can and should also be present when NMI is switched on. So there is a mismatch.
You could measure this best with a logic analyzer or digital oscilloscope as a small difference of 1 percent is not seen with an analogue oscilloscope. Or you do a review of your code.