Missing Display modes

[Gorf]

Originally Posted by Leffmann

A 256-color chunky mode obviously. Even OCS has the bandwidth for it in lowres.

I understand that extending the palette register file and LUT mechanism from 32 to 256 entries would've increased the cost, but would it really have been prohibitive?

the LUT is by far the biggest part of the chip - so in the early years too expensive - also no fun with 512k RAM (or even 256k as in the original A1000).

And I don't understand the arguments that the whole chip design would have had to be remade from scratch. If you have all the data required read into one or more holding registers, why is it difficult to select a different set of bits for the LUT? I'm sure these chip designs already solve more complex problems than that.

never said "from the scratch", but it would have added transistors as well:

we do not know how Denise exactly works internally, but planar modes in general work like layers on top of each other. So for Denise with 2 bitplanes it might work like looking at the first bit, if 0 it has to be one of only two registers, if 1 it must be one of two other registers ... the second bit than decides which of them even if this second bit only arrives a clock cycle later...

In a chunky mode the ram-dac chooses the value stored on the position given by the 8-bit value.

But that is just my personal theory why Commodore never managed to include a chunky mode....

The other reason is of course, that most Blitter operations are pretty useless on chunky pixels in RAM ... ok, copying blocks still works.

[Toni Wilen]

Originally Posted by Gorf

why super-high-res and productivity mode do have a limited palette of 64 colors in total

Color palette RAM is too slow for superhires (and perhaps shift registers too) so they needed hack to process 2 pixels per cycle: in ECS superhires mode palette is specially "encoded" to make it possible to fetch both odd and even pixel pair color from single palette entry, keeping original palette RAM access speed. AGA superhires works normally and does not even support ECS shres palette "scrambling".

Encoding is described in later HRM editions ECS chapter.

we do not know how Denise exactly works internally

Not fully but it can be almost fully guessed because demos doing BPLCON1 abuse horizontally generates side-effects that restricts possibilities greatly without extra complexity. (I described this in some BPLCON1 scaling thread)

