Computer graphics during the 8 bit era

[RMartins]

@RMartins, consider this simplified example:

Code: Select all

BBBBrrrrrrrrrrrrrrrrBBBBhhhh

-p-pVpVpVpVpVpVpVpVp-p-p-p-p	50/50 split	= 8V 14p 6-

pppVVVVppppVVVVppppppppppppp	buffered	= 8V 20p

...

You just confirmed what I stated in a previous message.

You are considering that accesses would NOT be ping/pong (pVpV), but something else (ppppVVVVppppppppp), and that there will be enough buffering (VVVV).
Besides all of this being system design changes, that affect Display circuitry, and sync/stop with CPU (which is more complex than the simple Ping/Pong design), it's not clear if you are just shuffling the order of accesses around, without any real benefit, except the CPU eventually using the gaps that the Display is not using.

And if this is the goal (use the unused display slots), a "simpler" signaling from the Display circuitry, enabling the CPU to use the slots the Display will not use (providing extra clocks to CPU), would give the same effect without all the extra complexity.

Overall a more complex and less deterministic system, than a Display and CPU that run at fixed CONSTANT speed, with predetermined reserved slots for access.

[RMartins]

...
good enough, but the main gain is at the top & bottom borders (including vblank)

Yes, when the display is not using its reserved slots these could be used by the CPU.

However, this makes the Design a bit more complex, since it requires some form of synchronisation/enable/stop clock of the CPU (or wait states), so that it could re-use these slots.

The original design is a bit wasteful on memory bandwidth that goes unused, but a lot simpler and cleaner.
But on the other hand it also supports some other features like hardware sprites, in the middle of those display accesses.

Being able to manage buffering of those dynamically moving accesses to sprite data, would be a control nightmare.

An alternative other solution is like you mention ...

no need for EXTRA (chip capacity) if it isn't wasted on hw sprites

Just remove the hardware sprites feature.

[RMartins]

@AndyC, you don't understand. I said available memory bandwidth, not the bus. The bus clock has no impact on it. And you don't have to use such primitive memory sharing (that was not enough anyway and still required unpredictable stalling of the already crippled CPU). The CPU could be clocked higher as long as the memory tolerates it - and the memory already operates twice as fast. So with better memory management it was possible to clock the CPU @2MHz and lose less than 50% of these cycles for video generation. Not over 50% as it was done.

This is perfectly valid, if by "memory management" you mean, a completely different pattern of access to the memory bus and hence a completely different system design.

AndyC, as far as I understood it, always replied with the assumption that the system design wasn't changed, i.e. the memory access ping/pong patterns wouldn't change.

So like I said before, both were right, given the correct context.

[1024MAK]

Which ever way you look at this, the reality was that a compromise had to be reached between:

• The cost of RAM (back in the early 1980s, DRAM chips were very expensive and SRAM was even more expensive);
• If DRAM is used, it needs to be refreshed, either a separate refresh system, or if possible, by the act of the display system reading enough of the addresses such that all of the DRAM rows are accessed within the enquired time (2ms or 4ms depending on which type of DRAM chip is used);
• The transfer speed that the RAM can manage, keeping in mind that faster RAM costs substantially more than the same amount of slower RAM;
• The video system must never run of of data, otherwise you get lost video which uses will see as glitches in the video picture,
• You must allow the microprocessor enough time to access the RAM that has the video picture stored in it, otherwise you end up with the problem the Acorn Electron has with memory intensive screen modes, where the microprocessor is halted for the entire time that a horizontal display line is drawn;
• Including large memory buffers in custom chips back in the early 1980s was really expensive (just as, or more expensive than SRAM);
• The complexity of the timing and logic control system. The faster and/or more complex this is, the more expensive it becomes.
• Development time. More complex systems cost more because the development time is longer. If it takes too long to move to being manufactured, you may loose the slot in the market to a competitor...

