crtc atari 2600-like

[zhulien]

I want to output to crtc atari 2600-like.  How do I go about that on cpc?

If doing so what are the pros and cons, does it use cpc video ram or none at all?

[andycadley]

The CRTC doesn't actually produce any image. You'd have to turn the display off and then just keep writing to the border colour register in the Gate Array.

It wouldn't "use any screen RAM" although obviously the code necessary to generate an image will consume an awful lot as well as all the processor time. And the resolution will be incredibly low.

[McArti0]

https://www.cpcwiki.eu/forum/programming/125-colors-in-basic-very-important-unnecessary-thing-cpc6128-0-66mhz/msg228289/#msg228289

7x200 resolution 

[zhulien]

T

https://www.cpcwiki.eu/forum/programming/125-colors-in-basic-very-important-unnecessary-thing-cpc6128-0-66mhz/msg228289/#msg228289

7x200 resolution 

thanks, looks like something useful for me to test.

[McArti0]

BUT you can make 1 line screen and update this 80 byte VRAM always.

[zhulien]

T

https://www.cpcwiki.eu/forum/programming/125-colors-in-basic-very-important-unnecessary-thing-cpc6128-0-66mhz/msg228289/#msg228289

7x200 resolution 

thanks, looks like something useful for me to test.

For this method, do we have to use the OUTI instruction or can OUT (C), C be used?

[McArti0]

Count clocks. 

[zhulien]

I've been playing with the CPC Wiki Raster 1 sample.  I'm guessing Rasters are doing this?  I can understand the code but... do we have to have interrupts enabled or is it just easier to position the raster?

I have tried disabling and instead of halts, putting from small to large defs (nops) but still couldn't see anything.

Modified raster sample to see how quickly CPC can change colours on a single pixel line - seems 6 changes (7 colours).

Is this basically how Atari 2600 does it?  I have read and watched (on youtube) dev tutorials for Atari 2600 but thought maybe that can be applied to CPC, but is CPC really that much slower at changing the colours than the Atari 2600?

[zhulien]

Code Select Expand

org &8000

.scr_set_mode equ &bc0e

ld a,1
call scr_set_mode

di
im 1

ld hl,&c9fb
ld (&0038),hl

ei

;; select border
ld bc,&7f10
out (c),c

;; set border colour to black
ld bc,&7f47
out (c),c

.main_loop

; wait for frame flyback
ld b,&f5
.ml1
in a,(c)
rra
jr nc,ml1

;;----------------------------------------

halt
halt
halt
halt
halt
halt

;; delay so that colour change position is not visible (hidden by border
;; and horizontal flyback)
;defs 47
defs 46

;; select pen to change (colour 0)
ld bc,&7f00               ;; [3]
out (c),c                 ;; [4]

;; change colours
ld a,#5a
out (c),a

ld a,#4c
out (c),a

ld a,#5a
out (c),a

ld a,#4c
out (c),a

ld a,#5a
out (c),a

ld a,#4c
out (c),a

ld a,#5a
out (c),a

ld a,#54
out (c),a

defs 16

ld a,#5a
out (c),a

ld a,#4c
out (c),a

ld a,#5a
out (c),a

ld a,#4c
out (c),a

ld a,#5a
out (c),a

ld a,#4c
out (c),a

ld a,#5a
out (c),a

ld a,#54
out (c),a


defs 16

ld a,#5a
out (c),a

ld a,#4c
out (c),a

ld a,#5a
out (c),a

ld a,#4c
out (c),a

ld a,#5a
out (c),a

ld a,#4c
out (c),a

ld a,#5a
out (c),a

ld a,#54
out (c),a


defs 16

ld a,#5a
out (c),a

ld a,#4c
out (c),a

ld a,#5a
out (c),a

ld a,#4c
out (c),a

ld a,#5a
out (c),a

ld a,#4c
out (c),a

ld a,#5a
out (c),a

ld a,#54
out (c),a


jp main_loop

[andycadley]

