The Sinclair QL Forum

How would you extract it?

While I am not one of the early adopters (not that I don't want to be, but funds are allocated elsewhere), I would root for aurora 256 color mode
Not to toot my own horn but it seems to me a good compromise between usable colors and memory bandwidth limitations at high res. I do fully realize it's not even close to simple but well... just my $0.02...

Re flash, it's not the only slightly strange decision, though the idea to pack read and green bits for mode 4 in alternate even and odd bytes seems like that, it seems someone has carefully studied the works of the MOVEP instruction but then this comes back to bite you once you move into 68040/60 and ColdFire territory.
One rather odd one is that the QL does not have 4 possible screen areas rather than two. The amount of added logic for that would have been almost negligible, certainly compared to the workings of the flash bit.
Also, technically, the flash bit could well have worked as a 16 color modifier without an extra pin (and I'll get to that later) or analog circuits - by halving the length of the pixel. Remember, we already have mode 4 with twice as many pixels per line, so we are already capable of displaying half width pixels compared to mode 8. Yes, it would bring some interference on the TV unless the cost of around 3 small capacitors was added to filter RGB to the modulator (which should have been added anyway...) and besides, Apple II did something very similar way back when. Besides doing it just a bit more clever like displaying green in the forst half and red+blue in the second half of the pixel would work much better, sort of a 'on the fly' stipple.

As for the extra pin, the decision to decode 8302 through the 8301 actually cost the 8301 designers 2 extra pins, not 1. It could have been done the way the later revisions do it even before the use of the HAL chip. 8301 needs access to address line A6 to decode the display control register, which it gets from the multiplexed address lines going to the RAM chips. The 8301 only uses A17 and A16 directly. For some inexplicable reason, the 8301 uses not one but two pins to arbitrate when it's accessing RAM, vs. when the CPU is doing it, one to tri-state the address multiplexers, and one to tristate the data bus, hence isolating the CPU from the RAM. Because it seems that the 8302 was originally intended to be on the RAM side of the bus (for which there is no good reason and indeed it was not done that way in the end) two of these enable pins are needed, so that the data bus could be independently enabled for the 8302. If it was not for that never actually used blunder, one would have been enough to enable bot the address multiplexers and data buffer, and one pin could have been freed on the 8301. May not look as much, but it would have opened a whole lot of possibility.

Even more interesting, the 8302 has one redundant pin too. PCENL is decoded by the 8301 originally but not gated by CPU DSL, so the 8302 has a DSL pin as well. Funnily enough, so does the 8301 so it's only missing one OR gate in the PCENL decoding, and the DSL pin on the 8302 could have been freed for other uses. When the HAL is used, the PCENL line can actually be gated by DSL and you can just as well tie DSL on the 8302 to ground, or use DSL interchangeably with PCENL.

Is it all a case of working under great pressure and a series of last minute decisions?

Nasta wrote:While I am not one of the early adopters (not that I don't want to be, but funds are allocated elsewhere), I would root for aurora 256 color mode
Not to toot my own horn but it seems to me a good compromise between usable colors and memory bandwidth limitations at high res. I do fully realize it's not even close to simple but well... just my $0.02...

Maybe you should have mentioned that funds were the issue, I tend to find solutions in such cases

As for 8-bit colour mode, I have looked into that, and found it is not nice to implement in my otherwise 16-bit oriented approach (in some way, even the QL Modes fit the 16-bit implementation well). For timing reasons, additional 8-bit colour (the design has 7 other modes already) calls for an extra pipelining stage. (CPLDs cells would be different.) But if I do that, I have to pipeline the other modes also, unless I want to run into different usage of internal counter values and make the design hard to read and maintain. That, on top of the Aurora mode specific stuff itself, costs registers and routing resources which I would rather save for future things that I'm interested in, like cache or an MMU. Not that it is impossible to do both, but I don't want a nearly full chip! The fuller the chip, there harder to achieve good timings. Plus: I saw quite a difference in timings and slice usage between simple RGB332 and your somewhat complicated scheme. Also, the Q68 DACs don't have the same data width as Aurora and I may not be able to evenly spread the brightness of the Aurora mode over the full range (without further increase of design complexity).

The Aurora mode might still come, as a personal favour for someone who contributed enourmously to the Q68. But taking away the elegance of the Q68 video controller, which is an emotional issue in a design that is done neither for any financial reward, nor seeking for sales numbers.

Back to the flash bit, thanks for your explanations. I wonder how you can remember such things over such a long time. While I almost "lived" in QL schematics, 15 years ago, things get more and more lost for me...

Nasta wrote:Is it all a case of working under great pressure and a series of last minute decisions?

I have no other explanation.

Peter