Both the ZX Spectrum and the Commodore 64 were intended to be low cost machines. The market that was aimed for, was of course, for use in the home. So it very much was maximum features but at the lowest possible cost. And given what we now know, of course it’s possible to get more out of them if we could redesign them from scratch. But it’s not really appropriate to use the knowledge that we have now (hindsight) to redesign things from the past. It’s very likely that the designer(s) knew about these limitations and some of these were choices. Either driven by cost, timescales or both. As it is, they are what they are.

Mark

[Lethargeek]

You are considering that accesses would NOT be ping/pong (pVpV), but something else (ppppVVVVppppppppp), and that there will be enough buffering (VVVV).
Besides all of this being system design changes, that affect Display circuitry,

so? this is the exact thing being discussed here, after all

and sync/stop with CPU (which is more complex than the simple Ping/Pong design),

and this is being done by the real VIC anyway (for badlines and sprite data) WITH ping/pong

it's not clear if you are just shuffling the order of accesses around, without any real benefit, except the CPU eventually using the gaps that the Display is not using.

WOW how +55% of performance isn't "real benefit" for you?

And if this is the goal (use the unused display slots), a "simpler" signaling from the Display circuitry, enabling the CPU to use the slots the Display will not use (providing extra clocks to CPU), would give the same effect without all the extra complexity.

simpler? this will need two clocks and will give less performance improvement

Overall a more complex and less deterministic system, than a Display and CPU that run at fixed CONSTANT speed, with predetermined reserved slots for access.

1) start/stop could be completely deterministic (Spectrum anyone?)
2) CPU running at CONSTANT low speed won't be able to use reserved slots, as these are shorter than its clock periods
3) CPU running at CONSTANT double speed will need start/stop manager

However, this makes the Design a bit more complex, since it requires some form of synchronisation/enable/stop clock of the CPU (or wait states), so that it could re-use these slots.

The original design is a bit wasteful on memory bandwidth that goes unused, but a lot simpler and cleaner.
But on the other hand it also supports some other features like hardware sprites, in the middle of those display accesses.

see above (the bolded part)

Being able to manage buffering of those dynamically moving accesses to sprite data, would be a control nightmare.

it isn't neither dynamic nor control nightmare for the badlines
it IS dynamic and unpredictable for the hw sprites though

AndyC, as far as I understood it, always replied with the assumption that the system design wasn't changed, i.e. the memory access ping/pong patterns wouldn't change.

no, his assumption was splitting the bus time 50/50 has "zero impact" on performance, which is obviously wrong

[Lethargeek]

Both the ZX Spectrum and the Commodore 64 were intended to be low cost machines.

so? doesn't mean it was impossible to design better machines to be about the same cost

But it’s not really appropriate to use the knowledge that we have now (hindsight) to redesign things from the past.

why not? it's not like we're talking possible (but unknown at the time) ideas and technology
just about the design choices, all the necessary tech and knowledge was available

[AndyC]

AndyC, as far as I understood it, always replied with the assumption that the system design wasn't changed, i.e. the memory access ping/pong patterns wouldn't change.

no, his assumption was splitting the bus time 50/50 has "zero impact" on performance, which is obviously wrong

The 6502 will only ever use the ping of a ping/pong type arrangement and that was what my assumptions are based upon. It doesn't matter how fast you clock a 6502, the bus will always sit idle 50% of the time so you might as well optimize the video circuitry around using that time.

I mean sure if you completely redesigned the 6502 so that it could make bus accesses on both the ping/pong parts of a cycle then you could come up with a different bus access scheme that might be more efficient but I'm assuming that's not really a practical option.

[Lethargeek]

The 6502 will only ever use the ping of a ping/pong type arrangement and that was what my assumptions are based upon. It doesn't matter how fast you clock a 6502, the bus will always sit idle 50% of the time

"time" measured in WHAT? i'm talking about full memory access cycles as the smallest unit of measurement

so you might as well optimize the video circuitry around using that time.

"optimize" for WHAT? cost (of this part of the system) or performance? simple even splitting doesn't optimize 6502 performance

I mean sure if you completely redesigned the 6502 so that it could make bus accesses on both the ping/pong parts of a cycle then you could come up with a different bus access scheme that might be more efficient but I'm assuming that's not really a practical option.

