The big Oric ULA Database

[iss]

Yes, it's strange but it's fun to touch our ' precioussss'... Oric.
You mentioned the MAP signal - I totally agree that this can be the main problem. I need to finish something 'soft' for Oric than I'll switch to 'hard' debugging the Xilinx sources experimenting with timings.

BTW, during my tests on the SDCard was only one image - Oricium!

[Godzil]

Chema: yes it's a combination of problemes, Phi2 comming out of the 6502 which is in a bad shape, (Phi2 is internally use in the 6502 and there is no hardware inside to shape it like a normal TTL output, so if you look at Phi2 it generally looks like a crap square waveform and external hardware pluged on it tends to make it worse. The only good solution whould be to buffer it with a normal TTL chip or use a transistor to switch the output (a cmos one would be the best I think, I should check my schematics for this point)

Then the crapish Phi2 is distorded from the "long" cable between the Oric and the connected device, this device try to understand the Phi2 and may be confused if the shape is too bad,

Then the device, if Phi2 is correct enough will generate the /MAP signal, which also goes along the cable and will be distorded, and get by the ULA.

Most of the issue we saw are, I think, caused by the ULA which get the /MAP signal in an incorrect time (I don't know how the ULA handle video generation with /MAP selected, but I think badly, and if would be a conception issue of the ULA, it should ignore /MAP when doing the video generation part.

So what fail in our case is the ULA, but the cause is something between the Phi2 generation from the fact that there is nothing to handle a correct impedance on the long cable used (and that the cumulus may not handle correctly the Phi2 signal in the current CPLD code..)

[kenneth]

I remember a diagram from an Oric magazine where an unused gate into the oric pcb could be connected to restore the phase2 signal shape.

[Steve M]

Maybe it is a 6502 database we need? What make are your 6502 ISS ?

So far all the ULAs I've tested work. I had a faulty Oric-1 which turns out to have a fault ULA that throws garbage on the screen, but it still managed to work with the Cumulus and load a disk.

I marked all the Atmoses that didn't work with Cumulus but the marks have faded so I'm having to test everything again and my monitor plug has come apart now so I'm off to fit a new case and resolder it before I can do any more testing.

[iss]

Here is my CPU list:

Code: Select all

R6502AP     R6502-13  83/04
R6502AP     R6502-13  84/38
SY6502                83/37
MOS6502AD             86/31
CM630P                87/28
CM630P                90/10

CM630P is Bulgarian analog of 6502.
IMO creating database with full details (ULA, CPU, DRAM, VIA) is interesting, but I doubt that it will have any practical use,
because never will be full guaranty that using 'proper' chips will make Cumulus work.
I prefer to investigate and solve the real problem - just need some more free time, of course any help will be highly appreciated.

[Steve M]

Yes, I think something else is at fault. It may be more than one thing.

I fixed my monitor plug but the monitor has gone now. Don't know if I'll be able to get an old RGB monitor fixed in this day and age
I guess I'll have to get a TV out to do any more testing.

[Chema]

Added the info of two Atmos owned by Silicebit which did not work with Cumulus. No apparent pattern arises

Godzil, you put the "partially " option in the wrong question....

[Godzil]

Chema: OOPS

For the 6502, even if the Phi2 is badly shaped, it's not the direct culprit, and even on the same manufacturer there are a lot of variation for this signal, not sure if storing information on them is really interesting

Edit: I'm really sorry for the mess, I've left the "partially" on the "wrong" question as it could have a sense, add it to the correct one, and add for both a "other" ("autre" if it display it in french..) choice

[Steve M]

I've added my results - I seem to have 2 8316 but not sure if I had two chips or write it down twice. But I did have a faulty 8316 which still loaded Cumulus disk. So there's still 2. This conflicts with a previous ULA with same number that didn't work. The results seem to be a bit random.

Perhaps the next stage would be to swap some good ULAs and see if they work in Atmoses that are fussy about which ULA it likes?

I remember some blaming the power supply for loading failures at an Oric meet. The Oric used to act oddly sometimes.

[Steve M]

Curious.
Found an Atmos that didn't work with Cumulus - 7C 8316 ULA. The Atmos seemed noisy - a hum from the speaker. Odd RAM chips, not sure if that is significant (OKI 3764) Tried a new ULA 8F 8422 and the Cumulus boots though the booting sequence seemed a little different and flashed the Oric boot screen at one point.

Found another non Cumulus. (it's when the disk loads that it hangs.) 8C 8316. This one seemed a bit noisy too. Swapped for new 8F 8422 and the disk loaded this time. Again the loading seemed a little different flashing up the insert disk screen again.

So I found an Atmos that was OK with the Cumulus and put the 'bad ULA' 7C 8316 in and it worked fine. Booted normally without the noise.

So, whilst the ULA affects things I don't think it is the ULA that is the problem.

[Chema]

Yep Steve, you're right. The ULA is not the culprit, but different ULAs may tolerate timing errors more or less for a given setup. So if your Oric 'nearly' works with Cumulus (hangups, odd screen patterns, nearly boots but no,...) it is worth to try another ULA.

And if it simply does not work at all with Cumulus, you will lose nothing for trying

Found an Atmos that didn't work with Cumulus - 7C 8316 ULA. The Atmos seemed noisy - a hum from the speaker.

When the Oric+Cumulus does not boot (for instance invalid SD card) I have that clearly audible hum from the speaker. It disappears as soon as booting starts.

BTW, you said that two Orics which were not working with Cumulus, started working when you changed for a new ULA? It would be nice to know the differences between all those Orics (memory chips, but also processor and via too...)

[Godzil]

(This hum comme from the busy Data/Addresse IO line, The Oric initialisation where all the RAM zeroed and is written with $AA or $55, can't remember, do this amazing noise.)

[Steve M]

(This hum comme from the busy Data/Addresse IO line, The Oric initialisation where all the RAM zeroed and is written with $AA or $55, can't remember, do this amazing noise.)

What would be the fix for this?

[Steve M]

BTW, you said that two Orics which were not working with Cumulus, started working when you changed for a new ULA? It would be nice to know the differences between all those Orics (memory chips, but also processor and via too...)

I will need to have another look. I have tried a lot of 'new' chips recently after buying some 74LS04 6502 6522 XTAL and a mixed collection.
I've been testing Atmoses and swapping components - my head's spinning !

I have some socketed boards which work, but the ones that I have problems with tend to be mostly soldered so I can't easily swap to test components. I don't have an oscilloscope yet so I'm limited as to what I can test.

(Bought a cheap scope kit to build - hope it works. Wish me luck !)
http://www.ebay.co.uk/itm/331552774803? ... EBIDX%3AIT

[Godzil]

(This hum comme from the busy Data/Addresse IO line, The Oric initialisation where all the RAM zeroed and is written with $AA or $55, can't remember, do this amazing noise.)

What would be the fix for this?

I big change on the Oric PCB.

This is a stupid layout on the oric if you look where the component are placed:

On the middle bottom, you have the GI/Yamaha PSG which generate the sound output.

Ben in the middle/center you have the ULA and just on the left of the ULA, you have the OpAmp used to amplify the PSG output, and they on the right of the ULA you have the output HP.

What happen is that the PCB track that transport the PSG output to the OpAmp cross part of the Address bus and the Data bus, all of the line do what we call crosstalk, and even if there is a lowpass filter before the opamp, the perturbation is not only on the 1Mhz frequency, there are a lots of harmonic frequency, and some seems to be on the audible part, and are amplified by the OpAmp, and that what we ear in the output HP.


The only way to clear that would be to make a new PCB to prevent this to happen, either by adding some inductance, having different ground plane for the logic part and the audio part, and last but not least, put that OpAmp between the PSG and the HP, not on the complete other side of the PCB as it is now.

How to solve on an existing Oric? Not that easy, but it's definitely doable. You will first need to find correctly a shielded wire, then you will need to cut the audio transport track on BOTH sides, on the filter before the OpAmp and on the PSG, we don't want the existing track to still behave as an antenna. Then solder the shielded wire one end to the output of the PSG, the other on the filter entry which is before the OpAmp.

You will also need to cut the track that goes from the OpAmp to the TAPE DIN connector, for the same reason, this track is acting as an antenna and would need to be replaced by a properly shielded wire.

I'm currently unsure if the shield need to be connected to ground on one side or not, but I suppose so.