2026-07-15

All chips for minimal system in. 

Power, ground and all chips on the left of the 6522 seemed shorted when buzzed, but hi-z when resistance measured. Multimeter battery measured 2.2 volts, so changed for fresh and the buzzed-shorts went away.

Applied power. No magic smoke. Power LED on. Current draw is 1.16 amps (CMOS CPU fitted).

Next step: apply logic probe to check signals that should be pulsing are actually pulsing.

Frequencies on pins 17, 18 and 19 of the timing PAL are correct.

Frequencies on the CRTC chip:

VSYNC (40) = 50 Hz
HSYNC (39) = 15.625 kHz
DE (18) = 10000 = 200 * 50 Hz
CCLK (21) = 1.875 MHz

DRAM /RAS (4) = 1.841 MHz

So it looks like the system got as far as running the code in the ROM to initialise the CRTC.

Next step: Check the video output.

2026-07-16

Kludged a phono socket on, fed it to a small TV.

And here is the video:

The startup switched are all open, selecting video with minimal RAM disk.

If switch 4 is closed, selecting serial port, the video is not initialised as above. If the RAM is not working then it probably won't be able to call serial I/O subroutines properly.

I'm using a 29.5 MHz oscillator so the timings are proportionally slower, and these small tellies never had great timing.

Looks like the CRTC has been initialised, but not the video RAM. The video patterns look like DRAM start-up. 

Removing or swapping the ROM chips has the same effect, no video. So I believe the CPU is waking healthy enough to program the CRTC.

If all RAM chips are removed, the pixels are all white. Which suggests the DRAM bits are being read and the shift registers are working.

Removing all the RAM chips, and shorting individual data outputs to grounds should produce dark narrow vertical lines. It does for most, but not IC47, 73 and 74.

I then notice I have 18 RAM chips, not 16. IC47 is listed as a spare, and IC74 is not listed at all so presumably this is a spare too. So that leaves IC73 suspect. If pin 14 is connected to a known-good ground, the vertical stripe appears so it is connected to the shift register. Pin 16 is not connected to ground. 

Visible bad joint corrected, but behaviour is like before. Occasionally there is flickering of the background, perhaps random writes to the background colour register. 

I also sometimes get this screen mode:

2026-07-17

I fitted a LED in JP3 and U18 which drives the LED. 

Test results:

Test 0: 

Centronics latch pin, DAC latch pin, Video latch pin, Analog multiplexer latch pin (Relay coil control, LED), all pulsing low.

Fails with bus error if PCB flexed. Address pins go hi-z.

Test 1: SCC

U64.12 pulsing low. LED pulsing for a while. 

Fails with bus error if PCB flexed.

Test 3: CRTC. Blinks LED.

Test 4: IPORT. Blinks LED.

So far, so good. Now the failures.

Test 7: No LED blinking, but that is normal.

Tfails to increments border and screen colours in 320 mode, or display character set in 640 mode, or draws coloured line test pattern in 320 mode.

U64 (an LS139) pins 2, 3, 13, 14 pulsing low (A8, A9). Pins 4,5,6,7, 9,10,11,12 all high because pins 1 and 15 are high. No I/O devices are being selected. /AS, /UDS and /LDS are active, but not accessing DRAM. It is looping in ROM.

Test 2: VIA pin 23 /CS pulsing, but only for a few LED pulse cycles.

Test 5: Read / write memory: LED pulsed for 8 cycles. Bus error (U33 pin 5 low).

This test does not even start LED blinking if the previous test 7 was run and a soft reset done. 

Serial port tests

I attached a USB-to-TTL-serial cable. 

Test 1: LED blinks but no serial port traffic. 

Looking at the code, the SCC test is very primitive, it just reads and write a byte to the SCC. It does not initialise the SCC to open a communication channel.

So now I am wondering what to do. 

I suspect that the dual-ported DRAM is at fault, being the most complex section. Without it, not only does video fail but so does everything else that relies upon it.

The test routines are very primitive, and rely on the centronics port as an output. This in turn requires some LEDs to observe what is happening. Even then, bits will be toggling so fast that their behaviour is a blur.

Some kind of report code on 7-segment display would be good. 

Other ideas would be a 2x16 text LCD, or a FIFO-USB interface.

Some static RAM would be very useful to hold  the stack and some test code variables. Two 512K SRAM chips would hold the entire system RAM and work without the video display.

Ideally I'd like the system to run headless and then run a diagnostic program on the video system.

Bug report

Forthnuter reported that his VPAL (my extracted equations in a  GAL16V8) was not working correctly. No text on startup screen. The original VPAL 16R8 did work. 

I'm certain I read the fuse map correctly. So two possible issues:

1. I mucked up converting the disassembled equations into human-friendly equations
2. Speed issue due to modern GAL chips being faster than old PAL

Fortunately I still have the original PAL chips so I can gave them a try. It made no difference.

I moved the RAM address link to the 1 Megaword block before the ROM. The system behaves as before, the CRTC initialised but the DRAM data is not. 

The CPU thinks it is writing to the DRAM, and it seems that way because /WE, /RAS and /CAS are toggling.

CPU data transceiver direction pin check:
U28,30 pins 1 and 19 are connected to /DBRE from U55.3.
U55.1 connects to TPAL.16 (/DTACKR i.e. DTACK for RAM)
U55.2 connects to  U54.12 ((/RD)

/RAMWE signal check:
U55.13 from /DATACKR (TPAL.16)
U55.12 from R/!W (U51.8 and CPU.9)
U55.11 to /RAMWE (DRAM.3)

Checking the 74LS253 chips I used instead of the 74LS153 cinp have similar switching times. Yes they do. About 11 ns maximum at 25°C.

I conclude that the DRAM is not working for some reason and I need better test programs. I could write them in assembler and keep blowing them into Flash ROM, but that is a chore.

A CPU with working RAM would be useful to prove that the rest of the system is basically working, and be able to load and run some better test programs.

Reluctantly, I'm going to try piggy-backing some SRAM over the ROM chips. Ironically this should be double the the size of the SRAM.