again, you're talking CPU cycles, i'm talking memory cycles - these two types don't have to be the same length

[AndyC]

I'm talking about actual wall time. In 2ms, a 6502 on its own will always leave the bus idle for 1ms. It doesn't matter how fast you clock it.

[Lethargeek]

I'm talking about actual wall time.

and what's the point and practical use of this info?

In 2ms, a 6502 on its own will always leave the bus idle for 1ms.

no, a 6502 leaves it FREE (for the other system parts to use) - NOT IDLE
the BUS may or may not be actually idle during this time
(it is not for duration of the VIC raster scanline part)

It doesn't matter how fast you clock it.

no, it does - depending on the memory clock

[catmeows]

Completely unrelated question
Assume 6809 system @1.75 MHZ, with CPU and video chip accessing DRAM on opposite edges of clock.
System has 8*64Kb DRAM with cycle time less than 280 ns.
I have found some 64Kb DRAM as early as 1979 (most likely around $500+ for 8 chips).
I'm thinking of simple, high performance home computer build of 6809, 8*DRAM, ROM and 2*ASIC: 1) video&memory management, 2) sound&IO. Simple design like Timex or Oric, not the modular design of BBC or Apple.

So, could such computer start by 1980 with price tag under $800 and follow fall of DRAM to price about $200 in 1982/1983 ?

[AndyC]

*sigh*, I'm going to regret this but one last time.

I was measuring in wall time because it doesn't matter. You can measure in seconds, cycles, phases of the moon. The 6502, on its own, will leave the bus idle 50% of the time. Yes, I know that in a C64 this time is used by the VIC. And it's used by the VIC precisely because it's the best time to use, because the CPU will never need access in this time. And it doesn't matter how fast you clock the CPU or how fast an individual memory read is, this timing won't change. This is the most fundamental thing to grasp.

Let's consider your simplified example:

@RMartins, consider this simplified example:

Code: Select all

BBBBrrrrrrrrrrrrrrrrBBBBhhhh

-p-pVpVpVpVpVpVpVpVp-p-p-p-p	50/50 split	= 8V 14p 6-

pppVVVVppppVVVVppppppppppppp	buffered	= 8V 20p

where:

Code: Select all

B border
r raster
h hblank
p CPU access
V VIC access
- VIC idle

(this is ordinary raster line, not a badline)

good enough, but the main gain is at the top & bottom borders (including vblank)

Sounds great, right. By buffering you've gained 6 extra CPU memory accesses? Well no, because you've ignored that the CPU will never, ever, access the memory on the alternate half cycles. So let's apply that fact to the buffered example:

Code: Select all

-p-pVpVpVpVpVpVpVpVp-p-p-p-p	50/50 split	= 8V 14p 6-
pppVVVVppppVVVVppppppppppppp	buffered	= 8V 20p
-p-VVVVp-p-VVVVp-p-p-p-p-p-p	reality  	= 8V 10p

As we can see, the net effect is that stalling the CPU in order to let the video chip have longer consecutive accesses just reduces the overall CPU throughput and doesn't really gain us anything. More bus time ends up spent idling because our revised design isn't optimizing its access patterns around the best possible time to make those accesses.

[Lethargeek]

Sounds great, right. By buffering you've gained 6 extra CPU memory accesses? Well no,

Well, YES...

because you've ignored that the CPU will never, ever, access the memory on the alternate half cycles. So let's apply that fact to the buffered example:

...because you ignored the fact that the CPU in the 2nd example is DOUBLE CLOCKED

So let's apply that fact to the buffered example:

So let's apply that fact to the buffered example:

Code: Select all

-p-pVpVpVpVpVpVpVpVp-p-p-p-p	50/50 split	= 8V 14p 6-
pppVVVVppppVVVVppppppppppppp	buffered	= 8V 20p
pppVVVVppppVVVVppppppppppppp	reality		= 8V 20p

[AndyC]

Doubling the clock speed doesn't matter. It only doubles the number of half cycles you have in a given amount of wall time.

So, in a simplified example (with numbers that are easy, not realistic)

