ULA, bus conflicts and the expansion devices

If you want to ask questions about how the machine works, peculiar details, the differences between models, here it is !
How to program the oric hardware (VIA, FDC, ...) is also welcome.
User avatar
iss
Wing Commander
Posts: 1642
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: ULA, bus conflicts and the expansion devices

Post by iss »

Sodiumlightbaby wrote: Sun Mar 03, 2024 10:37 pm So today I learned - don't put WD1770s straight on the bus, especially if its as hostile as the Oric's :lol:
Indeed! #Oric is full with bad HW design examples and the worst one is to leave the CPU buses unbuffered and open to this cruel world :lol:
User avatar
Dbug
Site Admin
Posts: 4464
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: ULA, bus conflicts and the expansion devices

Post by Dbug »

iss wrote: Mon Mar 04, 2024 9:50 am
Sodiumlightbaby wrote: Sun Mar 03, 2024 10:37 pm So today I learned - don't put WD1770s straight on the bus, especially if its as hostile as the Oric's :lol:
Indeed! #Oric is full with bad HW design examples and the worst one is to leave the CPU buses unbuffered and open to this cruel world :lol:
Question: A number of people are trying to make replicas of the Oric motherboard.

Would it be technically possible to improve over all these design faults, and produce a replica motherboard that fits into the standard Atmos case, with proper buffering, proper reset circuitry, etc... which would still work properly with the existing peripherals?
User avatar
iss
Wing Commander
Posts: 1642
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: ULA, bus conflicts and the expansion devices

Post by iss »

Dbug wrote: Mon Mar 04, 2024 10:12 am Question: A number of people are trying to make replicas of the Oric motherboard.

Would it be technically possible to improve over all these design faults, and produce a replica motherboard that fits into the standard Atmos case, with proper buffering, proper reset circuitry, etc... which would still work properly with the existing peripherals?
Yes, it's possible. Actually the right direction is already fact and I've just open it to take a picture.
It's the AtmoStrat:
IMG_20240304_122303.jpg
It works fine but needs some improvements too.
BUT, in general the problem with such projects is that "l'appétit vient en mangeant"!
After every next improvement/feature comes the question "can I also add this and that too" ... :lol:
Well, this year just began the right time for a new project! :)
User avatar
Dbug
Site Admin
Posts: 4464
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: ULA, bus conflicts and the expansion devices

Post by Dbug »

65816!

Is it still running at 1mhz, or have you found a way to make it run faster than 1mhz now and then?
User avatar
iss
Wing Commander
Posts: 1642
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: ULA, bus conflicts and the expansion devices

Post by iss »

Dbug wrote: Mon Mar 04, 2024 11:41 am 65816!

Is it still running at 1mhz, or have you found a way to make it run faster than 1mhz now and then?
Yes, it's 1 MHz and 256 kB RAM - this is because of the "original" ULA limitations. For faster machine it needs redesign.
Here comes the problem I've mentioned above - where to stop - everything is possible but many things
will be replaced with (for instance) FPGA's and/or decent MCU's and this is already an emulation - why do it when we have Oricutron! :D
Sodiumlightbaby
Officer Cadet
Posts: 53
Joined: Thu Feb 22, 2024 11:38 am

Re: ULA, bus conflicts and the expansion devices

Post by Sodiumlightbaby »

