• Please review our updated Terms and Rules here

SOL-20 0909 PATTERN

I have attached the corrected diagrams , the two polarity forms of the circuit, that I should have attached the first time to include D12. I'm sorry I messed the first ones up, by leaving D12 out of the picture. As you can see it is very easy at a glance to see how the voltages come about in its negative ground format.
 

Attachments

  • polj.jpg
    polj.jpg
    114.7 KB · Views: 4
@Hugo Holden thanks for the updates and further useful information!

...I'm puzzled by the lack of meaningful and adequate Sol-20 service literature. I guess I'm pretty used to working with stuff like Sams Photofacts, which provided extensive waveforms and troubleshooting guidelines, so the lack of those things given the extensive documentation otherwise, is surprising.

I plan to continue to try to trace signals from the P module up to the CPU, as well as more thorough testing of chip voltages, in the hopes of tracking down the fault, but my suspicions still stand that I may have damaged ROMs on my Personality modules. I plan to follow the paths according to the block diagram branching out from the ROM.

I do know that prior to this condition, I was having no success in seeing or talking to or from the serial port, which I believe is governed by the module.
 
Last edited:
I'm not sure which personality modules you have. There were a few variants. They can be checked by reading the ROM's in some cases, where they are not the MM5204 (unless you have Martin Eberhard's programmer) and the encoder logic/chip select circuit can be checked.

My preferred version of the module was the one with the MM5204's because my SOL came with this version and for some reason I warmed to these more obscure UVEPROM's. So I built Martin's programmer, he can supply the BOM, the programmed IC with a copy of its firmware and the pcb & his super detailed professional grade manual.

I wrote an article a while back on this module and how the chip select circuit works, it is an interesting design doing it with a 74LS155:


I managed to get the replica pretty close to the original with my usual method of tracing over the tracks in a drawing program.

Also these different personality modules were being sold in Australia with SOLOS & DPMON in them (the latter I am not familiar with). The seller probably still has them though I cannot see an active listing:


On the topic of faulty serial ports, I have had these in both the SOL-20 and my IBM 5155. In both cases the transceiver IC's were damaged. One reason I think these get ESD damaged by plugging long lengths of electrostatically charged cables, or perhaps by "hot plugging" where the other device does not have its negative supply at ground potential , but floating and there are transient currents into the computer's serial port when they connect.
When I found the defective IC in my 5155 I did not have the IC type in my stocks (shock & horror) and had to order it, but in the meantime I found a way to repair it with a spare gate:

 
The 909090 pattern means the CPU is running properly and has fetched a RST 7 instruction (0xFF) at some point. Upon fetching RST 7, the CPU jumps to location 0x38 and, in this case, also fetches an RST 7 (0xFF) at that location. From then on, the CPU pushes 0x39, 0x00 onto the stack over and over because it keeps fetching another RST 7 instruction at location 0x38 and 0x0039 is the return address. This eventually fills all of RAM, including video memory, with 0x39 0x00 which results in the 909090 pattern on the display.

I assume you have no RAM at location 0x38 (i.e., no RAM in the S-100 bus), right? That is fine when getting the machine up and running and also ensures we get a 0xFF at location 0x38 as required for some of testing procedures in the manual.

The question to be answered is why is your machine encountering 0xFF during an instruction fetch? There are all sorts of possible reasons for this. For starters:

1) As already mentioned, if the ROM on the personality module does not respond, then 0xFF is seen and that causes the 909090 pattern.

2) If system RAM at 0xC800-0xCBFF is bad, then the first time the SOLOS ROM calls a subroutine, the RET instruction could easily end up in address space with no RAM (all addresses other than 0xC000-0xCFFF). This, in turn, will fetch 0xFF and generate the 909090 pattern.

3) If the PHANTOM circuit is not working properly (look for PHANTOM to go low for four CPU cycles after RESET is released), then the CPU does not execute SOLOS from the personality ROM and, in turn, generate the 909090 display.

4) Related directly to PHANTOM, if any of the ICs in the logic chain for generating the PAGE C0 signal (U24, U22, U34) are bad, the CPU will not execute SOLOS, which, in turn, generates the 909090 display.

5) Issues with the data input muxes or the logic that generates the mux select lines could also result in the CPU seeing 0xFF instead of actual data.

Mike
 
@Hugo Holden
I have the 5204 and 2708 modules. The 5204 came with the Sol and initially worked for the most part. The 2708 is an ebay purchase but was sold as untested. The completed ebay auction you saw was for the one I recently purchased as well. That should be landing soon, and perhaps it will turn out that's the only working one. I don't have any EPROM programmers, but have read your article about the Eberhard version which sounds like it could be useful, although I assume it's Windows based and I'm on a Mac.

By "transceiver" do you mean the UART, or is it U38? I did swap the serial UART with the parallel, and the unseen serial problem remained.
 
@deramp5113
Thanks for the definitive answer about the 9090 pattern!

You're correct. I'm not running any cards installed on the S-100 bus, but if I do install the 16KRA card anywhere on the bus, instead of the 9090 pattern, I get random characters instead, upon booting.

Re:
1) I will try the new P module when I have it in my possession.
2) I'm not sure if this disproves if the RAM is bad, but I did try swapping U3-10 with U14-21 and there was no change.
3) I tried swapping U76 with a couple other 74LS175 chip and it made no difference. I tried pulling the phantom jumper as well.
4) Swapped U34 w/U35 and no change

5) Will probe around these sections and see what I can find...TBA
 
Mike,

