• Please review our updated Terms and Rules here

Dead 2001

It should boot - but you will get no keyboard activity or flashing cursor.

This is all done in interrupt code as a result of an interrupt generated by one of the PIA or VIA devices.

Dave
 
Cool, thanks Dave. Assumed as much but not 100% sure the IO was needed to turn some signal on or off to enable something. I did 3 different sets of quick tests (NOP Generator, PET diagnostics, RAM/ROM replacement), to get a quick feel where to focus.

I'll describe these 3, individually, in the following 3 posts.
 
There are a couple of signals floating (the important one being GRAPHIC on the BUSINESS variant)...

Dave
 
NOP Generator

2001-NOP Generator.jpg

With the 3 IO chips removed, I plugged a NOP Generator in, and found the following:
.
- Reset, clock (39, 37, 3), /NMI, /IRQ and Sync all good on CPU
- All Address lines show expected NOP square waves
- BA address lines show expected square waves. However, signals quite noisy with 3 levels seen. I assume this is normal when the buffers (E3, E4, E5) can go into such as state. (But I'm guessing here).
- Address decoder (G2) gives expected outputs on all 15 outputs.
- Gates in E2, G3, J9 seems OK.
- All the buffers (E3, E4, E5, G5, G6, H8, H9) "looks" OK. I.e. nothing is obviously dead but with two buffers per line, I'm not sure.
- RAM CS (I9) gives outputs to each RAM bank.
.
Basically I probed where I could to check address decoding around the RAM and ROM with the NOPs running. I did not specifically check the decoding to the IO chips yet. From what I could see most signals seem to be what's expected. The buffered data buses looks a bit messy and the RAM bus (BBD0-7) looks suspect. Suspect faulty 2114s? But, with the NOP generator, would the data bus be in a known state?
 
Last edited:
RAM/ROM Replacement

With nothing obviously very broken, I plugged a Tynemouth RAM/ROM replacement board in.

2001 RAM-ROM.jpg

Here I got some confusing results. I've only ever used this board in a 8032, so I might be having some finger trouble with the DIP switches. (Though it's not that complicated)

- In most tests, the screen did not clear and stayed on the random characters screen. I.e. it seems the CPU is not clearing the screen. This was with (what I think) both the PET ROMs or PETTESTER enabled.
- However, there was a burst on the CPU Sync output, so it was executing code up to some point. About 35ms worth of activity before it stopped.
- During this setup, when I press reset, the screen would show a screen filled with a single character. The characters would vary but always the same character filled the whole screen. So it seems, the VRAM was being written. This was also with the PETTESTER enabled, so could be Dave's routine that ran for a while.
.
- Then, at some point (might well have been after changing DIP switches), she would boot but drop into the monitor. I could not get any other effect so went to test 3 below.
.
To be honest, I need to redo this and be better to note what (if anything) changed. Not happy with the random flipping of dip switches and/or test results.
 
Last edited:
Tynemouth PET Diagnostics

At this point, I plugged in the Tynemouth PET Diagnostics. This is a little microcontroller that sits in the 6502 socket and essentially exercise all the output lines connected to the 6502 and measuring the input lines. It's a bloody brilliant way of testing a PET.

2001-Tynemouth-01.jpg

The above shows that there does not seem to be stuck lines on the AD and Data buses. Reset, IRQ, NMI all good.

However, note the lower case character in the 1st position of the on-screen text.........need to think about this one.........

2001-Tynemouth-02.jpg

The RAM tests shows significant failures on nearly all addresses / bits. According to this, all sixteen 2114s are broken. Likely? Not sure.......
With no ROMs plugged in, no ROM checksums are positive. But watch what happens next.

2001-Tynemouth-03.jpg

Not sure what test the Tynemouth Diagnostic thingy does next but suddenly the screen goes wonky. Something with testing the video circuit perhaps?

2001-Tynemouth-04.jpg
2001-Tynemouth-05.jpg

Again, not 100% sure what is tested here, think it's printing the different character sets. Seems mostly OK except for the lower case on each 1st letter in the header.
 
Last edited:
From the above:

- I could not (quickly) find any (obviously) broken logic chips around the AD decoding circuits.
- I do think something is still broken with the video circuit. The Char ROM tested fine outside the machine, could be the socket?
- Why would the first char (after a space?) be lower case?
- Tynemouth throws up LOTS of RAM errors.
- The buffered data bus looks messy.
- Why won't it boot or why does it drop to ML with the RAM/ROM replacement?
- Why won't PETTESTER run?
.
^^ My musings to figure out what to do next. I did these quick tests to give a high-level dump of the state of the machine, so now need to start thinking carefully where to start.
.
As always, your wisdom and guidance will be greatly appreciated! 🙏
 
First things first...

The PETTester in the Tynemouth board is NOT my code... Hence, it will not work the same as my code - because it isn't my code! Someone has asked for my PETTESTER to be incorporated into the Tynemouth board - but to no avail.

The PETTester code is either Eudi's original or dave_m's 'hacked' version.

The other potential issue is the one I warned you about regarding the GRAPHICS signal. Removal of the VIA can confuse the display...

Dave
 
daver2 said:
First things first...

The PETTester in the Tynemouth board is NOT my code... Hence, it will not work the same as my code - because it isn't my code! Someone has asked for my PETTESTER to be incorporated into the Tynemouth board - but to no avail.

The PETTester code is either Eudi's original or dave_m's 'hacked' version.

The other potential issue is the one I warned you about regarding the GRAPHICS signal. Removal of the VIA can confuse the display...

