Project Logs

Collapse

• OpenSpand v0.1.0

  adam.klotblixt • 3 days ago • 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.
  

• Refactoring

  adam.klotblixt • 12/25/2024 at 18:33 • 0 comments

  I worked on refactoring the software quite a bit over Christmas, it is much better organized now.

  The manual has been heavily extended, with more to be added as the software functionality expands and finalizes.

  No nice pictures for this entry ;)
  

• It's working!

  adam.klotblixt • 12/17/2024 at 15:58 • 0 comments

  After some beep-testing, ocular verification and soldering the only fault I found was a mirrored pinout for the USB module. No problem, just mounted it upside down.

  Software testing showed that the new joystick and soft-reset/config button reading worked as expected. Nice, hadn't really tested it before!

  The only major fault I found was that the micro-SD module I used had a different pinout compared to the datasheet I used. 3 patch wires solved that. Not very good looking but serviceable.

  Next up is trimming the LED resistors to give enough light. The LEDs come from my old stash, so I had no datasheet for them and will have to test my way to a decent current.

  The PCB was fault free and I had no problem soldering everything. All faults were my own. I'll fix all the faults, make some improvements and make a final version later. Now it's time to work on the software and think hard on all the possible hardware improvements.
  

  I certainly won't hesitate ordering from PCBX.com again, it all went as smoothly as hoped.

• PCBs arrived!

  adam.klotblixt • 12/17/2024 at 10:14 • 0 comments

  The PCBs were delivered half an hour ago, wohoo! Time to verify some signals before soldering and testing everything. They look very good.

View all 13 project logs