When you're NOT in load mode, the LOAD_N2 line should be low (until an OUT instruction pulses N2).
The strobe to the LED shouldn't be happening all the time. Check that diode OR gate...???
From: email@example.com <firstname.lastname@example.org> on behalf of John Kennedy <johntkennedy@...>
Sent: Thursday, September 24, 2020 12:46 PM
To: email@example.com <firstname.lastname@example.org>
Subject: Re: [cosmacelf] Noob question: examine arbitrary memory address? #ELF #Memory
Current theory (may be nonsense ;-) -
Problem: I can’t display specific values on the LED displays using the 1802 out command, as expected.
* The original design the RC1802 used TIL311 displays, which are awesome (now vintage) LED displays with built-in logic (and a thirst for power).
* The RC1802 design replaces the TIL311s with a pair of common cathode 7-segment LED displays, with a driver IC for each.
* The design of the RC1802 works fine for displaying values when input from the switches, and when examining memory.
* The design does not support using out commands to display values on the display, because the TIL and 7-segment ICs work in a different way. The LEDs in the RC1802 system are being updated all the time, rather than latching.
* Or I screwed up :)
Problem: I can’t get the IDIOT/4 monitor to work, no matter which of the four versions and jumper combinations and baud rate settings I try. I have added other code to the same EEPROM and that works fine.
* The serial loop back test code works fine, so the electronics are _probably_ ok.
* Hard coding an app that does nothing but spit out “Hello” at 300 baud works.
I’m guessing that the monitor code tries to measure the baud rate based on the user entering a characters. However, for whatever reason, this isn’t working. Perhaps the speed of my board is just not accurate enough for the monitor to get that calculation working. Perhaps I screwed up something.
problem: The memory map isn’t decoded perfectly, in that a 32K EEPROM in socket 2 is mapped from 8000h up, but the first 0000 to 4000h addresses in the EEPROM are ignored. When programming the ROM, it’s therefore necessary to start at the ROM’s internal address at 4000h (wasting the entire first half of the chip) with code assuming it will be running at 8000h. I’ve not yet been able to check the RAM memory map as I can’t easily display diagnostics (see above two problems :-) )
I await other people finishing their own boards to see what works for them!