(Why does everyone always want to decap chips that have very little unknowns. OCS or A1000 Agnus would be best candidate, less complex than later models which added features that are easy enough to understand without decapping. Even Paula's full internals would be more interesting than Denise!)

[Gorf]

Originally Posted by Toni Wilen

Color palette RAM is too slow for superhires (and perhaps shift registers too) so they needed hack to process 2 pixels per cycle: in ECS superhires mode palette is specially "encoded" to make it possible to fetch both odd and even pixel pair color from single palette entry, keeping original palette RAM access speed. AGA superhires works normally and does not even support ECS shres palette "scrambling".

Encoding is described in later HRM editions ECS chapter.

I did know about the encoding but not the exact reason for it.
Still not entire clear why the chip internal ram is so slow... MOS was able to produce faster chips like the VDC in the C128 @16Mhz in 85.

Not fully but it can be almost fully guessed because demos doing BPLCON1 abuse horizontally generates side-effects that restricts possibilities greatly without extra complexity. (I described this in some BPLCON1 scaling thread)

(Why does everyone always want to decap chips that have very little unknowns. OCS or A1000 Agnus would be best candidate, less complex than later models which added features that are easy enough to understand without decapping. Even Paula's full internals would be more interesting than Denise!)

because decapping is fun?
of course all of them should be done!

Thank you for your insight! Always great!
Anything you would consider as missed opportunity?

[Gorf]

An other nice idea, again from the IIgs (but my also available on other platforms):

A "sticky color" mode.
You define one entry (eg value 0000) that will not change the previous color, but repeat it until some other value comes along. So putting "red" in the fist pixel of a line followed by zero in all other pixels would make the whole line red.
This gives you a kind of automatic fill mode.

Imagine a vector graphic game or demo, where you only have to draw the wireframe and all in between gets filled for free. To change the frame, you only have to zero out the previous wireframe and drop a new one, since all pixels in between stay at zero in RAM.

[Toni Wilen]

Originally Posted by Gorf

I did know about the encoding but not the exact reason for it.
Still not entire clear why the chip internal ram is so slow... MOS was able to produce faster chips like the VDC in the C128 @16Mhz in 85.

Faster? Super hires = 28MHz pixel clock. Hires pixel clock is only 14MHz.

"Culprit" was most likely the usual: MOS/CSG was (very?) good in early to mid 1980s but when chip technology improvements started to accelerated quickly, they didn't keep up.

Anything you would consider as missed opportunity?

I don't think so (if you mean what to decap).

Blitter and DMA slot priority/sequencer schematics are the main thing that I really want to see someday..

[Photon]

No need for too complicated things with very special case modes. A charmode somehow would have been useful in games coming from C64, bitplanes was quite demonstrably the right choice in 1985 paired with the hardware performance, and AGA should have come in 1990 with a couple extra chunky mode resolutions, and that alone would have covered all the needs for the future.

Dreaming up a future graphics card is a different thing, although since RTG cards you'd be looking at a Denise mod. But the problem that has plagued expansions and mods is if they aren't adopted by enough people they die and if two major standards appear, platforms and platform support in software are divided for each.

So the problem for new cards is adoption. And chunky you can get, "just by putting in an RTG card in your A4000"

When that combo is easy to get and not too expensive, a common driver feature level can be supported for the many.

[bloodline]

Originally Posted by Toni Wilen

Faster? Super hires = 28MHz pixel clock. Hires pixel clock is only 14MHz.

"Culprit" was most likely the usual: MOS/CSG was (very?) good in early to mid 1980s but when chip technology improvements started to accelerated quickly, they didn't keep up.

I think the old CSG fab was very out of date by the late 80’s. IIRC Lisa had to be manufactured by HP

I don't think so (if you mean what to decap).

Blitter and DMA slot priority/sequencer schematics are the main thing that I really want to see someday..

I think Gorf wants to know if you feel there were some easy chipset wins, totally missed by Commodore?

Also I keep my eye on Visual6502, they have an Agnus and plan to recap it!

[Gorf]

Originally Posted by Toni Wilen

Faster? Super hires = 28MHz pixel clock. Hires pixel clock is only 14MHz.

ECS is 1990
OCS with max. 14 MHz is 1985 like the VDC with 16Mhz
So yes: the VDC is faster.

And according to the previous comment only the max. pixel-clock was doubled in ECS, leaving most of the chip untouched running on lower frequency, what leads to the insufficient bandwidth within it.

the point here:
a chunky 8-bit mode would not have worked on OCS/ECS even with more color-registers.
a chunky 4-bit mode with 16 colors could have been done, but would it been useful?

I don't think so (if you mean what to decap).

no, I was actually asking for some ideas regarding alternative screen modes and features, that could have been implemented without much fuzz in the original design.
Any thoughts?

[Gorf]

Originally Posted by Photon

No need for too complicated things with very special case modes. A charmode somehow would have been useful in games coming from C64,

And I am somewhat glad the Amiga does not have one.
It would have allowed for even cheaper conversions without any progress...

A tilemap mode is something people are wishing for here from time to time and it is a little bit different to a charmode ... but I do not see how a classical tile map mode would fit into the design easily.

That said, I do have an idea that comes quite close and that I would call "stitcher mode", as it could stitch multiple parts of a screen together without blitting.
more later.

and AGA should have come in 1990 with a couple extra chunky mode resolutions, and that alone would have covered all the needs for the future.

together with a faster Blitter of course

Dreaming up a future graphics card is a different thing...

and I did not want to go into this...

[Photon]

Well I do mention Denise mods, and they would have the same struggle for adoption as graphics card.

As an example of a special case mode, back in the day when I started coding filled vectors, I dreamed up a mode where I sacrificed black and made it repeat the previous color. This would make fills completely free and linedraw selective at any bitplane depth, the opposite of HAM vectors.

But I knew almost nothing about electronics then, so I couldn't have made one, let alone "modify a chip". You could have said it to me twenty times and got a blank stare or a wild cry of, "Liar!" back... chips were magical products that came from chip manufacturers

But we can dream. It's always allowed to dream, because some dreams become reality. We've seen this, we just don't know which ones will.

[bloodline]

Originally Posted by Gorf

the point here:
a chunky 8-bit mode would not have worked on OCS/ECS even with more color-registers.

ECS had the bandwidth... but not the palette capacity.

a chunky 4-bit mode with 16 colors could have been done, but would it been useful?

That was the Atari ST pixel format IIRC, it allowed two pixels per byte.

[Photon]

The ST used bitplanes, they just wanted to skimp on bitplane pointers cos registers cost money So you have 4 bitplanes on all the time and they interleave the words with the plane bits sequentially instead (a very 16-bit design thought(!)).

[Gorf]

Originally Posted by Photon

Well I do mention Denise mods, and they would have the same struggle for adoption as graphics card.

As an example of a special case mode, back in the day when I started coding filled vectors, I dreamed up a mode where I sacrificed black and made it repeat the previous color. This would make fills completely free and linedraw selective at any bitplane depth, the opposite of HAM vectors.

I described that same Idea above
The Apple IIgs (1986) had such a mode.

But I knew almost nothing about electronics then, so I couldn't have made one, let alone "modify a chip". You could have said it to me twenty times and got a blank stare or a wild cry of, "Liar!" back... chips were magical products that came from chip manufacturers

chips - no they come out of the kitchen made from potatoes
FPGAs are still kind of magical, aren't they?

But we can dream. It's always allowed to dream, because some dreams become reality. We've seen this, we just don't know which ones will.

yes - that is probably the reason for this thread ... as well as the love for our Amiga and retro-computing.
Somehow I find it more interesting what was and what could have been done with the limited technology back than ... modern hardware has not enough restrictions and does not need such clever tricks anymore.

But we are not the only ones ... modern computers and hardware did become only easier on the surface, while the systems itself did become impossible to understand and manage for a single person. And more and more people long for things that bring back the joy of computing of the early days.

[Gorf]

Originally Posted by Photon

The ST used bitplanes, they just wanted to skip on bitplane pointers So you have 4 bitplanes on all the time and they interleave the words with the plane bits sequentially instead (a very 16-bit design thought).

good point and it would have been easy to implement for the data fetching part... but little bit more complicates for some bitter operations.
Only really useful for ST compatibility, or am I missing some other features?

[bloodline]

Originally Posted by Photon

The ST used bitplanes, they just wanted to skimp on bitplane pointers cos registers cost money So you have 4 bitplanes on all the time and they interleave the words with the plane bits sequentially instead (a very 16-bit design thought(!)).

Hmmm, I don’t really understand the ST, it seems like an 8bit machine with a 68000

[Gorf]

Originally Posted by bloodline

That was the Atari ST pixel format IIRC, it allowed two pixels per byte.

As Photon pointed out: the ST stores the screen in interleaved bitplanes (word aligned) - so 16 bit of the first plane, than 16 bit of the second and so on.
To get the first pixel of a 16 colour screen you still have to read 4 words (64 bits) first.

A 4bit chunky mode is different, storing a pixel in 4-bit nibbles.
(I think the Neo-Geo used this mode...)

[Gorf]

next idea, that would be "easy" to implement: mirrored sprites.

As sprites are (line-wise) read before the other display data and stored in buffers, it should be not too hard to change the endianness of that buffer and read a sprite-line from the end.

normal:
0-1-2-...-14-15

reversed:
15-14-...-2-1-0

and allow 32 pixel wide symmetrical sprites:
0-1-2-...-14-15 | 15-14-...-2-1-0

there was an interesting thread here about using sprites as a third playfield in the background. It works, but is somewhat complicated.
It could be assisted by allowing self repeating sprites (without copper interaction)

So next to the sprite position you would tell Denise to mirror and/or repeat a sprite until this is overwritten by an other sprite (or store a number how many times the sprite should be repeated)

[bloodline]

Originally Posted by Gorf

As Photon pointed out: the ST stores the screen in interleaved bitplanes (word aligned) - so 16 bit of the first plane, than 16 bit of the second and so on.
To get the first pixel of a 16 colour screen you still have to read 4 words (64 bits) first.

Ahhh, that makes sense, cheers for the clarification.

A 4bit chunky mode is different, storing a pixel in 4-bit nibbles.
(I think the Neo-Geo used this mode...)

I didn't know this!

[Gorf]

Originally Posted by bloodline

Ahhh, that makes sense, cheers for the clarification.

the benefit of this ST way of fetching data is simply that you do not need to jump around in memory and only need one pointer to the start of your screen.
All is read in a consecutive way...

This scheme would then also be beneficial for 32bit or 64bit wide fetches (as in AGA). Where our Lisa has to fetch up to eg. 4x64bit -> 256 bits into buffers before showing the first pixel of a 4-bitplane screen this could be done in just one single fetch with interleaved bitplanes.

A disadvantage is of course more complicated Bllitter operations.
So the transistors one would save by getting rid of the buffers would need to be spent on a more complex Blitter (or more instructions in code).

[NorthWay]

I never got why the Copper is every other access slot. Logic timing limits?
And the Blitter could have had a mode where it used hw sprite data as input. Or is that actually possible for 2bpl mode with the right minterm?
(Do you want more from my list of "missed opportunities in OCS"? :-)