Dual Pokey... so much more could be done.

[Rybags]

The OS routines would be close to useless. But doing custom SIO is no big problem. But for a second full-function SIO port you'd probably need to borrow a joystick port pin to act as the /Command line.

[tcdev]

It's not explained by the PCB, but a Vector Display is something different to a Raster Display.

Perhaps a Vector Processor is not a full CPU, but it is a Co-Processor. If the Main Processor had to handle the 3D , there had to be a second CPU to drive POKEY. Or a much faster processor with an adaptive bus system.

The (6502/6809) main CPU in the Atari vector arcade games build a "display list" in shared memory that consists primarily of VECTOR commands and calls to vector ROM routines (that consist of VECTOR commands). Once a complete "frame" has been described, the CPU hands it over to the AVG for actual display on the monitor, then gets on with the business of building the display list for the next frame. So the main CPU doesn't have to actually render any vectors itself.

 

The AVG in the arcade machines processes the "display list" of vector commands and controls the beam on the monitor to draw the vectors. It is a simple "processor" with a handful of special commands, either drawing or execution flow (JSR, JMP, RTS, HALT).

 

The so-called "math box" used in the games assist the main CPU with matrix arithmetic for 2D and 3D transforms. These calculations would be required whether the display is vector, or raster (with the same graphics rendered). The math box has a PROM which defines a dozen or so subroutines that chain together a few simple operations (think micro-code in a CPU) to provide more complex operations, like a 3x3 matrix multiply. The interface is, again, a block of shared memory.

 

FWIW A single 6809 in Star Wars controls the TMS5220 and 4x POKEY chips. The TMS5220 sample data is fed byte-by-byte by the 6809 whilst it's also doing POKEY sound. 2 POKEYs are used for FX, the other 2 for music.

[tcdev]

Referring to the design of POKEY, it is created to take use of one 6502 CPU. So, if you want to have every added POKEY used correctly, you have to add an extra 6502 CPU. Anything else is dreaming on a pink cloud...

 

Absolute rubbish.

[tcdev]

A 65816 would probably be needed to have acceptable results with quad POKEY audio. You're probably right about many of the other POKEY functions needing a dedicated CPU... otherwise, some kind of buffering circuit would be necessary, and that would cause lag.

 

Actually the 65816 would be quite unsuited to the POKEY. In native mode the 65816 is unable to byte-address memory, being restricted to two 8-bit accesses to sequential addresses. It does have an 8-bit access mode, but then you're crippling it down towards the 6502 again.

[tcdev]

 

IMHO this is a failed assumption. The POKEY chip is the one and only in the Atari 8-Bit chipset which has two (!) chip-select signals. Atari would have advisedly the goal to enable more than one POKEY in a system or cabinet. And CPU power isn´t the issue here.

 

Having 2 chip-select signals has nothing to do with having multiple POKEYs in a system; it's to simplify glue logic for the system designer, especially when the chip-select logic has two inputs, or being able to select either positive or negative logic without adding another inverter to the circuit.

 

Just like any other device, you can hook as many POKEY chips up to a CPU as you desire. The chip-select pin on each is driven by address decode circuitry that is part of the system design, not the POKEY itself.

[Bryan]

Actually the 65816 would be quite unsuited to the POKEY. In native mode the 65816 is unable to byte-address memory, being restricted to two 8-bit accesses to sequential addresses. It does have an 8-bit access mode, but then you're crippling it down towards the 6502 again.

I haven't looked at the 65816 much but if this is true you could simply shift the address lines down one and fail to decode to hardware on odd addresses.

[Rybags]

Problem is that'd screw up normal mode accesses.

 

As for CPU demand, one Pokey requires the full attention of one 6502 in the context of doing sample playback, nothing else.

But really, there's little point in using more than a couple of channels for samples at a time. Sure you can use 3 voices to get near to 5 bit sample resolution but going 4 is barely worth it. If you want higher fidelity sample playback then just add a Covox or equivalent.

 

A single CPU is more than capable of doing a 16 voice chiptune even though it'd likely leave next to no time for game logic.

Edited September 22, 2017 by Rybags

[tcdev]

I haven't looked at the 65816 much but if this is true you could simply shift the address lines down one and fail to decode to hardware on odd addresses.

Yeah but the issue is that you're now only using some of the available cycles to do useful stuff... so there's little advantage over using a 6502...

[+wood_jl]

 

 

What I'm wondering about is the need to "turn off" the dual POKEY. As a layman, shouldn't the "extra" POKEY lay dormant, until called upon? I thought I saw that it had to be switched on, and off?

[CPUWIZ]

 

Actually the 65816 would be quite unsuited to the POKEY. In native mode the 65816 is unable to byte-address memory, being restricted to two 8-bit accesses to sequential addresses. It does have an 8-bit access mode, but then you're crippling it down towards the 6502 again.

 

I wrote two SNES games in 65816, you can switch 8 16 bit on the fly, no crippling. Just useful.

[tcdev]

 

I wrote two SNES games in 65816, you can switch 8 <> 16 bit on the fly, no crippling. Just useful.

 

I've written 65816 ASM as well. Switching between 8<->16 bit chews up cycles and whatever 'advantage' the 65816 had over the 6502 for controlling POKEY chips is looking less and less...