Project Logs

Collapse

• OpenSpand is now open!

  adam.klotblixt • 12/08/2025 at 07:07 • 0 comments

  The project is now released to the public at:
  https://codeberg.org/NollKollTroll/OpenSpand
  

• Closer to finished

  adam.klotblixt • 10/25/2025 at 11:50 • 0 comments

  I have not updated here in a long time, but things have progressed in the background.

  The goal is to have all hardware and software sources released before the end of 2025. As with all release promises this is not set in stone, but it looks promising. Barring any unforeseen events, this project will finally be release-worthy!

• Video out

  adam.klotblixt • 02/09/2025 at 12:56 • 0 comments

  OpenSpand v0.1.0 has a composite video out connector. I made some test-code already on the previous version which mostly worked, but lacked the /HALT signal to be properly completed. Now that the signal is available, it is possible to do everything needed.

  To be able to construct a video signal, most of the ULA functionality has to be replicated.
  

  I've struggled several days with this, and it boils down to me missing 1 critical fact and also too much complexity in the PIO code.

  I had missed that the sync-generator is free running until it either wraps around or gets an interrupt acknowledge. I really thought it was reset every vsync as well. Easy to fix when I had read about it.

  The PIO code was stranger. I tried to make 2 state machines, one to count cycles and generate syncs as well as tell the pixel generator when to operate. The pixel generator is a separate state machine. Synchronization between them was done via a PIO-interrupt. It didn't work very well for some reason, I could get it to work mostly in text mode but not in other modes. The fix was to remove the interrupt synchronization, simplifying the code dramatically! Now everything works as expected, in all modes.
  

• OpenSpand v0.1.0

  adam.klotblixt • 02/06/2025 at 08:12 • 0 comments

  The new revision of the card works after some troubleshooting and a patch. All the tested new features actually work the way we intended, but there is still some testing to complete.

  There are SO many features that could be done in both HW and SW, it's hard to decide what to do and what to postpone or scrap. Good to have a colleague to discuss with, but we always end up getting new ideas :)

  The RTC module gave me trouble, it might work OK with the specified LIR2032 rechargeable cell, but it does not work without it or with a CR2032 cell. I found a forum thread with a work-around with a solution that removes 4 components and adds a bridge. Now everything works as expected for me, even with a CR2032 cell.

  Yes, there is now a pass-thorough.
  

• The perils of optimization?

  adam.klotblixt • 01/25/2025 at 15:50 • 0 comments

  The other day I had a nice chat with FreddyV, known for PicoMem and PicoCPC. Projects that are quite similar to OpenSpand, but for other platforms than the ZX81.

  He's been optimizing his projects far longer than I have, so we delved into what he'd done. Now that I've implemented similar optimizations, the project runs far leaner, and the code is also easier to read. Great news for when I want to complete the implementation of video output, which requires quite some cycles.
  

  Unfortunately I have a new (old) problem: the clone ULA VLA81 is MUCH more finicky about how long things take, and now that the code is optimized, it complains earlier/more often! I have none of these problems with the Sinclair original ULAs and the other 2 clone ULAs I have... Lowering the RP2350B speed fixes (masks?) the problem, but is not a long term fix. I have to debug and fix the problem, since the only clone ULA sold now IS the VLA81!
  

• Fixing a ZX81

  adam.klotblixt • 01/13/2025 at 09:52 • 2 comments

  I have 3 ZX81 units. A few years ago one of them started exhibiting problems with reading the keyboard, which I assumed was a faulty ULA. Half a year ago, it failed ALL keyboard reads, so it was put away.

  Today I decided to do a repair attempt. After some searching, I noticed the resistor pack RP3 had 3 of the 5 resistors bad in different ways. I removed it and mounted separate resistors. The keyboard attachment points still measured wrong, so more detective work.

  Much searching later I had found the heat sink for the voltage regulator shorted 2 traces. Fixed with some fresh electrical tape. The keyboard still measured wrong, but not as much.

  Finally found a dodgy solder joint on one of the ULA pins going to the keyboard. I reflowed the solder joint and now everything works as expected!

  So happy to have a spare working ZX81, they do go bad sometime.
  

• Testing ULAs

  adam.klotblixt • 01/06/2025 at 17:56 • 0 comments

  I spent the entire day testing different combinations of ULAs and CPUs on my ZX81s in order to understand why some combos did not work with OpenSpand. Lots of chip changes and short tests of different programs, lots of hung or rebooted ZX81. In the end I did find a way to be compatible with all the combinations I have tested.

  In the RD code I used to let the RP2350 first output data and then set the data itself. It worked perfectly fine on the Sincalir ULAs, but very poorly on some of the clone ULAs. Changing the order to first write the data and then setting to output fixed a lot of problems.

  The main loop that checked the Z80 bus and responded in real time had to be changed as well. After many hours of testing and rewriting code, I decided to read a newer version of the Z80 manual. I had problems with the CMOS version of the Z80, whereas the NMOS version was perfectly stable. After some reading I realized I had decoded the RFSH signal by itself, where the manual claims it has to be decoded together with MREQ. With this info I managed to change my if/else-code to a much better switch/case that is better at decoding the bus evenly timed. In the end I had to use 2 different statements, both RFSH together with MREQ and RFSH by itself, in order to get 100% stable operation.

  5 different ULAs, 4 different CPUs were tested on 2 different ZX81 revisions. I finally have a better grasp of what chips I own, and that they actually work OK :D
  

  From left to right:
  VLA81 V2.2, 2x of Andy Rea's ZX81 ULA 2K18, Andy Rea's ZX81-ULA 2011, Sinclair 2C185E and 2C210E under heatsinks.
  

• A colleague

  adam.klotblixt • 12/31/2024 at 22:23 • 0 comments

  Since writing about this project on the ZX81 forum the project now has a new member, who is very keen on doing both HW and SW. We had a long and very pleasant introductory video chat with lots of ideas and knowledge sharing. Feels good to not work alone any more!

  OpenSpand v0.0.1 card number 2 has been built and will be sent to him as soon as the post offices are open.
  

• EEPROM woes

  adam.klotblixt • 12/28/2024 at 17:55 • 0 comments

  For a long time I've had problem with starting the program ZXpand Commander, it would only flash by and reset the ZX81. ZEdragon had problem when ending a game and it tried to save hi-score to the EEPROM, it would hang or restart the ZX81.

  I really thought I had some serious debugging in front of me, but today I implemented EEPROM initializing, which cleared up the Commander problem. Faulty data in the persistent storage apparently.

  On a walk this afternoon I realized that the EEPROM emulation actually pauses the other core while committing the data. Of course that messes stuff up, since the other core deals with hard real time stuff like memory and I/O!

  A different approach was implemented: everything is saved in the EEPROM layer in RAM, and the user has to actively save to persistent storage in the config menu. This fixed the problem with Zedragon, wohoo!

  The remaining issue to do before serious testing is to make the joystick configuration better. Just some restructuring and better handling since I have 3 different ways/levels to config the joystick.
  

• Oh joy!

  adam.klotblixt • 12/27/2024 at 11:16 • 0 comments

  Today I extended the joystick configuration. There are quick options in the config menu, and in BASIC it is possible to set directions+fire with:
  

  CONFIG J=QAOPM

   Next up is saving the settings in EEPROM.
  

View all 16 project logs