OT: Amiga 8364R7 Paula dissection

[ttlworks]

Hi Ed,
thanks for the appreciation.

The problem isn't decoding the PLAs, I had translated them to AND/OR gate equivalents.

The problem is understanding in depth what a PLA based state machine does when, how and why.

For instance, the control PLA in an audio channel gives us a 3 Bit state machine.
More than one PLA product term can be active at a time.

Let's just imagine, that two product terms are active at the same time.
One wants the state machine jump to '5', //binary 101
the other wants the state machine jump to '3', //binary 011
the state machine then jumps to '5' AND '3' = '1'. //binary 101 AND 011 = 001

Things like that can give you quite a headache, it's tricky.

;---

Of course there were different 6545/6845 implementations from different vendors, with slightly different features.
We voted for the Rockwell R6545, because it features things like horizontal scrolling and interlaced mode.

[BigEd]

Ah, yes, for sure, understanding the state machine is another level!

I have no problem with your choice of R6845 - just noting the variety really, for my own mental picture.

Edit: I see André has a page on differences.

[BigDumbDinosaur]

Interesting that someone would pay 2000 € just to look at a chip’s innards.

It was chips such as Paula that made the Amiga a standout among the MC68000-based machines of the time. I recall an animation that was widely used as a demo on the Amiga 1000 when it was first put on the market. It wasn’t much of an animation by today’s standards, but was ground-breaking in the mid-1980s. It was too bad Commodore completely dropped the ball on marketing the Amiga. Had Tramiel still been around when the Amiga was released, I think we might have seen desktop computing go in a different direction than it did. The 68K MPUs were so much more elegant than the Intel crud that took over...

BTW, much of my computing work in the 1980s was on 68K-powered minis, which were quite ho-hum compared to the Amiga (or even the Atari ST). That was how I learned (and subsequently forgot most of) 68K assembly language.

[BigEd]

I'm very glad this work was done - it's possible one could raise this sort of money by crowdsourcing, as there's lots of interest in the precise workings of these kinds of custom chips, and the way to a definitive answer - expensive, labour intensive, and time-consuming though it is - is by way of adventures like these.

I'm also very glad to share the planet with people as interested as I am - maybe a little more interested - in the lowest levels of workings of things, and the preservation of the history.

[BigDumbDinosaur]

BigEd wrote:

Ah, yes, for sure, understanding the state machine is another level!

I have no problem with your choice of R6845 - just noting the variety really, for my own mental picture.

Edit: I see André has a page on differences.

Interesting little aside. Commodore’s 8563 video display controller (VDC) found in the “flat” C-128 was essentially a superannuated 6845 with RGBI color and faster timings. The 8568 VDC used in the North American C-128DCR (and a few European C-128D models) was an upscaled 8563 with an extra register, a different pinout and an unused /IRQ output. I don’t know for certain, but I believe the 8568’s bus timing was faster than the 8563, supposedly able to support a machine with an 8 MHz clock. That was a feature intended to work in a Z8000-powered UNIX machine that never came to light.

[ttlworks]

BigDumbDinosaur wrote:

Interesting that someone would pay 2000 € just to look at a chip’s innards.

BDD, Thanks for dropping by.

Ja, getting maybe 30 chips decapped at 2k€ each ain't cheap. //Meanwhile, the lab has changed the price for a decapping to 2k5€.
But that's just money, money isn't the problem. The problem is time. Time is more valuable than money here.

3 months average for vectorizing a 65xx peripheral chip.
3 months average for extracting schematics from the vectorized picture.

This requires a trained eye and some years of experience, and not everybody can do this.
Frank and me happen to have something like a job and a life...

BigDumbDinosaur wrote:

BTW, much of my computing work in the 1980s was on 68K-powered minis, which were quite ho-hum compared to the Amiga
(or even the Atari ST). That was how I learned (and subsequently forgot most of) 68K assembly language.

As somebody had put it:
"68k assembly coding is like to walz.
After RISC or x86 assembly coding, you feel like crawling out of the boxing ring, trying to remember how and when you got the one or other bruise."