Imagine the base CPU has 1000 cycles in 10ms. The are 1000 unused half cycles, accounting for 5ms of idle time that the video circuitry might as well use.

Let's double the clock speed and see what happens:

There are now 2000 cycles in 10ms. There are therefore 2000 unused half cycles, accounting for 5ms the video circuitry might as well use.

See how that works?

What if there is a tenfold increase in speed? 10000 cycles and still 5ms of unused time the video circuitry might as well use.

Altering the clock speed doesn't alter the calculation of how much bus time the CPU doesn't use, it just apportions it out into smaller chunks. It's still better to use that time rather than stalling the CPU when you don't need to.

[Lethargeek]

Doubling the clock speed doesn't matter. It only doubles the number of half cycles you have in a given amount of wall time.

no, mentioning CPU "half cycles" over and over again doesn't matter, as we're talking MEMORY CYCLES

Imagine the base CPU has 1000 cycles in 10ms. The are 1000 unused half cycles, accounting for 5ms of idle time that the video circuitry might as well use.

Imagine the base MEMORY has 2000 cycles in the same 10ms, all of these may be well used for anything whenever necessary

There are now 2000 cycles in 10ms. There are therefore 2000 unused half cycles,

NO - these "half cycles" all belong to the USED MEMORY CYCLES now!
and you cannot split these cycles further, memory is not fast enough for this
so there is ZERO "unused half cycles"

What if there is a tenfold increase in speed?

no "tenfold increase in speed" because MEMORY in this example can't support it

MEMORY MEMORY MEMORY MEMORY MEMORY MEMORY MEMORY - is it enough now for you to remember?

[1024MAK]

Excuse me. In a 6502 system without a memory mapped video display system, the processor cycle is exactly the same as the memory access cycle. That’s the whole point of the 6502 architecture. It’s cheap!

If you now use faster RAM, then when the 6502 clock is high, the processor accesses memory as normal. But when the 6502 clock is low, you can use tristate buffers to isolate the processor from the system RAM. Then the video display system can use this time to fetch screen data from the RAM. Hence the RAM speed is ‘double’ compared to my first example (although in reality it’s not quite as simple as that).

With a Z80 system, because the Z80 does not have the same predictable memory access cycles, either you have to stop the Z80 when ever it tries to access the RAM at the same time as the video system is using it (as done in the ZX Spectrum) or alternatively stretch all the Z80 cycles to a longer and predictable pattern so that you can interleave the video system RAM accesses (which is what the Amstrad CPC series does).

Yes, it’s possible to use buffers to allow the video system more time between main memory reads. But this makes the system more complex and even more costly. And it does not change the overall data rate between the main memory and the video system.

Unless of course you don’t use a memory mapped system and instead put the video RAM on a completely separate bus (as done in MSX machines).

Whatever you go for, the limitations on what DRAM speed was affordable still comes into it. As does the ability of the microprocessor to actually move data around. No point in having a very high resolution display if the processor is not fast enough to move enough data around to achieve animation...

Mark

[Lethargeek]

Excuse me. In a 6502 system without a memory mapped video display system, the processor cycle is exactly the same as the memory access cycle. That’s the whole point of the 6502 architecture. It’s cheap!

If you now use faster RAM, then when the 6502 clock is high, the processor accesses memory as normal. But when the 6502 clock is low, you can use tristate buffers to isolate the processor from the system RAM. Then the video display system can use this time to fetch screen data from the RAM. Hence the RAM speed is ‘double’ compared to my first example (although in reality it’s not quite as simple as that).

btw the c128 has 2MHz CPU mode with the VIC being switched off

With a Z80 system, because the Z80 does not have the same predictable memory access cycles, either you have to stop the Z80 when ever it tries to access the RAM at the same time as the video system is using it (as done in the ZX Spectrum) or alternatively stretch all the Z80 cycles to a longer and predictable pattern so that you can interleave the video system RAM accesses (which is what the Amstrad CPC series does).

Yes, it’s possible to use buffers to allow the video system more time between main memory reads. But this makes the system more complex and even more costly.

