Help with two Orics

[Chema]

I think Mike suggested using 150ms or faster.

http://forum.defence-force.net/viewtopi ... 029#p20546

Did you try his diagnostic ROM, btw? .

[protek]

Yeah, gotta try to source some faster ones or see if I can get lucky with the 4164s that I have.

I only tried iss’s diagnostic ROM. I should probably try Mike’s ROM too.

[protek]

Here’s how the screen looks like with the 4164 RAMs, btw. The b/w bars are different.

[protek]

Here is how the screen looks with MikeB’s ROM and 4164 chips. There’s a repeating pattern clearly. Also a constant tone is played out of the speaker.

[Chema]

Mmmm I don't remember Mike's ROM playing anything...

Just in case here is the manual: http://oric.signal11.org.uk/files/pub/d ... OM1-08.pdf
Let's see what he has to say...

[protek]

I consulted the manual, and I’m not getting what I interpret to be a clock signal on the ULA pin 7. The probe is just faintly high. Is the hex inverter the culprit?

[Chema]

No clock signal? IIRC pin 7 of ULA is connected to the 12MHz crystal oscillator. Maybe it is too fast? Check you get a 1MHz phi2 signal output at pin 14 of ULA...

If you don't, or if your oscilloscope should read the 12MHz signal, check the output of the crystal. But how does the ULA even make an image without the master clock?

You could also check RAS and CAS (pin 10 and 9 at the ULA, I think) signals arriving at the memory chips. They should be varying as memory is accessed. Just in case one is held up or down.

[protek]

Unfortunately, I don’t have an oscilloscope, just a logic probe. I’ll try the other pin on the ULA. RAS and CAS pins did give a pulse on my probe when I tried it.

Well, the hex inverter wasn’t the problem, or then I have two duff hex inverters. At least, I now have a socket for the inverter. It was a bitch to get off as my desoldering gun was clogged or something and simply didn’t suck the solder off, so I had to do it other way.

[mikeb]

Excellent screen shot!

That "junk" shows something important, even if it looks like rubbish.

Your "D3" data line is high at times when it should not be.

Observe all those ")" symbols. (Hex 0x28) that should be spaces (0x20). That's bit 3 of the data bus stuck high.

Now, for the mind blower

Your version above the correct text ....

Code: Select all

 Z K M \M LML
ORIC EXTENDED BASIC
 
Zmil
Ready

If you force bit 3 high in the original text, you get the scrambled rubbish on your screen.

So check everything on D3 carefully, IC16 DRAM chip especially.

[mikeb]

On the clocks etc. -- you must have a 12MHz clock (you have a coherent picture!) and further, you have a 1MHz clock out from the ULA, even if your logic probe thinks that's too fast to be "pulsing" because the machine has booted and run BASIC. Hard to do that without 1MHz clock.

My diag ROM -- shouldn't make any noises that early on, I suspect you are hearing the 8912 getting garbage data. Note, the first thing I do is a quick then slower RAM test, and if that fails, there's no point going further, so it will sulk at that point. Given the display on the screen, I'm not sure how that's happened -- if the data bus was truly stuck, I don't think Oric would boot (reading from ROM would be corrupted, for a start).

So I wonder if you can check that ULA pin 12 (D3) is actually connected to everything else (CPU p30, VIA p30, Pin 2 AND 14 of IC16 DRAM) with resistance check/continuity tester (powered off, obviously!)

It's almost like the machine is trying to work, but the ULA can't see straight (d3 high). Check from the actual pin on the chip, to make sure the ULA and socket are making contact!

What happens if you (blind) type on the keyboard (e.g. PING or ZAP (return), do you get any key click/cursor movement/screen update/sound?)

[Chema]

Mike, you rock!

[protek]

Wow, Mike, that is indeed mindblowing! Thanks! I’ll be checking the continuities later today.

As for the keyboard, I actually tried typing those commands but the keyboard isn’t very responsive. I’m able to type in maybe one or two keypresses as I suspect from the audible response I’m getting but then it goes quiet.

[protek]

I checked the continuities between your suggeste pins, and indeed there’s no continuity at all between ULA pin 12 and IC16 pins 2 qnd 14 leg pins. CPU and VIA have continuity with the ULA.

I did a quick visual inspection on the socket pin solder joints. The pin 14 joint on IC16 looks a bit dodgy, so I’ll redo at least that. I guess I have to go through the traces now.

[protek]

Okay, this is a bit perplexing. I look at the schematics and see that D3 that is pin12 on the ULA should be connected to IC16. But when I use my multimeter to check the continuity, the pin12 beeps with IC17 data lines. IC16 data lines beep with pin 13 on the ULA and pin 29 on the CPU and VIA. I suppose there’s a perfectly logical explanation to this but it does boggle me a bit as I’ve double checked and triple checked that I’m touching the correct pins on all chips.

[mikeb]

(Looks at bare Oric board ...)

For perfectly understandable reasons, you are on the wrong chip!

The DRAM chips are numbered, left to right

For D7, 6, 5, 4, 3, 2 1, D0 ...

IC 12,13,14,15,16,17,18,19



Only the outer two are numbered!

You have taken the numbering from the decoupling capacitor below the chip,

(Nothing), C14, C15, C16, C17, C18, [NOTHING], C20

... because someone ran out of space for the silk screening.

It's a good sign that typing is making keyclicks/response. It seems odd to have any kind of "working" Oric if the databus is stuffed like that, so I'm still leaning toward the ULA being unable to read the DRAM. If possible, swap IC 16 and 15 over (the middle pair of DRAM) and see if the sea of "(" turn to "0" characters (if it's the DRAM misbehaving, D4 will be stuffed instead!)

Otherwise, it might just be that the DRAM is a little slow, and is not asserting its output quick enough for the ULA to get it.

ETA: Weirder observation still -- after the CPU has had its share of DRAM access, the ULA accesses the DRAM twice per clock cycle/column of the screen. Once, to get an ASCII character ... e.g 0x20 for "SPACE", here misread as 0x28 ")" and then once more to look up the 8 separate bit patterns for the character, to make 8 scanlines worth of picture.

It mis-reads the first lookup, but it's getting the second lookup bit patterns right? Otherwise you would see corrupted fonts too.

Why, ULA, why?