Project Logs

Collapse

• ET-3400A Supported - 2 KBs over Expansion Header, Firmware v1.7

  Michael Wessel • a day ago • 0 comments

• PCB BUG!

  Michael Wessel • 2 days ago • 0 comments

  Unfortunately, the current version of PicoRAM Ultimate has a PCB bug: the position of the RE signal on the header is incorrect. Apologies for that.

  You can see that in the schematics here:

  When I wired up the IO header on my ET-3400, I flipped left and right and put it on pins 30 and 29 instead of 12 and 11, where they should have been.

  I only noticed now, with my new ET-3400A, which already came with the RE signal wired up on the IO header (I only had to install the data lines), that the position didn't match. And indeed, the ET-3400A schematics lists the RE pin positions as follows - you see the difference:

  There is an easy fix for this - don't use JP9, but a DuPont wire that runs directly into the breadboard RE signal, as shown in these pictures:

  Eventually, I will create a new PCB version with this bug fix. But for now, the workaround is sufficient.

• PicoRAM Ultimate Firmware V1.6 Released

  Michael Wessel • 01/10/2026 at 22:19 • 0 comments

  The new firmware supporting the ET-3400A is now online!

  https://github.com/lambdamikel/picoram-ultimate 

• PicoRAM and the 6808-Based ET-3400A

  Michael Wessel • 01/09/2026 at 23:20 • 0 comments

  ... got my hands on a Heathkit ET-3400A. This one has the much faster 6808 CPU. It took me a week to get the timing right, but eventually, I got there:

• Three new "first steps" videos for PicoRAM Ultimate: ET-3400 + MPF-1

  Michael Wessel • 01/01/2026 at 02:20 • 0 comments

  Happy New Year - I had committed to build a PicoRAM Ultimate for a fellow ET-3400 enthusiast, and am wrapping up the year 2025 with three "first steps" videos that I made for new users: 

  
  

• Nasty firmware bug fixed

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

  I had a pretty nasty firmware bug encountered during my RetroChallenge 2025/10 contribution:

  https://hackaday.io/project/204153-3d-graphics-on-the-microprofessor-mpf-1b

  Basically, I was getting glitches and random CPU failures (crashes, SYS-REG, ...) At first I thought these were caused by my MPF-GRAFX card, but it turned out to be an issue with PicoRAM. 

  
  This is fixed now:

  
  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 ULTIMATE.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 file. 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!
  
  So, it wasn't really a "firmware bug", as it worked as intended. But, I wasted a lot of time chasing red herrings because the spurious button presses were happening without me becoming aware of them. This specific ADC button level fell through the button decoding "switch / case" in the UI thread running on the second core, and a default case was missing - this is where the error message is being raised on the display now to make the user aware that his ADC threshold levels in the init files are inadequate. 

  Checkout the new firmware here: 

  https://github.com/lambdamikel/picoram-ultimate
  
  
  

• My first MC6800 program - Towers of Hanoi on the Heathkit!

  Michael Wessel • 06/28/2025 at 13:38 • 0 comments

  Well, that was a bit of work to get that running... getting to know the side effects of the built-in firmware / monitor routines for driving the keyboard and display are always a bit of work! I almost went insane yesterday when sequences of `PSHA`, `PSHB` and ` PULB` and `PULA` op-codes consistently "transmuted" into `PSHA`, `PSHA` and `PULB`, `PULB`, and only when actually *running* the code... turns out there was still something slightly off with PicoRAM's timing, that oddly only showed up when accessing the stack. At first I suspected that there was something wrong with the assembler, ASM80.org, or that push/pull are only supported for the `A` accumulator, and that the MC6800 "would correct" these op-code "on the flx". I then replaced PicoRAM with the original 2112 SRAMs, and saw that the problem went away too - ops! After 2 hours of PicoRAM debugging I found that I needed to remove a few `NOP`s... and, problem fxed! There is a new firmware version, 1.3: https://github.com/lambdamikel/picoram-ultimate/blob/main/firmware/v1.3/picoram_ultimate.uf2 

  Anyhow, after I understood how indexed addressing from the stack using `TSX` and `LDAA <offset>, X` works, I got it running - my first MC6800 assembly program. Thanks again to ASM80.org for hosting a very useful tool online. Here is the code, which might be instructive for anyhow trying to learn how utilize the ET-3400's built-in monitor / firmware ROM routines for their own programs:

  https://github.com/lambdamikel/picoram-ultimate/blob/main/software/et-3400/HANOI.A68
  
  I also uploaded the programs to the ET-3400 Google IO group here: 
  https://groups.io/g/ET-3400/files/9.%20Sample%20Programs/Towers%20of%20Hanoi%20Assembly%20and%20Hex

  And, a video too - enjoy! 

• New programs for the Lab-Volt 6502 CPU Trainer - Towers of Hanoi!

  Michael Wessel • 06/23/2025 at 23:41 • 0 comments

  I ported the 6502-version of the Towers of Hanoi from 
  https://rosettacode.org/wiki/Towers_of_Hanoi
  to the Lab-Volt trainer. 

  It was fun to study the manual and learn how to use the firmware routines for input & output! My HANOI.RAM program can be found on the PicoRAM Ultimate GitHub, as well as the ".a65" assembly source code:
  https://github.com/lambdamikel/picoram-ultimate 

  I am also briefly showing two other programs that I found in the Lab-Volt course book; one IO LED PIA test, and a program that adds two numbers and displays the result. These programs are also in the GitHub repo. Enjoy!

• New Firmware v1.2 Passes LabVolt RAM Test!

  Michael Wessel • 06/22/2025 at 19:48 • 0 comments

  I just learned (from reading the manual) that the LabVolt trainer comes with a built-in RAM test in ROM. So I tried it - and PicoRAM failed :-( Only "pages" `0x02` and `0x03` are user RAM on the LabVolt; page `0x00` is obviously the infamous 6502 Zero Page, and `0x04` is memory-mapped IO / hardware, specifically, the PIA sits there. As you know, in 6502 speak, a page corresponds to the high nibble of the 16 bit address, and hence, each page has 256 bytes. 

  To start the RAM test, you write the start page (`0x02`) into memory cell `0x0000`, and the end page (`0x03`) to `0x0001`. Then you start the program from the ROM address `0xF6B1`. The program then goes through all the test patterns (bytes  `0x00` to `0xFF`) and writes and reads back every memory cell in all pages (inclusive and) between start- and end-page; here, from `0x0200`  to ` 0x03FF`, 512 bytes of user RAM. 

  This test *failed* at first, and it failed quickly! It is surprising that the machine was working at all with the LabVOLT... I hence tweaked the firmware a bit by introducing two more `NOP`s when reading the address from the latches, and played with some GPIO settings. After a bit of back and forth, the RAM test finally succeeded! 
  

  The firmware version 1.2 has been uploaded to the GitHub repo.

• Firmware Update and PicoRAM Ultimate Galore!

  Michael Wessel • 06/21/2025 at 16:10 • 0 comments

  I fixed a slight firmware stability problem with the Microprofessor. The `CLOCK.RAM` program is a good stability test. It runs for hours now without any glitch / crash, so I am assuming that this problem has been fixed. At first I though it was due to noise or requiring 74F373 instead of the 74LS373, but these were red herrings. In the end, the GPIO slew rate and drive strength, as well as the hysteresis config were causing the problem. Fixed in Version 1.1 of the firmware now. And here is video showing all the machines with the new firmware:
  

View all 22 project logs