California Devices Inc and the HCS10017

In this forum you can write about anything that does not fit in other forums.
This includes generic Oric talkings and things that are totaly unrelated but want to share with people here :)
User avatar
dreamseal
Officer Cadet
Posts: 61
Joined: Sat Mar 17, 2018 6:14 pm

Re: California Devices Inc and the HCS10017

Post by dreamseal » Tue Sep 04, 2018 7:50 pm

dreamseal wrote:
Tue Jul 24, 2018 7:36 pm
Also I've been in touch with Mike Brown, who has in the past done a lot of thinking about what the internals of the ULA might look like. I knew he would be very interested in the die shot, as would any Oric enthusiast.
Many of you have probably been wondering where things have got to with this investigation. Some of you may have been keeping an eye on Mike Brown's ULA die shot page and would already have noticed many more diagrams and documents appearing on that page over the past few weeks:

http://oric.signal11.org.uk/html/ula-dieshot.htm

Mike Brown has very much taken the lead with this effort. I was in almost daily communication with him for the first three weeks after we received the die shot images back, but I contributed less than 1% to the effort due to not having a lot of time. Luckily for all of us though, Mike Brown has had a lot of free time over the past 6 weeks. I myself have been away overseas on holiday for the past three, and during that time Mike has made significant progress, up to the point where today he has said he is done.

So what does done mean you might ask?

Something I hadn't mentioned up until this point is that Datel also provided me with some verilog files that went some way towards representing what was on the die shot. It contained almost all of the transistors and connections between them, and also many of the logic gates that had been identified through some kind of automated process. I wasn't sure to what degree the second file was complete, in fact Mike at Datel had indicated that they weren't complete. I passed these verilog files over to Mike Brown and he immediately saw these as the best way to derive the full logic of the die shot. So he started writing scripts to analyse and verify the verilog files provided by Datel. He started by writing scripts that took the transistor level verilog and attempted to identify the basic logic gates from those transistors and their connections. We thought that the transistor level file was probably mostly complete. Mike Brown did find a number of missing connections as part of his investigation though and as he went along he kept updating his version of the verilog to include everything he had identified as missing. He reached a point where his scripts were able to verify the logic gates contained in the second of the verilog files provided by Datel, but he very much took things beyond that, up to a point where his scripts identified all of the logic gates and all unused transistors. He then took it to the next level above that, identifying things such as flip flops (of which there were many). And then he started looking at the level above that, identifying counters, sets of data latches, registers, adders, clock dividers, etc.

I had mentioned to Mike that I'd used a tool called Logisim in the past to simulate purely digital circuits like this. I'd said that I might try to write something to convert his verilog files into a Logisim circuit, and then I went on holiday. Now that I'm back, I've discovered that Mike has already done it. He took the full Oric ULA circuit that he'd worked out from analysing the verilog and set about creating the circuit in Logisim and he reached a point with the simulation where it is fully working as expected. This is a great validation and verification of the circuits that he has produced from the die shot. You'll find those Logisim files also on his website.

Mike has documented this journey of discovery in a document that he has released on his website today:

http://oric.signal11.org.uk/files/pub/u ... Schems.pdf

I think you'll all find it a great read and we encourage you to have a read through and report back here with any feedback that you have. I'm sure you'll all be interested in the hidden feature that was discovered.

User avatar
Chema
Game master
Posts: 2282
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: California Devices Inc and the HCS10017

Post by Chema » Tue Sep 04, 2018 9:33 pm

This is exciting. Incredibly exciting. I can't express how exciting.

I am going to read the pdf and see what's in there. But this is an incredible achievement for the Oric community.

Please tell Mike how thankful we are and that it would be incredible to see him around this forum.

User avatar
Dbug
Site Admin
Posts: 2702
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: California Devices Inc and the HCS10017

Post by Dbug » Wed Sep 05, 2018 5:11 pm

What I find interesting is that the hidden feature may just be what I needed to synchronize the ULA :D

User avatar
dreamseal
Officer Cadet
Posts: 61
Joined: Sat Mar 17, 2018 6:14 pm

Re: California Devices Inc and the HCS10017