I guess the ULA and the 3MHz bus speed is hard to break out of. I know the later 65xx devices are more capable when it comes to bus coexistance, but not sure if its possible to make an Oric backwards compatible system that makes use of those features (but I'm not really a 65xx expert and would enjoy being wrong on this.

But in general, there is a lot that can be fixed on the basic motherboard.
  • Switch mode DC-DC converter
  • Modern reset manager device
  • Alternative Phi2 (or fixed ULA)
  • Expansion port buffering and termination
  • +++
For me, a great project would be to design a ULA replica but with fixes for some of the timing issues we've been discussing (yeah it's the ULA's fault) and perhaps some superset enhancements like supporting higher clocked CPUs, improved graphics modes (sprites?), RAM to RAM DMA channels, or page swapping (get to that RAM behind 0x0300). Not going crazy but imagining what Oric could have evolved to if the product line continued. Could be great for both old and new Oric boards.

But first I need to see if my current project bears fruits.
User avatar
Chema
Game master
Posts: 3020
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: ULA, bus conflicts and the expansion devices

Post by Chema »

Could this be the reason why we detected that some Orics not working with cumulus, solved the issue when changing the ULA? We even started gathering info about which ULAs seemed to work and which didn't, but never reached any conclusion. At first it seemed that more modern ULAs worked better, but in the end, it did not follow any pattern we could identify.

Someone pointed out it could be a combination between ULA and RAM, but I don't remember the details.
User avatar
iss
Wing Commander
Posts: 1642
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: ULA, bus conflicts and the expansion devices

Post by iss »

Chema wrote: Sat Mar 16, 2024 5:10 pm ... combination between ULA and RAM ...
Indeed! The keyword is "combination" of factors because ULA, RAM, CPU, I/O extensions are working on the edge of all (un)documented time-related limits.
Sodiumlightbaby
Officer Cadet
Posts: 53
Joined: Thu Feb 22, 2024 11:38 am

Re: ULA, bus conflicts and the expansion devices

Post by Sodiumlightbaby »

So true. The designers at Tangerine put together a system without accounting for the different parts' variation span of their timing characteristics, so you become dependent on "matching" of the different devices sharing the bus for things to work well. Some of the design decisions inside the ULA might not even have made it to their own system designers, as they have the ROM and RAM bus use overlapping (or they knew and just said "ship it!").
User avatar
Dbug
Site Admin
Posts: 4464
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: ULA, bus conflicts and the expansion devices

Post by Dbug »

I remember reading some post from someone who worked at Oric support, and one common issue was Oric Atmos and Microdisc not working together, so they would do some tweaks, replace capacitors/resistors/whatever until the two work together properly, then send it back to the customer.

Fast forward a few decades and most of these ended up separated one from the other, so when you finally managed to get a Microdisc unit for your Oric, it would often not work with your specific Oric machine.
User avatar
PHD
Private
Posts: 5
Joined: Fri Jun 11, 2021 7:08 pm
Location: France & Ivory Coast
Contact:

Re: ULA, bus conflicts and the expansion devices

Post by PHD »

Hello Sodiumlightbaby,

Congrat for your analyzes, they are very interesting, and thanks for the nice pictures.

I also noticed a strange behavior of the signals on the same area you mentioned at the PHI2 rising edge. I tried many ORIC, and it's almost the same. First, I thought that it was due of the poor shape of this slow rising edge, inaccurate and swinging. It’s for that we can’t trust in the rising edge of PHI2, recommended to use the falling edge by manufacturer.

Coming to you screenshoot:
Can you tell me which signal have you connected to measure the access of the DRAM, ULA and ROM?
Can you also confirm the time enter the falling edge of PHI2 and the end of the DRAM access as shown below:
Attachments
oscilo ula ACCES.png
Sodiumlightbaby
Officer Cadet
Posts: 53
Joined: Thu Feb 22, 2024 11:38 am

Re: ULA, bus conflicts and the expansion devices

Post by Sodiumlightbaby »

Hi PHD!

The signal is one of the data bus pins (D7-D0). The scope is in contiuous trace mode so all the accesses are overlayed. For the ULA accesses you only see the DRAM driving the bus, but for the CPU access there's DRAM, ROM and VIA accesses in different cycles all overlayed.

I can go back and measure it exactly, but the ULA divides the Phi2 cycle (1000ns) into three equal slices of ca 333ns, and eyeballing the hold time I would guess it is ca 200ns of driving the bus after Phi2 goes low.
Last edited by Sodiumlightbaby on Sat Mar 30, 2024 4:53 pm, edited 1 time in total.
Sodiumlightbaby
Officer Cadet
Posts: 53
Joined: Thu Feb 22, 2024 11:38 am

Re: ULA, bus conflicts and the expansion devices

Post by Sodiumlightbaby »

On the scope I measure 176ns, although I see now I measured it when Phi2 hit 2V which is too high for the to-low TTL transition, so the actual time should be a little less. Perhaps 160-170ns.
oric_phi2_cpu_hold_time.png
Edit - addtional thoughts.
This makes sense also logically. The ULA asserts the CAS line (driving DRAM output on the bus) two 83.3ns cycles after pulling Phi0 low. That comes in at 167ns. Now Phi0->Phi2 adds some latency to the clock, but I guess that latency is quite close to the DRAM latency to react.

I'm also thinking the more faint (trace on scope) but stronger (higher voltage on the bus) device we can see in the CPU bus slot could be the VIA. It has the same Phi driven activation as the clearer but weaker device I have assumed is the ROM.
User avatar
PHD
Private
Posts: 5
Joined: Fri Jun 11, 2021 7:08 pm
Location: France & Ivory Coast
Contact:

Re: ULA, bus conflicts and the expansion devices

Post by PHD »

Hi Sodiumlightbaby,

ROM is asserted during PHI2 high side, and when OE goes low to high (Tonz according to datasheet is 100ns). For the VIA is even shorter, THW is 10ns. During this period the ULA don’t access to RAM, before 136ns after PHI goes low, see below, attachement 1. Then for me, no risk at all to have a conflict.

During the low side of PHI2, ULA access twice the RAM, and the last time is around 257ns before MUX signal, when 6502 need to access the RAM. At the falling edge of CAS, Tcac is 75ns, then we have a lot of time and no conflict risk.

I think that the most critical is the swing of PHI2 (0.996MHz to 1.003MHz) and the not stable PHI2 rising edge with also a bad shape, making it impossible to use it as a reference and therefore be forced to use the falling edge. It’s for that I said last time that, the area of rising edge of PHI2 is very unpredictable with sometimes strange behaviour.

Rgeards
Attachments
Capture 2.JPG
Capture 1.JPG
Sodiumlightbaby
Officer Cadet
Posts: 53
Joined: Thu Feb 22, 2024 11:38 am

Re: ULA, bus conflicts and the expansion devices

Post by Sodiumlightbaby »

Hi PHD!

Nice captures! Looking at the polarity, I would assume this is measuring RAS and CAS on the DRAM, after the inverters. Is this correct? In that case the signals are active low (switched compared to the output of ULA), and the DRAM output buffers are active as long as CAS is low. Yes, Tcac is 75ns so Tangerine engineers could have sampled the data and disabled CAS quickly - but they didn't. The last ULA access doesn't end 257ns before the MUX signal, it start at that point - and is "hot" all the way until after Phi2 starts rising. Also the output from the DRAMs continue Toff time after CAC signal is turned off.

From Phi2 starts rising and CAS turns off (DRAM output disabled) we're in potential conflict area and depend on CS and OE latencies on the individual chips. So I still think this is an area likely to have bus contentions with devices using Phi2 rising edge directly.

On the other clock transition (Phi2 high to low), I agree - we have quite some time and little issues with conflicts.
PHD Capture 2 - SLB comment.jpg
Post Reply