Dave
Click to expand...
I need to build another Welte board, then I can run V4. I'll try and configure the Tynemouth board to just run Kernal and plug my 2816 V4 into the board.

If I plug in a 6522, will it keep the B/G signal stable? Will definitely try it.
 
Last edited:
>>> If I plug in a 6522, will it keep the B/G signal stable? Will definitely try it.

That should work...

It should just be the GRAPHIC signal that 'sneaks' into the character generator. It normally doesn't matter (the signal floats HIGH) - but once or twice it has caught people out... Presumably marginal ICs or an electrically noisy environment?

Dave
 
daver2 said:
>>> If I plug in a 6522, will it keep the B/G signal stable? Will definitely try it.

That should work...

It should just be the GRAPHIC signal that 'sneaks' into the character generator. It normally doesn't matter (the signal floats HIGH) - but once or twice it has caught people out... Presumably marginal ICs or an electrically noisy environment?

Dave
Click to expand...
But it should not account for the ROMs / PETTESTER booting up, right?
 
daver2 said:
What character were you getting with the PETTester ROM mapped in?

Dave
Click to expand...
Initially it was either a b or g and I thought it's PETTESTER that was writing it, but in subsequent reboots it was all over the show, m, k and even graphics characters.
I'll need to run another set of tests to see if I can get better results. Will try and get V4 running.
.
The common symptom though was that it did not display the screen of uniform characters UNTIL I pressed and kept reset in (another good reason to have a reset switch :) ).
In other words, the machine would turn on, display the normal boot screen of random characters and never clear the screen. Then, when reset is pressed and held, it will display the full screen of uniform characters.
 
Last edited:
Managed to figure out the dip switches on the RAM/ROM replacement board and observed the following:

All the onboard RAM seems to be bad, have to map RAM out to the replacement board.

- With BASIC 1 or BASIC 2, I get a blank screen after the startup random characters are cleared. The CPU keeps running (pin-7 is active) but only a blank display. This is with or without the 3 IO chips in place.
- With BASIC 4 and the 3 IO chips removed, the system drops to the ML monitor.
- With BASIC 4 and PIA #1 (G8) plugged in, I get the BASIC boot prompt. No cursor.

With PETTESTER V4 installed, I get the following output:

(PS. These are screenshots from a video, need to figure out how to upload videos)

2001 PETTESTER V4-01.jpg

2001 PETTESTER V4-02.jpg

2001 PETTESTER V4-03.jpg

2001 PETTESTER V4-04.jpg

2001 PETTESTER V4-05.jpg

In the video, you can see that on-screen characters change as the test run.
 
OK, So I would proceed as follows:

I assume you have already tested the Buffered Address lines (BAn) as I see reference to that previously. The ROM and RAM are addressed via the BAn signals.

You must have installed my PETTESTER into the onboard PET ROM. Yes?

Remove any superfluous ROMs.

Remove all RAM apart from I8 and J8. This RAM responds to addresses between $0000 to $03FF (i.e. incorporates pages 0 and 1).

Test using PETTESTER.

It looks like the video RAM 2114 devices are fine (otherwise my test wouldn't move on passed the VDU RAM test)...

As a result, you should be able to test the 2114 RAM in the VDU RAM socket. Pick ONE of the VDU RAM devices to use as a testbed. You don't want to change more than one device at any one time. I suppose the dumb question is whether the video RAM is socketed or not?

If the video RAM is not socketed, you will have to perform the testing in the main RAM I8 and J8 sockets.

It is interesting that (on the first test) the data returned is always a character 'm' = $4D = 0100 1101. It would be worth checking the buffered buffered data lines (BBDn) signals on the RAMs themselves and see what is being written to the RAMs and read from the RAMs. Pick one RAM device (say I8) and look at that. The patterns that are written into (and expected from) the RAM are in my PETTESTER documentation.

Note that there are two (2) data buffers between I8 and the CPU data bus (H8 and G5). This is similar for J8. It could be that one (or both) of these data bus buffers are dead... That would be the more likely possibility than a whole load of dead 2114 devices...

The other way is to write a noddy test program to write one value into address $0000 and read the value back. Then probe that address...

Dave
 
Last edited:
Thanks Dave,

- BAx looked good with the NOP generator installed.
- Yes, I installed PETTESTER V4 onto the motherboard while other ROMs were mapped out with the RAM/ROM replacement board.
- All 16 system RAM chips soldered in. Contemplating unsoldering / snipping them all out. Suspect it's best to just go ahead and do them all.
- Video RAM replaced so should be good.
I'm kinda at the point where I need to decide to just bite the bullet and replace/socket all the System RAM.

Let me look into this further:

"It is interesting that (on the first test) the data returned is always a character 'm' = $4D = 0100 1101. It would be worth checking the buffered buffered data lines (BBDn) signals on the RAMs themselves and see what is being written to the RAMs and read from the RAMs. Pick one RAM device (say I8) and look at that. The patterns that are written into (and expected from) the RAM are in my PETTESTER documentation."20230502_172705.jpg
 
I would (personally) resist the temptation to do a 'hatchet' job on the 2114 system RAM if it is a duff data bus buffer (or two)...

I am going out shortly, but will suggest a couple of things to look at tomorrow. But you seem smart enough to work it out for yourself...

Actually, we can rule out G5 and G6 (generating BDn) because the video RAM hangs off this bus - and that tests fine with PETTESTER.

If there was a fault with the data bus buffers it would be in H8 or H9...

Just do a few 'thought experiments' to rule out what it can't be...

Dave
 
You must log in or register to reply here.
Back
Top