It's close to how the 2600 does it, in the sense it's about "chasing the beam". But the 2600 has special hardware to help out with this, in that it contains a very small frame buffer that either repeats or mirrors on each line and thus racing the beam is really about reloading this buffer rather than palette switches so you have a little more control over the time things happen.

You don't have to have interrupts enabled on the CPC to pull this kind of thing off, but you have very little capability to figure out where in the frame you currently are (there are no registers you can poll for current raster position etc) so you're very limited on what you can do without using the interrupts to a least vaguely position changes.

[McArti0]

Out (c),c
Out (c),a
Out (c),h
Out (c),l
Out (c),d
Out (c),e
Exx
Out (c),c
Out (c),h
Out (c),l
Out (c),d
Out (c),e

But what doing now...

[lightforce6128]

Besides changing colors to create a split raster also one scanline can be updated multiple times. So for each scanline on the display there is only one scanline of RAM (e.g. &C000-&C04F). If the content of this RAM is changed, the scanline will look differently at each display position. To achieve this, the CRTC needs to be reprogrammed to create a one-line-image and "forget" about to inform the monitor that the image is completed. There is a common demo effect that makes use of this.

The question is: How many of the 80 bytes can be updated before the beam reaches them again? The hardware of the Atari 2600 automatically handles updates of the background (loading the right line from ROM) and also handles some smaller (colored dots) and bigger sprites. So here, many things can be achieved by updating the configuration here and there. Without this help, every change needs to be done by the CPU, and on each scanline there are only 64 NOPs available.

[lightforce6128]

Out (c),c
...
Exx
...
Out (c),e

But what doing now...

The registers are the pens, and each OUT command creates one big pixel (EXX will stretch the previous pixel even further). A full screen can be drawn with a long list of OUT commands. This would need much memory and only give a static image. But during HSYNC no color needs to be changed. The parts of the OUT list can be reused or an animation can be done by changing the used OUT lists over time.

[lightforce6128]

You don't have to have interrupts enabled on the CPC to pull this kind of thing off, but you have very little capability to figure out where in the frame you currently are (there are no registers you can poll for current raster position etc) so you're very limited on what you can do without using the interrupts to a least vaguely position changes.

One possibility is to use VSYNC and interrupts to go to one known position on screen once, then to turn off interrupts and make sure that the main loop of the program exactly takes 19.968 NOPs, in all situations. It is a nightmare to develop software like this (balancing all code parts for exact timing), but then you will always know where the beam is currently.

Another possibility is to again use VSYNC and interrupts to go to one known position on screen once, but to keep the interrupts running and continuously count from 0 to 5 to know which interrupt is which one. With this, one get to know the position of the beam at six (almost) defined positions on screen. From there with some (well used) delay other positions on the screen can be reached. BUT: An interrupt will never cut an already running instruction in halves. So the interrupt may be delayed if it happens during a longer lasting instruction. To avoid this, there should be only short instructions in the region where the interrupt will occur ... another nightmarish restriction on software development.

[Anthony Flack]

Essentially the 2600 has a line buffer instead of a screen buffer. But it also has several hardware sprites on that line buffer, which the CPC can't really emulate fast enough to race the beam.

However the making of Logon's Run article published on NoRecess' website does talk about a technique, used there and also in the Batman Forever demo, where a single updated scanline (or two) is racing the beam and being continuously updated.

http://norecess.cpcscene.net/the-elders-scrollers.html

[lightforce6128]

... a technique ... where a single updated scanline (or two) is racing the beam and being continuously updated.

That is an interesting approach. If there are many changes in one line, followed by only a few changes in the next line, the approach with two scanlines can cover this. Only on average each scanline has 64 NOPs available. A single scanline might use much more, if the next one compensates this by using less. This allows to use more different and more complex shapes.

I also have to mention: I really like the demo "Logon's run - 3D meets the aging bits" by Overflow / Logon System. It was more than impressing when I saw it first, and it still is even if the mystery was revealed by the great Making Of. I think, this one brought me back to the CPC after decades of other stuff.