Can't agree here. The real VIC is already using CPU stalling when reading badlines and sprite data. I don't think it needs to be extended too much to support the Atari-like memory sharing scheme - most likely much less than quoted 3/4 of the chip space the hardware sprites are taking!

And it does not change the overall data rate between the main memory and the video system.

it does change the CPU performance and the data rate between the CPU and video memory

And it does not change the overall data rate between the main memory and the video system.

Unless of course you don’t use a memory mapped system and instead put the video RAM on a completely separate bus (as done in MSX machines).

Whatever you go for, the limitations on what DRAM speed was affordable still comes into it. As does the ability of the microprocessor to actually move data around. No point in having a very high resolution display if the processor is not fast enough to move enough data around to achieve animation...

8-bit Ataris use memory mapping, have 1.79MHz CPU clock and are visibly faster than the c64 in isometric and 3D games

[Pegaz]

Then it's not clear to me, how the C128 at 2 Mhz in VDC mode, works visibly faster with 3D Ultimate titles like Gunfright, Knight Lore, Alien 8, Pentragram, than Spectrum or Amstrad versions at 3.5/4.0 Mhz?
No VIC chip and hw sprites, just plain bitmap graphics and CPU.

https://www.youtube.com/watch?v=KwCznVcVTPw&t=8s
https://www.youtube.com/watch?v=bAE2RIVcauo

Also, all these games in the C64/Plus4 versions, run at the Spectrum speed level, with an even lower cpu clock of 1Mhz/1.76 Mhz.
btw, here's a Knight Lore comparison between the Atari 8-bit and C64 versions.
It doesn't seem to me that the Atari version is visibly or faster at all, while the C128 version of the Knight Lore is superior, it just flies.

https://www.youtube.com/watch?v=HdvInDE58j0
https://www.youtube.com/watch?v=pShpzdfJuZk

[Lethargeek]

Then it's not clear to me, how the C128 at 2 Mhz in VDC mode, works visibly faster with 3D Ultimate titles like Gunfright, Knight Lore, Alien 8, Pentragram, than Spectrum or Amstrad versions at 3.5/4.0 Mhz?
No VIC chip and hw sprites, just plain bitmap graphics and CPU.

well, because "no VIC" - full 2MHz > stalled 1.79MHz 6502

Also, all these games in the C64/Plus4 versions, run at the Spectrum speed level, with an even lower cpu clock of 1Mhz/1.76 Mhz.
btw, here's a Knight Lore comparison between the Atari 8-bit and C64 versions.
It doesn't seem to me that the Atari version is visibly or faster at all, while the C128 version of the Knight Lore is superior, it just flies.

Knight Lore is flip-screen and thus less CPU demanding
now compare scrolling isometric Nightshade
(also note c64 version using sprites)

[Pegaz]

Ok, but If the KL isn't too demanding for the 6502 2Mhz, it shouldn't be for the Z80 on the higher clock, too.
Code optimization may also have a significant impact.
All the Ultimate games we mention are new ports for the C64/128/A8, but the CPC Gunfright and C64 Night Shade are still the original 35-year-old versions.
I'm almost sure it could be faster and better, with the technique that the author of C64 ports used for KL, Alien8, Gunfright and Pentagram...

[Lethargeek]

Ok, but If the KL isn't too demanding for the 6502 2Mhz, it shouldn't be for the Z80 on the higher clock, too.

on average 6502 1MHz ~ 2MHz Z80 so definitely 2MHz 6502 > 3.5MHz Z80 (even uncontended)

Code optimization may also have a significant impact.
All the Ultimate games we mention are new ports for the C64/128/A8, but the CPC Gunfright and C64 Night Shade are still the original 35-year-old versions.
I'm almost sure it could be faster and better, with the technique that the author of C64 ports used for KL, Alien8, Gunfright and Pentagram...

also for me the Atari KL in your vidz looks a bit faster than c64 KL
the difference must be more visible in crowded rooms

(also note c64 version using sprites)

here i was wrong though - checked it on small phone screen now i can see attributes

[Pegaz]

Yes, all four of these new C64 ports are practically one man project and all are done without hw sprites and scrolling.
Honestly, just a few years ago, I wouldn't have believed that this kind of speed was possible on the C64 in such 3D titles.
After all, here are a few quotes, what the author himself said about these ports:

