Project Logs

Collapse

• Final RetroChallenge YouTube Video Log Entry #3 - Double-Buffering and Multiple Colors!

  Michael Wessel • 10/25/2025 at 16:12 • 0 comments

  This is my final RetroChallenge 2025/10 VLog Update. Double buffering has been implemented by now! 
  

  
  For double buffering, we are using the Adafruit Canvas object. Unfortunately, it turned out that Adafruit's drawBitmap is far too slow, even at max SPI bus frequency, and I needed to find a workaround. This solution is drawBitmapFast, and can be found here: https://github.com/adafruit/Adafruit-GFX-Library/issues/415

  Thanks much to "jsseab" (Jakob Selbing) for saving the project! Moreover, we can now specify fore- and background colors for the display. The GRAF-X command buffer is 8 KBs (8192 bytes) by now... getting to the limit of what we can do with the ATmega 1284p's 16 KBs of SRAM. Note that the Canvas is 1bit color depth only - drawBitmapFast doesn't work with the true color Canvas, and would probably require too much (SRAM) memory anyways. Also, it would be even slower. However, GRAF-X double buffering can be turned off, and we can then draw in multiple foreground colors and take advantage of the truecolor / 16 bit graphics TFT display and use all its colors. 
  
  Next year, I am going to release the firmware and a proper custom GRAF-X card PCB designed specifically for the Microprofessor on Github, maybe even with an additional speech synthesizer and AY 3-8910 soundchip (think "multi-purpose multimedia IO extension for the Microprofessor"). So stay tuned!
  
  The hardware you are seeing here is based on a re-purposed and "recycled" LambdaSpeak FS PCB for the Amstrad CPC. This proved to be a good basis for the project (better than a breadboard for sure), as it already had the required SPI headers on board - LambdaSpeak FS uses a MikroE SPI speech module, so the required SPI headers for connecting the TFT display were already in place and no further PCB mods were needed. 

  Alright guys, that's it! RC2025/10 is wrapped up for me! Looking forward to next year's RC challenge. Until then, enjoy your retro computers. Bye for now.

• RetroChallenge YouTube Video Log Entry #2 - Automagically Rotating 3D Cube!

  Michael Wessel • 10/19/2025 at 15:37 • 0 comments

  
  

  
  YouTube Video Description:

  EDIT: I am actually talking about the WAIT signal on the Z80 CPU, NOT the HALT signal.
  After the problem causing the graphics glitches and CPU crashes shown in VLog Update #1 was fixed (PicoRAM firmware update and ULTIMATE.INI file ADC levels adjusted), there is some more progress to share on the Z80 software side of things - check out this auto-magically rotating 3D cube! We can now record and playback rotation and zoom operations using a 256 byte record and playback buffer for "Cube Operations". One more update and we are done with this year's RetroChallenge 2025/10 - stay tuned for Update #3 next weekend!

• RetroChallenge Log Entry #3: The Glitches are fixed!

  Michael Wessel • 10/18/2025 at 13:56 • 0 comments

  The glitches seen in the previous video (Update #2) are fixed - this turned out to be completely unrelated to the MPF-GRAFX card, but was caused by PicoRAM Ultimate. An uncaught "glitch" in the SRAM emulation due to noisy ADC button decoding. I have pushed a firmware update to PicoRAM Ultimate and PicoRAM 6116. The problem was that due to bad and noisy ADC thresholds button presses were detected that weren't real. Now, each time a button press is registered, the SRAM emulation is temporarily halted... but it requires the Z80 WAIT line to be connected, which I had not. This caused the issues. Obviously, you can't just halt SRAM emulation and not halt the CPU and expect it to run properly. The problem was fixed by adjusting the ADC threshold levels in the UTLIMATE.INI (or, 6116.INI). But I added some UI Error Message now if such a "spurious" button press is detected caused by noisy ADC and inappropriate analog threshold levels in the init files. Hopefully, this will make the effect at least visible if it should happen again to someone. Because it really was a head scratcher, given that there was no visible indication for this error other than the CPU crashing or glitching. Now we at least see what's going on, and can the manually adjust the thresholds in the init files. Phew!

• RetroChallenge Log Entry #2: It's Rotating!

  Michael Wessel • 10/17/2025 at 14:18 • 0 comments

  I ported Brian Chiaha's code to the Microprofessor + MPF-GRAFX card. Still some glitches, but overall - it works! It was remarkably little work - after all, Z80 machines are not that different. And the code was very well written, with very clear documentation and well-documented TEC-1 firmware calls etc. Thanks, Brian! 

  So, here we go: 

  And here is my first VLog entry for the RetroChallenge:

• RetroChallenge Log Entry #1: MPF-GRAFX works with the ATmega1284p @ 16 MHz

  Michael Wessel • 10/16/2025 at 15:35 • 0 comments

  To support double buffering for the rotating cube, we will need more (video) RAM. Currently, MPF-GRAFX is using an ATmega644p @ 20 MHz. The 1284p is fully pin- (and software?) compatible but has four times the SRAM amount (16K instead of 4K). That's actually twice as much as I thought - nice! And should give us plenty of video SRAM to support double buffering (and maybe even for a color display?) for the Adafruit graphics library being used here. 

  So, I swapped the ATmega 644p @ 20 MHz with the 1284p. If was hoping it would run out of the box, but: 

  It didn't even initialize the SPI display. Something was wrong. Fuses maybe? Maybe MightyCore didn't work well enough for the 1284p? Maybe the Adafruit Library? SPI speed? I changed the display initialization sequence

    tft.initR(INITR_BLACKTAB);
    //tft.setSPISpeed(1000000);

   trying various settings, with and without explicit SPI  speed setting. Nothing worked. 

  OK, so maybe starting ATmega with the SPI display (which is complex) and expecting this to work out of the box isn't the best debugging strategy. So, does the thing run *at all*? It's always good to have a couple of LEDs on board... so before starting up SPI and the display, I put some code in to flash the LEDs as the first thing in "setup" to see if the ATmega was running code at all. And - nothing! So, something was fundamentally wrong. 
  
  My next guess was - maybe I (accidentally) bought a 16 MHz one, and the 20 MHz clock was simply too much and on the edge of this design. So, I swapped the 20 MHz crystal with a 16 MHz one: 

  and changed the clock settings in MightyCore accordingly: 

  To my relief I could now see LED activity upon boot, and even the display initialized correctly!  Phew!

  But, would it work with the Microprofessor? Let's see: 

  Alright, we are all set now for working on the firmware to support double buffering and can indulge ourselves with Z80 programming as well, trying to port the rotating 3D cube to the Microprofessor and GRAFX card now. Seems the hardware side of things is done - I would call that progress! 

  Stay tuned, the next update is coming soon (hopefully, before the RetroChallenge RC2025#10 runs out ;-) )

View all 5 project logs