My impression is, that the Amiga designers were quite good, and they sure knew what they were doing and why.
But the management at Commodore never had sort of a clue what it got with the Amiga, and what do do with it.
//Just let me mention the NewTek Video Toaster and "Babylon 5 space scenes"...
//...now: why didn't Commodore invent something like the Video Toaster ?

BDD and Ed:
Trying to imagine how much cool technology went dumped into '/dev/null' over the past 50 years
because of incompetent managament, bad product\price politics, dogma and such sure gives you odd numbers...

We are just trying to preserve some of it. //At some point in the future, all of the original chips might be gone.

;---

Of course Frank and me have taken a look at the VDC datasheets,
and from the VDC register map it's obvious that the chip _has_ to be built around a 6845\6545.

But it will take some time until we can pay attention to the VDC.
TED and VIC-II have to be done first.
EF9367 also is interesting: there had been fast vector graphics for the PET.

[Stingray64er]

ttlworks wrote:

analog joysticks

Basically, what we have is a 4 channel 8 Bit A\D converter.

A write to POTGO register with Bit 0 = '1' clears/starts an 8 Bit counter.
The output of said counter goes into the data latches of every channel.

The 4 channels are: POT0X, POT0Y, POT1X, POT1Y.
Register POT0DAT has POT0X in Bit 0..7, and POT0Y in Bit 8..15.
Register POT1DAT has POT1X in Bit 0..7, and POT1Y in Bit 8..15.

;...

All of the channels are built pretty much in the same way,
so we now focus on POT0X.

At the POT0X pad, there is supposed to be attached:
a 47nF (+-10%) capacitor to GND, and a 470kOhm (+-10%) potentiometer to VCC.

Writing '1' to Bit 9 of the POTGO register configurates the POT0X pad as an output,
means the POT0X pad output driver is enabled,
and according to what is written into POTGO register Bit 8
said driver either switches the POT0X pad to GND or to VCC.

When '0' was written to Bit 9,
the POT0X pad is switched to GND when the counter is cleared/started,
what discharges the external capacitor.
After the counter is started, the capacitor is charged to VCC
through the potentiometer.

A Schmidt trigger senses the voltage at the POT0X pad.
Reading POTGO register Bit 8 gives you what logic level is at the POT0X pad.
As long as the logic level on the POT0X pad is low,
the counter value is loaded into the POT0X register,
and that's basically it.

Wow! what an excellent resource this is! Thank you for doing this dissection.

I have a question about the POT outputs

Myself and a good buddy (Damian from D&D Retro Computers) found an example of Amiga software that holds a POT pin low (i.e. sets the POT as low and as an output) while a connected CD32 pad drives the same pin high (i.e. 5V)

Should this damage Paula?

If I am understanding the dissection schematic, the POT outputs are similar to CMOS outputs (having a P-FET & a N-FET) but importantly, there is some resistance in series with each FET.

Does my understanding here sound about right?

Interestingly, the dissection shows that when using the POT pins to read a potentiometer value, Paula discharges the 47nF cap by connecting the POT pin to 0V through the N-FET, this is while the 470k potentiometer could be set to 0R (i.e. the pot pin is connected to 5V)

Does this suggest that the POT outputs may be robust enough to handle being connected to 5V while they themselves are driving low?

[ttlworks]

Stingray64er, welcome to our forum.

It's been a while that we did the Paula dissection,
and I don't remember too much of the details.

I think the POT pins might be robust enough,
and I think it's possible to re_use the POT pins as I\O port.

[Stingray64er]

Thank you for the friendly welcome & response ttlworks

I guess the question of POT pins being connected to 5V while the low side FET is on, comes down to how chunky that 'resistor' in series with the low side FET is.

I think those resistors are representative of the RDS of the FET, does that sound right?

[Stingray64er]

Hi ttlworks et al.

I think I've found something...

In regard to the POT pins, "Mapping The Amiga" 2nd ed. p467 states "The positive voltage sent to these pins should never exceed 5 volts or 400 milliamps."

I think this is probably the most definitive answer I'm likely to come across. I also think the figures sound reasonable, but I would be interested if you (or anyone else) has any thoughts on this?