New Member and New Oric Atmos Owner

[SpaceFlightOrange]

Y'know. I only noticed the via when I uploaded the image earlier. must have accidentally caught it when I was using the desoldering gun.

I'll check both, and report back. Thanks

[SpaceFlightOrange]

No change. The cap wasn't touching. just looks like it from that angle, though I did lift it a little. pushing the cap against the board doesn't get the pins to touch.

I filled the via.

I have noticed the image does change every time you start it up.

IMG_0149.JPEG (1.86 MiB) Viewed 3495 times

IMG_0150.JPEG (1.4 MiB) Viewed 3495 times

on the lower image there was a bit of activity including a flashing block (kinda like a cursor?)

****EDIT****


Now this is a really stupid question, but this negative 5v rail is confusing me. If I hook up my scope, can you recommend a good location for the ground clip? I'm also new to the scope as well as the oric. I know this doesn't inspire confidence, but we all learn through our mistakes

I've also noticed that theres a bunch of mods missing from the underside. worth doing those too?

IMG_0152.jpg (5.06 MiB) Viewed 3492 times

[mikeb]

The first of your two pictures above makes me think you must have used Chinese DRAM, it's come preloaded with pictograms !

The flashing cursor-like thing is probably just a byproduct of an accidental "flashing attribute" found in junk in memory, and doesn't mean anything significant (other than the ULA has read that, and is making a flashy bit of picture) ...

As to where to probe, if you have a scope, look at the data lines D0 through D7 (anywhere you can find them easily, pin 2 of each DRAM chip) and see if they all have similar activity. They should be busy, as even if the CPU and ROM are dead, the ULA is clearly hauling data from RAM and making pictures. Expect to see similar height and shape on all 8 data lines.

You should see pin 1 of the ULA waggling between ROW and COL address selection, at three time per microsecond, as it allows the 6502 address (in two halves) followed by the ULA (in two halves, twice!) a go at memory.

Pin 3, 4 of the DRAM chips should all show a clear 3-per-microscond pattern (ROW enable, COLumn enable) ...

The display looks better now, but still quite filled with random stuff. However, it's possible as these are non-original chips, that might be their correct powerup behaviour -- the classic white bars pattern seems to be lost when you start swapping out DRAM for other manufacturers.

[SpaceFlightOrange]

The first of your two pictures above makes me think you must have used Chinese DRAM, it's come preloaded with pictograms !

you're right, it did come from China. It's branded Micron USA and is (supposedly) the same MT4264-15 as originally in it, but im taking that with a pinch of salt

As to where to probe, if you have a scope, look at the data lines D0 through D7 (anywhere you can find them easily, pin 2 of each DRAM chip) and see if they all have similar activity. They should be busy, as even if the CPU and ROM are dead, the ULA is clearly hauling data from RAM and making pictures. Expect to see similar height and shape on all 8 data lines.

You should see pin 1 of the ULA waggling between ROW and COL address selection, at three time per microsecond, as it allows the 6502 address (in two halves) followed by the ULA (in two halves, twice!) a go at memory.

Pin 3, 4 of the DRAM chips should all show a clear 3-per-microscond pattern (ROW enable, COLumn enable) ...

The display looks better now, but still quite filled with random stuff. However, it's possible as these are non-original chips, that might be their correct powerup behaviour -- the classic white bars pattern seems to be lost when you start swapping out DRAM for other manufacturers.

Thanks Mike. I've updated my last post about the missing mods from the underside, but also I feel really stupid asking but can you recommend a good solid place to connect the ground clip? I feel a lot less confident with this than with a spectrum due the regulator outputting -5v

Thanks

[SpaceFlightOrange]

Right. I've had the scope out, across all the ram chips, on pin 2 and the signal was dancing around and I couldn't stabilise it but they all looked pretty similar:

IC12_pin2.jpg (145.5 KiB) Viewed 3477 times

the main difference was IC18, but I read in the service manual the this is expected:

IC18_pin2.jpg (152.26 KiB) Viewed 3477 times

This is pin 1 of the ULA:

pic_30_9.jpg (137.6 KiB) Viewed 3477 times

[SpaceFlightOrange]

I checked Pin 3 and I get this fairly consistently across all ram (this is IC12):

IC12_Pin3.jpg (130.02 KiB) Viewed 3477 times

On pin 4 (RAS) I get this, again consistently:

IC12_Pin4.jpg (143.83 KiB) Viewed 3477 times

I was a little concerned about this as the pulse width is 165ns but the data sheet says that 150 is the min pulse width. Im new to all this to be honest so im probably barking up the wrong tree here.

[SpaceFlightOrange]

I measured the clock signals all round and they look fine.

I have one question though. This is pin 3 of the CPU:

CPU_pin3.jpg (135.5 KiB) Viewed 3477 times

And this is pin 39:

CPU_pin39.jpg (136.54 KiB) Viewed 3477 times

The shape is very different. Is this correct?


Thanks

[SpaceFlightOrange]

Final Update for tonight.

This is the clock signal on pin7 of the ULA:

IC7_pin7.jpg (145.52 KiB) Viewed 3467 times