Post by dreamseal » Wed Sep 05, 2018 5:27 pm

Yes, I'm waiting to see if anyone is brave enough to take the risk on testing this feature. :D

User avatar
Chema
Game master
Posts: 2282
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: California Devices Inc and the HCS10017

Post by Chema » Wed Sep 05, 2018 5:51 pm

To be honest I was praying for something weirder and more useful, such as a way to change the starting address of the screen data :twisted: (almost there) or some mad way of inhibiting the attribute thing altogether and get a 320x200 monochrome display (yeah, nothing even near that).

Nah, I did not really expected anything useful from the programming point of view. Nothing without any hardware mod, that is. :(

User avatar
mikeb
1st Star Corporal
Posts: 12
Joined: Wed Sep 05, 2018 8:03 pm
Location: West Midlands, UK
Contact:

Re: California Devices Inc and the HCS10017

Post by mikeb » Thu Sep 06, 2018 2:47 pm

Chema wrote:
Tue Sep 04, 2018 9:33 pm
Please tell Mike how thankful we are and that it would be incredible to see him around this forum.
Did someone call?

Hello all! I was watching this thread from the moment Dreamseal flagged it up to me, and occasionally lurk on interesting threads. But I've signed up so that I can respond to any feedback/questions directly.

Mike.

User avatar
mikeb
1st Star Corporal
Posts: 12
Joined: Wed Sep 05, 2018 8:03 pm
Location: West Midlands, UK
Contact:

Re: California Devices Inc and the HCS10017

Post by mikeb » Thu Sep 06, 2018 3:10 pm

dreamseal wrote:
Wed Sep 05, 2018 5:27 pm
Yes, I'm waiting to see if anyone is brave enough to take the risk on testing this feature. :D
I did -- last night. No smoke came out.

@Dbug you may be in luck for your hardware synchronization of video outputs.

So here's what I discovered: Because P19 is somewhat less well protected than other genuine inputs, I went cautiously -- as per the suggestion in my PDF. I used a 2K resistor to +5V rail (P19 to P24 of the ULA). This is to prevent any problems from excessive current into the pin when it's being driven as red video out.

First thing: It definitely worked as per the simulation and theory -- the picture went off immediately, the usual "purring" from the speaker stopped, and all the clocks stopped. On removing the resistor, of course Oric did not work -- as I also cautioned, DRAM had been completely emptied, due to no refresh, so the 6502 got bad data and hung. However, no harm done, briefly connecting Pin 40 of the 6502 (Reset) to ground triggered a cold reset and normal startup.

Secondly: Because I held the resistor there for a while, I expected it to come back dazed and confused. What I hadn't expected is that briefly touching the resistor across caused a brief blackout, and return to apparently normal operation. I was working on the basis that even a few milliseconds would allow memory to fade away, especially with the fuss some people made about how Oric's refresh doesn't seem to be as thorough as might be needed to work.

It turns out that a sub 1 second outage at P19 seems to leave a running Oric, each time. Between 1 and 2 seconds it's running, but you might get an odd character on the screen you didn't ask for, and a possible crash. At about 2-3 seconds, well the character set is clearly fading away and the screen turns to mush (and it crashes). You have to go quite far to actually drain the memory to black/white bars. DRAM is more persistent than I realized!

This is the bit I haven't tested: I am very much confident that if you take two Orics, give them a common 12MHz clock, and take P19 on both ULA's high for a minimum of 64us (absolute minimum: You must let both ULA reach HSYNC and come to a halt, so 128us would be better), then on simultaneously releasing pin 19, both ULAs will be in absolute lockstep, and stay there.

If you don't use a common clock they will drift apart. This means you will need to repeatedly do this, which is more likely to cause visual disturbances due to messing with the sync timings. A common clock could be one of: External 12MHz oscillator driving both ULAs, Internal 12MHz standard Oric circuit, but coupled together so they are forced to oscillate the same, Internal "Master" Oric signal taken across to "Slave" Oric's clock.

Note that to take both P19's high (and release together) you will need to drive the via something to isolate them from each other, e.g. 2 x tri-stateable buffers (with it's input tied high, output to P19, and only enabled (both together) when needed). Or, old school, two diodes as isolation to allow +5v (via a single limiting resistor still) onto both P19's without them seeing each other.

