Interesting blitter cycle diagram in first HRM revision errata

[Toni Wilen]

Old documentation can be sometimes interesting.

http://www.bombjack.org/commodore/am...ual_Errata.zip Pages 39 to 41.

This document has quite interesting blitter cycle diagram compared to later revisions. It includes all cycle diagrams, including special fill mode combinations that require extra cycle and line mode.

Notes are also interesting:

- I am not sure what note A is supposed to mean
- Note C can't be correct, blitter needs free cycle for all idle cycles (if cycle is used by higher priority DMA channel, blitter stalls, even if it is idle blitter cycle). Idle cycle "used" by blitter is still available for CPU.
- Note D is really weird.

Perhaps C and D are features of some prototype Agnus or A1000 Agnus?

- Disabled A and C channels are marked with * but disabled B is removed.
- Why did they remove fill mode special cases in later revisions? (Replaced with boring "- No fill" text..)

Unfortunately other chapters don't seem to have any surprises.

[mark_k]

Page 54 mentions the "old" canonical CIA addresses BFExFF, BFDxFE. I wonder why they changed the documentation to BFEx01 and BFDx00.

Page 2 of the PDF says BLTCON1 bit 5 is "Reserved for flabloden mode". Flabloden doesn't mean anything specific, at least according to this page it says "Flablode is a Jovian word meaning a device or function that we know is required or desired but for which we don't have an actual definition (noun: flabloden, verb: to flablode)." That page is about the Atari Lynx, and note several ex-Amiga people were involved with development of the Lynx...

[kamelito]

Jerry also have nice diagrams why not ask her?
[ Show youtube player ]
Kamelito

[pandy71]

Originally Posted by kamelito

Jerry also have nice diagrams why not ask her?
[ Show youtube player ]
Kamelito

To catch Jerry attention you need money, lot of them...

[mc6809e]

Originally Posted by Toni Wilen

- I am not sure what note A is supposed to mean

Perhaps they're just trying to help the programmer when the block move is a move of bytes versus a move of words i.e. move changes bytes' word alignment.

Originally Posted by Toni Wilen

- Note C can't be correct, blitter needs free cycle for all idle cycles (if cycle is used by higher priority DMA channel, blitter stalls, even if it is idle blitter cycle). Idle cycle "used" by blitter is still available for CPU.

I guess only one of the cycles actually uses Agnus' ALU so non fetch slot is really needed by blitter while the other is just blocked accidentally. Note c is the "ooops -- made a mistake".

Originally Posted by Toni Wilen

- Note D is really weird.

Perhaps C and D are features of some prototype Agnus or A1000 Agnus?

Could they be talking about D channel writes happening before the next B or C fetch if B or C is blocked by other DMA but D result is ready when next DMA slot is free?

Originally Posted by Toni Wilen

- Disabled A and C channels are marked with * but disabled B is removed.
- Why did they remove fill mode special cases in later revisions? (Replaced with boring "- No fill" text..)

Are the fill mode timings correct? Some fill modes (#3 and #8) look like they have no extra cycle penalty (except for some initial delay).

Maybe the timings become too complicated to show when the issue described in note d is combined with fill mode.

[Toni Wilen]

Originally Posted by mc6809e

Perhaps they're just trying to help the programmer when the block move is a move of bytes versus a move of words i.e. move changes bytes' word alignment.

Possibly but it still does not make enough sense (You wouldn't use B shift with A to D copy anyway)

I guess only one of the cycles actually uses Agnus' ALU so non fetch slot is really needed by blitter while the other is just blocked accidentally. Note c is the "ooops -- made a mistake".

Agreed, this way it makes sense. (But I think stars are in wrong slot, it probably should be Load from C, Do the line draw logic, Write to D, Do nothing)

Could they be talking about D channel writes happening before the next B or C fetch if B or C is blocked by other DMA but D result is ready when next DMA slot is free?

Could be. I'll have to test this someday. Fortunately no one uses those channel combinations, all listed special cases have faster channel combination variants.

More importantly this special case may help to solve blitter's internal hardware operation.

Are the fill mode timings correct? Some fill modes (#3 and #8) look like they have no extra cycle penalty (except for some initial delay).

3 is correct (4 is wrong, it shouldn't have empty slots)
8 is probably a typo, after first A there is two empty slots (which is correct) but later ones are missing.

Both may be simple printing layout errors. (wrong white space characters etc)

Maybe the timings become too complicated to show when the issue described in note d is combined with fill mode.

In my opinion fill mode should have been documented, A to D + fill is the most common fill operation.

But I agree layout of table is weird, order of "operation types" (Why it is called "operation type"?) is confusing. Later revision have better organization but fill mode special cases should have been kept and put in separate smaller table.

[mc6809e]

I've seen the following before in the standard HRM, but it seems to take on more meaning in light of note d:

PIPELINE REGISTER
The blitter performs many operations in each cycle - shifting and masking source words, logical combination of sources, and area fill and zero detect on the output. To enable so many things to take place so quickly, the blitter is pipelined. This means that rather than performing all of the above operations in one blitter cycle, the operations are spread over two blitter cycles. (Here "cycle" is used very loosely for simplicity.) To clarify this, the blitter can be imagined as two chips connected in series. Every cycle, a new set of source operations come in, and the first chip performs its operations on the data. It then passes the half-processed data to the second chip to be finished during the next cycle, when the first chip will be busy at work on the next set of data. Each set of data takes two "cycles" to get through the two chips, overlapped so a set of data can be pumped through each cycle.

It's an interesting description, yes?

Now I understand pipelining of course, but the above description makes me think the two stages of the pipeline are much more independent than is generally appreciated. It's a bit like comparing the 68000's prefetch mechanism to the 80x86's. With the 68000, there's pipelining but it's very rigid. Instruction prefetch cycles are hardwired into the microcode. With the 80x86, though, the prefetch circuit runs whenever possible without being rigidly controlled by the currently executed instruction. If an instruction made the bus free, the prefetch circuit would run independently and automatically.

If the blitter works more like the 8086 and less like the 68000, that might explain how a D channel write might occasionally get ahead of an A or B channel read that's been blocked on an earlier cycle. The D channel handling part of the chip just looks for an open DMA slot and takes it without following a rigid sequence.

This would suggest to me that there are a couple of state machines inside the blitter -- one for early processing and one D writing and area fill. I had always assumed there was just one state machine to handle all the combinations of enabled channels.

Something like (hypothetically):

S->firstAfetch->Afetch->Dwrite->lastDwrite->S

where the sequence is strictly determined by the bits in BLTCONx.

Instead we have two state machines talking to each other, perhaps with a couple of lines between them to signal when data is ready to write and when that data has been accepted.

This dual state machine model also might explain why the busy bit is reset before the last write. When the first state machine finishes it's work it resets the busy bit even though the D channel section is still working.

I'm thinking it might explain other odd behaviors, like why D-only writes have idle cycles even though they appear unnecessary.

[Toni Wilen]

Yes, I am also 100% sure it is not fully hardwired design because writing to BLTCON0 and changing number of channels when blitter is already active can result in really weird and normally impossible cycle diagrams. (for example BACBAC.. or CCCACCCA..)

It is possible each channel has (partially at least) own state machines, for example A needs more cycles before data is ready for mintern generator because A includes masking and shifting, B has shifting only and C is "immediate" and when all channels are "ready", data goes to second cycle (next pipeline step) which works independently, fill phase probably is one pipeline step too. When data is ready to be written, D channel does its job, whenever it gets next free slot.