ZX81 Video Circuit Part 3: TEXT.
ฝัง
- เผยแพร่เมื่อ 29 พ.ย. 2024
- Text character generator added to the design.
Part 1: Z80 - Solo - • ZX81 Video Circuit Par...
Part 2: Hi-res display - • ZX81 Video Circuit Par...
Part 3: TEXT - • ZX81 Video Circuit Par...
Part 4: Display files - • ZX81 Video Circuit Par...
Part 5: A6 - Interrupt - • ZX81 Video Circuit Par...
Part 6: HSYNC - • ZX81 Video Circuit Par...
Part 7: ZX81 Slow mode - • ZX81 Video Circuit Fin...
Ken Shirriff's 4116 blog page.
www.righto.com/...
Even if you're not interested in how the video logic works, this is still worth watching just for the description of SRAM vs DRAM and refresh logic. Thanks!
Thanks, enjoy!
This series is highly appreciated! If only such concise information had been available back in the days...
Glad you're getting some value from it.
Excellent explanation of DRAM!
Glad you liked it
Great video! To clarify most of the pseudo hi res graphics games that don’t require any additional hardware such as Rocketman , Forty Niner etc all use the same technique .. change the I register to another random set of ROM data - values of 12 and 8 are the most common… this gives access to pseudo random bit data for each “character”. The video buffer in memory is 182 lines of 32 characters each of which ends in a Ret not Halt opcode (both with bit 6 set in the opcode of course). A custom video driver jumps into this video buffer and the trick is that the display driver resets the Line Cntr for each line so it never increments !! Tada pseudo high res images …
@@TechWorldServices yeah, you just change the interrupt address for a random character set. We then have 7-bits (inverse + 6 bits) for 8-bit of display.
Good Video, I think this channel will go through the roof
Thanks for the feedback.
So really, the ZX80/81 are a text display circuit that just happens to have the ability to run BASIC as well. ☺️ I knew this was true in terms of the timing, i.e. the ZX81 executes user programs during the non-visible lines of the display, but I had no idea it was so literally true at a hardware level.
Yep, nearly all the 7400 series logic and most of the
CPU time (when the display is stable) is for generating the image
It seems from this explanation that the screen RAM contains not just video information but also a program which is the "main loop" which runs all of the time unless an interrupt (such as for keyboard input) comes which then suspends the video processing until the interrupt is handled. Once the interrupt is handled, it then does a RETI to return to the main loop. That's why the screen "flicks" each time a keyboard key is pressed: It has to stop displaying so that it can handle input.
Yep, i'll be going over interrupt in the next video.
Very very informative and interesting thank you
Glad you enjoyed it
Хорошая работа, спасибо.
Enjoy!
Really enjoying this series of videos, I'm wanting to reach for thesoldering iron!
Go for it!
"The ZX80 and ZX81 used SRAM" unless you added a wobbly 16KB expansion module, in which case the free refresh from the Z80 (even hijacked as it was) really helped.
Actually, the 16k Ram expansion had to recreate their own refresh. If you have a look at the schematic, the 16k expansion has a 74ls393 to recreate the refresh counter. This one had me baffled for a while.
@@DrMattRegan wow. I didn't expect that. I had the module but never looked inside and didn't study its schematic. It still depends on the Z80 timing so this wouldn't work on any other processor.
True, it still uses the refresh timing, it just has it's own counter. I also means you can't use data stored in the DRAM to directly replace the character set.
I like the way you solder the protoboard jumper wires. I have never thought to strip off a long stretch of insulation, solder the bare wire and then thread the correct length of insulation back onto the wire. It looks like it produces a neat result and would be easier then trying to strip the correct length of wire to begin with.
Do you have a more detailed description of this technique anywhere? I will have to give it a go when I am next wiring something up.
I have thought of doing a video like that. I was thinking of comparing the VGA from a EPROM design in both bread board and point to point soldering.
Now im curious what the old zif socket is going to be used for!
Want to posit a guess!
I don’t really want to store the text frame buffer in EPROM. Very hard to change it at run-time
Impressive ✨
although when you feedback output from eeprom to ROM address via mux doent it cause timing glitch ? since it is not been clocked to avoid hazards in timing.
Thanks, no the data from the EPROM is clocked through the character register.
Really interesting Matt.R
I should find a zx80 hardware book to read
Enjoy!
Great explination, very easy to follow. Though I expect I'll have to watch it a few times for it to really sink in. Question: It seems like this pushes a lot of complexity into software for driving the video system. Did the ZX provide any abstractions for developers to help with that complexity?
Sinclair being Sinclair: no. The only thing were the Basic (pun intended) output routine that handles the "display file" (IIRC). With 1k, screen buffer was dynamic with ENTERs representing EOL. Only with more RAM the display file becomes fixed size 32x24, if I'm not mistaken. Hires modules were a separate thing, I had a Memotech HiRes module and a Memotech 32k RAM module.
Correct, i'll be going over the display file in the next video.
My understanding about games that appear to show an arbitrary bitmap is that they use custom display code to address any byte from the character ROM that they need at the time, with the caveat that it may not be a perfect match at all times.
I haven't disassembled any game code, but the problem with the current character set, is that line 0 and line 7 are blank for almost all characters. I'd personally prefer random code to the existing character set.
@@DrMattRegan I'm reading elsewhere that the I register is used for the high byte of the address (normally $1E to point to the character set, but other parts of the ROM may be preferable, as you suggested).
@@peterhemmings2929 correct. That is one of the tricks for pseudo high res