After all, if P19 goes high on Oric-1 (any use of Red, Magenta, White), then Oric-2 will get kicked into reset! So you can't connect them together like that.

I leave you to think about how that can be used :)

Mike.

User avatar
NekoNoNiaow
Pilot Officer
Posts: 119
Joined: Sun Jan 15, 2006 10:08 pm
Location: Montreal, Canadia

Re: California Devices Inc and the HCS10017

Post by NekoNoNiaow » Thu Sep 06, 2018 11:59 pm

dreamseal wrote:
Tue Jul 24, 2018 7:36 pm
Also I've been in touch with Mike Brown, who has in the past done a lot of thinking about what the internals of the ULA might look like. I knew he would be very interested in the die shot, as would any Oric enthusiast.
Holy kitty, what an understatement. ;)
A huge fluffy thanks for your efforts in this endeavor, the results were worth it!
Chema wrote:
Tue Sep 04, 2018 9:33 pm
This is exciting. Incredibly exciting. I can't express how exciting.
Yup, completely mindblowing, I read the whole PDF and this is mesmerizing, especially the synchronization feature based on using the RED pin as an input. What a neat trick, it is clear that the engineers must have used it to debug the kitten.
Dbug wrote:
Wed Sep 05, 2018 5:11 pm
What I find interesting is that the hidden feature may just be what I needed to synchronize the ULA :D
Indeed, too bad though that the ULA is effectively incapable of writing back on the data bus. It looks like software based raster synchronization will remain impossible with an unmodified ULA. :'(
mikeb wrote:
Thu Sep 06, 2018 3:10 pm
dreamseal wrote:
Wed Sep 05, 2018 5:27 pm
Yes, I'm waiting to see if anyone is brave enough to take the risk on testing this feature. :D
I did -- last night. No smoke came out.
Huhu. ;)
Thanks Mike for your fantastic work, the PDF is both technically and narratively captivating. ;)
mikeb wrote:
Thu Sep 06, 2018 3:10 pm
First thing: It definitely worked as per the simulation and theory -- the picture went off immediately, the usual "purring" from the speaker stopped, and all the clocks stopped.
\(^o^)/
mikeb wrote:
Thu Sep 06, 2018 3:10 pm
[...] You have to go quite far to actually drain the memory to black/white bars. DRAM is more persistent than I realized!
DRAM is indeed much more persistent that the manufacturer datasheets imply. On the Amiga one can sometime get back enough valid memory even 10s after powering on the machine. The error rate is likely a function of the refresh rate and I assume that even between 1ms and 4ms you would get different error rates but neither would be actually zero but rather would go from something like 10^15 (4ms) to 10^16 (1ms).
Manufacturers essentially set the proper refresh rate as a level where the error rate is compatible with full time prolonged operation of the machine (i.e., no errors in months, maybe years).

User avatar
mikeb
1st Star Corporal
Posts: 12
Joined: Wed Sep 05, 2018 8:03 pm
Location: West Midlands, UK
Contact:

Re: California Devices Inc and the HCS10017

Post by mikeb » Sat Sep 08, 2018 10:53 am

NekoNoNiaow wrote:
Thu Sep 06, 2018 11:59 pm
DRAM is indeed much more persistent that the manufacturer datasheets imply. On the Amiga one can sometime get back enough valid memory even 10s after powering on the machine.
This could explain why when I tried doing a reduced-hardware version of Steve Ciarcia's DRAM chip based camera from Byte magazine (1983 Sept/Oct) I couldn't get it to work. The theory was that a DRAM chip makes a light sensitive array, when not refreshed. So fill memory with 1's (soak), wait a bit with no access (exposure) and then refresh/cycle/read back all the data.

Some of the data would be 0's, where light had fallen to "expose" the pixel. Some would be 1's.

The timing in the article (using a different DRAM chip) gave a read-rate of 15 frames per second of a 128x256 pixel array -- half the 64k DRAM. So there's no way I would expect data to hang around for seconds. Which is what I was finding - written data was still there. Light or not, it retained the data when not refreshed. Shoulda waited longer!

