noob copper question

[jotd]

I'm considering emulating an old 8-bit machine (Oric) display using the same technique used in the past:


- 1 bitplane (2 colors: background and foreground)

- dynamic color switching


For that I need to be able to change one (possibly 2) colors in a time for horizontal beam to draw 6 pixels maximum. Is that possible / reliable? or just too short?

[Kalms]

Too short. The copper can perform 1 operation per 8 lores pixels under ideal conditions. You will need to rely on some other method. For example, perhaps you can draw the color pattern into bitplanes, but perform 1x -> 8x stretch vertically for the color bitplanes by manipulating bpl ptrs or bpl modulos at the start of every line.

[jotd]

the Oric was able to do that ... okay. Thanks...

Wait! when I want to change the background or foreground, I have to write a byte, but if I want to change background THEN foreground, it's okay. There's a 6 pixel gap between each operation. But the result (foreground) is expected 12 pixels later:

<background attribute> <foreground attribute> <pattern>
0 6 12

I don't really care if the foreground attribute changes at pixel 10 as long as it changes at pixel 12... Same goes if I want to change other attributes afterwards. There's always a 6-pixel "deadzone". If I eliminate attribute changes that aren't useful (ex: 2 consecutive foreground switches) that may be okay.

[roondar]

You might be able to trick something using a race-the-beam setup and using more bitplanes to 'buffer' colours. However, if that works (I've not calculated it yet in detail, but my gut tells me it is doable for at least reasonably wide screens with a one change per six pixels restriction) it would take a lot of DMA bandwidth. So much so that it may only be useful for stills.

It'd be fiddly too as you'd basically be setting the shown colours of all pixels on screen using the Copper.

[Photon]

Originally Posted by jotd

the Oric was able to do that ... okay. Thanks...

Emulating hardware chips with software will always be slower.

No chance for a realtime emu on OCS. AGA should be able to set 40x2 colors per line, first char using COLOR01 and 02, second COLOR03 and COLOR04 etc. Track color and character changes and only update those, if scrolling do a hardware scroll with bitplane pointers in a rolling buffer. The same could be done on OCS but instead of generating a Copper you generate a bitmap. Only use the CPU then, it will run at almost 100% speed. It will still be ~1000 chars to draw, so best case only ~10 FPS.

This should make most if not all programs and games run. If a few demos rely on timing tricks, and you expect to solve that, well consider that some GHz emus don't. So don't feel bad