Nice. This looks very similar to the Frogger clone I made back in the day for the ZX Spectrum (a Z80 machine with a 256*192 monochrome bitmapped screen similar to this, albeit with low-res colour attributes overlaid on top). I used it to learn smooth-running "sprites" and scrolling techniques, and it followed some very similar routines. I recommend it to anyone learning, or jumping back into 8-bit programming as all of the graphic techniques are there but the game mechanic is quite simple. The main issue I had as I recall was stopping the frog flickering on the car section, as you don't want to scroll the frog there and so have to remove it and redraw. That's where the code gets a bit more complex 😂 As you alluded to, drawing the lines where the frog is in a buffer then LDIRing to the screen fixes this.
There was a bit more code to demo but I cut it out for time. I actually got the screen redraw working even faster. Currently, I use a delay between GLCD commands as I've had issues with reading the GLCD busy flag. It's a bus timing issue. BUT with my setup I was able to read busy successfully making updates really fast. I couldn't replicate it on other TEC-1Gs. Delay it is for now
The screen is the same resolution as the TRS80 model1, and there are hundreds of fab games for this machine, most of which, were designed to run in the 16kb RAM cassette based machine. The problem with LCD displays, is that the display tends to smear moving graphics. Maybe time for a TEC-1G z80 to get video out? Stephen G7VFY
ok I have questions!... 1) Is that LCD screen attached via SPI or paralel interface? The G12864 lets you read back in parallel but not in SPI. For SPI, you would need a effectively a copy of the screen in RAM to do your masking operation. 2) What editor are you using that highlights Z80 Assembly in colour? Ive written thousands of lines of Z80 code without that niceity
The GLCD uses a ST7920 chip. Its has both Parallel and SPI. Its running in Parallel mode (it's quicker) but I've got code for SPI. The screen data is stored in a buffer in RAM, which gets pushed out to the LCD every draw loop. I'm using VSCode with some Z80 extensions.
This is chicken soup for the Z80 bit-banger's soul. Great little project. Thanks for sharing. BTW... I like that collision via checksum, neat trick.
Great video as always Ready? Z80!
Very cool! Well done!
Nice. This looks very similar to the Frogger clone I made back in the day for the ZX Spectrum (a Z80 machine with a 256*192 monochrome bitmapped screen similar to this, albeit with low-res colour attributes overlaid on top). I used it to learn smooth-running "sprites" and scrolling techniques, and it followed some very similar routines. I recommend it to anyone learning, or jumping back into 8-bit programming as all of the graphic techniques are there but the game mechanic is quite simple.
The main issue I had as I recall was stopping the frog flickering on the car section, as you don't want to scroll the frog there and so have to remove it and redraw. That's where the code gets a bit more complex 😂 As you alluded to, drawing the lines where the frog is in a buffer then LDIRing to the screen fixes this.
There was a bit more code to demo but I cut it out for time. I actually got the screen redraw working even faster. Currently, I use a delay between GLCD commands as I've had issues with reading the GLCD busy flag. It's a bus timing issue. BUT with my setup I was able to read busy successfully making updates really fast. I couldn't replicate it on other TEC-1Gs. Delay it is for now
this is so cool! love the video 😊
Legendary!
The screen is the same resolution as the TRS80 model1, and there are hundreds of fab games for this machine, most of which, were designed to run in the 16kb RAM cassette based machine. The problem with LCD displays, is that the display tends to smear moving graphics. Maybe time for a TEC-1G z80 to get video out? Stephen G7VFY
100%
ok I have questions!...
1) Is that LCD screen attached via SPI or paralel interface? The G12864 lets you read back in parallel but not in SPI. For SPI, you would need a effectively a copy of the screen in RAM to do your masking operation.
2) What editor are you using that highlights Z80 Assembly in colour? Ive written thousands of lines of Z80 code without that niceity
The GLCD uses a ST7920 chip. Its has both Parallel and SPI. Its running in Parallel mode (it's quicker) but I've got code for SPI. The screen data is stored in a buffer in RAM, which gets pushed out to the LCD every draw loop.
I'm using VSCode with some Z80 extensions.
Well done using multiple output screens. Nice!