User avatar
Dbug
Site Admin
Posts: 2702
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: California Devices Inc and the HCS10017

Post by Dbug » Sat Sep 08, 2018 4:37 pm

I had similar experience with my Atari ST where in some cases I would still see some remnants of previous graphics in memory at least 10 seconds after I had switched off and on again the machine :)

User avatar
mikeb
1st Star Corporal
Posts: 12
Joined: Wed Sep 05, 2018 8:03 pm
Location: West Midlands, UK
Contact:

Re: California Devices Inc and the HCS10017

Post by mikeb » Sat Sep 08, 2018 9:12 pm

Back to the ULA document: Can anyone with a long memory, or the right early documentation, let me know if ever there was a time, early in the history of Oric where the INK and PAPER colours were not as we know them now ?

I'm thinking early as in pre-production/prototype models.

Is there any evidence that the colours used to be

0: Black
1: Blue
2: Green
3: Cyan
4: Red
5: Magenta
6: Yellow
7: White

Which might explain the mis-pinning of the ULA (and video socket) as shown on the official circuit diagram ... otherwise it's just an error :)

User avatar
Symoon
Archivist
Posts: 1373
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: California Devices Inc and the HCS10017

Post by Symoon » Sun Sep 09, 2018 5:01 pm

A bit late to the party, but WOW, what an amazing document!
Far beyond my understanding and abilities, but so well detailed that it still could be a source of information for non-hardware guys like me.

Congratulations Mike, and to all those involved.

User avatar
iss
Squad Leader
Posts: 669
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: California Devices Inc and the HCS10017

Post by iss » Wed Sep 12, 2018 2:56 pm

Absolutely incredible work! Thank you all Mike Brown, Mike Connors/Datel and dreamseal.

In our Oric are hidden lot of secrets but 2 questions related to ULA puzzled me for years and I lost hope to found the right answers...
Q1: Why they connect ONLY the Blue (actually the Red) video line with R26 (2.2 kOhms) to ground? Now this is answered and I'm very happy! :D

Q2: In the "ORIC service manual" on page 35 is written:
IC18-D6.png
and the question is: Why exactly Data Bit 6 (IC18) is different from all other Data Bits?
I didn't found in the great ULA documentation and schematics any difference... any ideas?

Thanks again, and now it's time to unfreeze Merging video output? ;)

User avatar
mikeb
1st Star Corporal
Posts: 12
Joined: Wed Sep 05, 2018 8:03 pm
Location: West Midlands, UK
Contact:

Re: California Devices Inc and the HCS10017

Post by mikeb » Wed Sep 12, 2018 9:20 pm

@symoon
Congratulations Mike, and to all those involved.
Thanks very much. Did you mean congratULAtions ? :lol:

@iss - I am so annoyed at myself for not seeing that. All these years staring at that circuit for different reasons, and even after everything written in that PDF, I didn't even notice that little resistor lurking there. Well spotted, and noted for future updates! This is why it's good for people to read through this stuff, anything else like that -- let me know! Of course, it's there to ensure the line doesn't accidentally "float" its way high, causing mayhem. Hidden in plain sight.

I've seen that comment in the service manual. I cannot think why data bit 6 would be different -- you're right there's nothing obvious in the circuit (external to the ULA) that is not symmetrical about that particular bit. As for the ULA -- the databus is all inputs, and exactly 4 bits have a common input circuit (the other 4 share a different input circuit). Bit 6 does not stand out.

All I can think of is that when they prepared the manual, they noticed it was different due to the data that happens to be passing around, and remarked on it so people wouldn't seize on that difference as a potential fault.

User avatar
iss
Squad Leader
Posts: 669
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: California Devices Inc and the HCS10017

Post by iss » Thu Sep 13, 2018 5:42 pm

mikeb wrote:
Wed Sep 12, 2018 9:20 pm
I am so annoyed at myself for not seeing that.
Now me too :) - actually you answered to my Q2 too - excluding ULA from the suspects, taking the words "inherent design feature" from the book literally and looking at the PCB the anser is obvious: there is no decoupling capacitor for IC18 :D That's it!
ic18.jpg

Post Reply