and this is one of the CPU address lines. They are all pretty much like this; some are flatter, but they are all up around this level.

AddressLine.jpg (134.96 KiB) Viewed 3467 times

[Chema]

Mmmm I am not sure that pin 3 signal is correct. Isn't that the WRITE signal? If it is, then it goes out directly from the ULA. Maybe the ULA is not working or there is something in that track.

Also the address lines should be jumping from 0s to 1s. They seem to be held high, as that pin 3.

You said you tested that ULA in another Oric, or a working ULA in this one?

[SpaceFlightOrange]

Mmmm I am not sure that pin 3 signal is correct. Isn't that the WRITE signal? If it is, then it goes out directly from the ULA. Maybe the ULA is not working or there is something in that track.

Also the address lines should be jumping from 0s to 1s. They seem to be held high, as that pin 3.

You said you tested that ULA in another Oric, or a working ULA in this one?

pin 3 of the 6502 is the clock output. or did you mean pin3 of the ram?

This ULA is the original from this machine. I only have this machine. I do have another ULA, I bought recently, but I haven't tried it yet. I'm also waiting for a replacement ROM to arrive. should be here in a day or 2, from Spain, as it happens

[Chema]

I meant the memory's pin 3. I think you should be seeing variations from high to low when the rom initializes things or when the ULA reads the screen memory. Also the /WRITE signal cannot be high all the time.

Maybe it is worth checking those tracks for something that might be pulling them up, or cuts that leaves them floating...

[mikeb]

Mmmm I am not sure that pin 3 signal is correct. Isn't that the WRITE signal? If it is, then it goes out directly from the ULA. Maybe the ULA is not working or there is something in that track.

Also the address lines should be jumping from 0s to 1s. They seem to be held high, as that pin 3.

You said you tested that ULA in another Oric, or a working ULA in this one?

First: Apologies, I meant pin 4 and 15 of the DRAM (RAS, CAS) not pin 3 (Write Enable)

Second: Chema -- it's actually perfectly possible that pin 3 ((Write Enable) is high all the time CORRECTLY, it would only go low for a write to DRAM. High all the time means nothing is being written. This is possibly because the ROM hasn't got enough code across to the 6502 to hit any write instruction, or it did, and you missed it in the moments after power up, and now we're in a fixed loop (JMP HERE!) or a crashed processor (read a bad opcode and locked up). So don't worry at this stage about that, but interesting to note.

You must've found ground The case of the modulator is a big shiny ground. Just be aware that the PSU you are using to drive Oric must be (like the original wall wart) isolated from mains earth, otherwise applying the (no doubt earthed!) probe of the scope to the board will bypass the regulator. This is not a problem for old style transformer wallwarts, or most modern switch mode replacements, but is a potential problem if you are using a bench supply or other metal cased PSU, often ground of supply is mains earthed. That doesn't work with Oric when you start introducing other earths!

Your waveforms look sensible ... ULA is waggling row and column multiplexer 3 times per cycles, all data busses going 0-5v quite cleanly. Phi-2 (Pn 39) is right, active for 1/3 of the time (other 2/3 = ULA using bus) and yes it looks ropey like that in normal life Pin 3 is 1MHZ clock out to the sound chip, looks ok.

Address line, always high .... that's interesting. Assuming the ROM gave up a startup vector, code would be running in ROM area (#C000-FFFF) which means you can forgive A15,14 being high. A13 downwards should be moving about (high and low). Otherwise, if they are all high, all the time, that's #FFFF .... can you make sure all 16 are not stuck high?

What is pin 7 (SYNC) of the CPU (6502) doing? IF the 6502 is fetching/decoding/executing, this pin will be toggling high/low. You may need to watch it at power up, if you can, to see what it does (because it might be that the CPU is crashing very early on, see my comment about all-reading-no-writing).

[mikeb]

Adding: Just realised, the only SOURCE on the address bus is the CPU. So If you really do have #FFFF (all address high) then the CPU is either crashed (given up asserting addresses) or never bothered starting. The bus floats high when idle.

Tip: Pin 40 of the CPU -- once you've powered up, dab (briefly) a wire from this pin to ground (pin 1 or 21 of cpu) to FORCE a reset, in case the power on reset isn't happening, as that wouldn't let the CPU start. Let me know if that makes a difference.

You can also do that to restart the CPU while watching pin 7 to see of there is a burst of "SYNC SYNC SYNC ... crash ...."

[Chema]

Yes, you are right about a ROM stuck only reading and never writting.

About the address bus, doesn't the ULA also read the ram to get image data, thus changing the address bus lines?

[iss]

About the address bus, doesn't the ULA also read the ram to get image data, thus changing the address bus lines?

Yes, ULA sets the address lines but ONLY for RAM and only during the low level of F2.

@SpaceFlightOrange: It will sound like joke but ... do you have inserted the ROM chip(s)?

If you have ROM programmer you can try mikeb's Diag ROM: http://oric.signal11.org.uk/html/diagrom.htm

Attached is my very simple diagnostic ROM which doesn't use RAM at all - if CPU, VIA, AY and speaker are OK you will hear like a "phone busy" sound. (Works in emulators too ).