Again this is all CPU grunt (the only hardware sprite is used on the title screen and no hardware scrolling is used) but the speed is still very good.

The C128 VDC version is by far the fastest version (I haven't seen any 8 bit version even close to the VDC version) as the CPU is running at almost 2Mhz all the time. The C128 Vic II version is next with the CPU running at about 1.27Mhz each frame (and apart from the VDC version it is the fastest 8 bit version I've seen).

The Plus4 & C64 versions run around the same speed as the Spectrum version. The Plus4's CPU is running at around 1.16Mhz per frame as the CPU speed is cut in half when the raster beam is in-line with the screen area, so it's about 10% faster than the C64 version.

[1024MAK]

And it does not change the overall data rate between the main memory and the video system.

it does change the CPU performance and the data rate between the CPU and video memory

No, using a buffer just time shifts the data for the video system. The data rate over the course of a video frame is the same. Everything that the video system displays has to be fetched from RAM at some point.
If you buffer too much data, the video system may miss recent changes/updates to the picture data in main RAM made by the microprocessor.

Of course in some instances, the video system may require less data.

In terms of the difference to the microprocessor, if you use page mode and/or as rapid reading of the data as the access speed of the DRAM allows, and in doing so get the video system to read ahead and fill a multibyte buffer, then the video system will not require to halt/pause or otherwise suspend access to the DRAM by the microprocessor as often. But if the microprocessor is not making full use of this time because it’s a 6502 which only accesses DRAM for half of its clock cycle, then where is the advantage? There is an advantage if you have a Z80 microprocessor system. But I was not talking about such a system earlier.

Or are you actually trying to make the case that you want even more screen data during this time? In which case we go full circle back to higher resolutions/more complex systems costing more money...

Mark

[Lethargeek]

it does change the CPU performance and the data rate between the CPU and video memory

No, using a buffer just time shifts the data for the video system. The data rate over the course of a video frame is the same. Everything that the video system displays has to be fetched from RAM at some point.

no, you're still talking about the displaying when i'm talking about filling the memory
you see no benefits for dispalying the video memory, i see benefits for processing it

If you buffer too much data, the video system may miss recent changes/updates to the picture data in main RAM made by the microprocessor.

not a big deal, and with scanline-precise interrupts no problems at all

In terms of the difference to the microprocessor, if you use page mode and/or as rapid reading of the data as the access speed of the DRAM allows, and in doing so get the video system to read ahead and fill a multibyte buffer, then the video system will not require to halt/pause or otherwise suspend access to the DRAM by the microprocessor as often. But if the microprocessor is not making full use of this time because it’s a 6502 which only accesses DRAM for half of its clock cycle, then where is the advantage? There is an advantage if you have a Z80 microprocessor system. But I was not talking about such a system earlier.

repeat: the processor IS making FULL use of MEMORY time when 6502 cycle = RAM cycle
in this case the memory can't do better, can't support any extra access in half-cycles
is it so bloody hard to understand?

Or are you actually trying to make the case that you want even more screen data during this time? In which case we go full circle back to higher resolutions/more complex systems costing more money...

we're going in circles because you guys keep blabbering about half-cycles even when it doesn't matter at all

[1024MAK]

[Mention]Lethargeek[/Mention] so as you can see from this 6502 timing diagram, it only ever reads or writes to memory at the end of the Φ2 or PHI2 clock period (the processor clock). Although it puts the address and R/W lines to valid states part way through the low part of PHI2, if you are using RAM that is fast enough, you can use tristate buffers or multiplexers to isolate the 6502 from the RAM address bus until the beginning of the high part of PHI2. Then the video system can use all the time that PHI2 is low to access the RAM. At higher 6502 clock frequencies this becomes less practical as the set-up times eat into the available RAM access time, but it’s fine for a 1MHz or 2MHz 6502 system.

Now you are disagreeing with others on here and with me. It could just be a misunderstanding. So maybe you would like to go into greater detail to explain what you mean?

Mark