That is a really good description of the things that could do the 90909090 pattern.
In my SOL it was U24 that had failed I think, I would have to look at my notes.
 
Some waveforms. These are with or without the Personality module inserted. When reset DIP switch is pushed, these all "flatline"

CPU/Pin 12/Reset

CPU_12.PNG

U22/8,11
u22_8.PNG

U22_11.PNG

U23/6

U23_6.PNG


U24/12,13
U24_12.PNG

U24_13.jpg
 
By "transceiver" do you mean the UART, or is it U38? I did swap the serial UART with the parallel, and the unseen serial problem remained.
I think it was a 1489 IC that was defective in my SOL, I'm away from home so I would have to look at my notes when I get back:


In the case of my sol the UARTs were ok, except for the fact they were TI types with silver plated steel pins that were falling off the sides of the IC's. They had rusted horribly, so I replaced them with new UARTS.

So I ended up buying a stack of equivalent UARTS, for my IC stocks, because I can't stand not having spare parts.

Actually, when I got my SOL, some pins had broken off the side of the CPU too, so I had to replace the CPU. In many ways it was like an Archeological dig to find the Dinosaur bones, but in the case of the SOL I could bring it back to life and that is the fun of vintage computers I think. Getting something old and broken and fixing it.

If every vintage computer you got was working off the bat, then where would the challenge be in that ?
 
Some waveforms.
You need to look at following signals during the 1st four cycles after RESET is released:

1) U24p1, U24p2
2) U22p3, U22p11

This will require a storage or digital scope.

Mike
 
@deramp5113
I haven't used the storage function, but I have another Tek scope, a little 224, which is an early portable digital.
This will be a good opportunity to try to use that function.

Am I looking for low states on all 4 pins for 4 cycles after RESET? I'm not sure what four cycles looks like in this case, but maybe it will be self evident.
 
Use the release of reset as your trigger and set time scale to capture about 4us-8us across the sweep.This should get the first four cycles.

U24p1 should be low during the first four cycles, U24p2 should be high.
I’d expect U22p3, U22p11 to be low most of the time during the first four cycles.

Mike
 
@deramp5113 Thanks!
BTW, have you ever heard of a Personality module failing, in your experience?
I'm not sure what others would say about this.

When I got my SOL with the four MM5204's in it, they had very poor thin paper covers over the windows letting in light. I was pretty sure the data was going to be corrupt. I replaced the covers with sticky aluminium builders tape.

But, to my surprise they were actually all ok, despite that.

I also bought another module version (old) it worked, and also that Australian module works fine too.

I'm just guessing here, but I think most likely both your modules are ok, rather than both being defective, but you will find out for sure when that new module arrives. Probably the 9090 thing has one of the other causes @deramp5113 has suggested, but the modules are not yet excluded.

( It might be possible to relentlessly strobe the reset line with a function generator to make the pulses you are looking for repetitive enough to see on a standard scope easily, since its a composite video signal out of the sol, the VDU cannot be harmed if it is erratic, but you could disconnect it anyway).
 
Last edited:
Still plinking around on the board. I’m comfortable at this point rolling out bad system RAM chips just based on subbing all of them for NOS ones and verifying continuities and signals to the best of my knowledge. Tried the reset technique as deramp suggested but i think my old digital scope isn’t cutting the mustard. The states on reset can be seen but not immediately after releasing the reset. Either my Store function isn’t smart enough or I’m not.

As far as strobing the reset, great idea, but I don’t have an appropriate function generator. A sine waveform generator for RF, yes, but it’s tube and the signal is way dirty.

I’m tempted to replace all the tantalums, including C15 which is part of the restart circuit. But in the meantime I’m going to shift some attention to the Address/Page section.

Yeah, certainly possible my P modules are ok. I can clearly see data coming from the ROM chips being sent to RAM.
 
Well, the new dual Personality card arrived today. I put that sucker in, but no dice. Not much of a surprise there. At least that avenue can be ruled out.
 
OK, so here's a rundown of where I'm at.

Assumptions:
  • System RAM appear ok
  • Video RAM ok
  • Clock ok
  • CPU ok
  • Personality modules assumed ok
  • PSU Supplies ok, although there is occasional "sag" at certain times, below 4.75v
Further investigation:
  • Data not seen on address line pins 5-8 at CPU. Not sure if this is normal - perhaps these addresses are used for something else? Need to trace these back through the buss drivers, the RAM, back to the ROM.
  • Pull the board and replace Tantalums
  • Check all solder connections on reverse, especially near connectors J11 and 5.
 
When you say, “Data not seen on address line pins 5-8 at CPU,” do you mean on a scope you see no transitions when measured drectly on the CPU pins? If so, what idle voltage are you are seeing?
 
When you say, “Data not seen on address line pins 5-8 at CPU,” do you mean on a scope you see no transitions when measured drectly on the CPU pins? If so, what idle voltage are you are seeing?
Since the above reading, I had gone back and tested those pins again with a logic probe. It looks like all the pins except for 3, 4, 5 were "floating" at 1.6-2v.

I have put every single chip I can test on the tester (7400 and 400 series) and 3 chips were bad (according to the tester), but they were in the video section, so I don't think they have anything to do with the "stack crash" as Lee Felsenstein calls it.

I don't want to run the machine again until I can replace those chips, and then go back and start tracing logic states down to the RAM. Most likely, it's one of the 2102 RAM chips or 8T97s buffers that's bad and an address simply can't be seen. According to LF, it's either a missing address or the ROM, and we've ruled out the RAM. If not, then perhaps a bad socket.
 
Back
Top