Why did the COMX-35 video memory seem unreliable?

Question

In my early days, many many years ago, one of the machines I managed to get my hands on was the COMX-35, a funky little machine based on the 1802 CPU.

I remember trying to develop some games for it and, as part of that process, I attempted to use 1802 assembler code to write directly to the screen rather than relying on the interpreted BASIC. From memory, the video RAM was supposed to be located at a fixed address.

However, try as I might, I could not get characters to reliably show up on the screen by simply injecting them into those memory locations. There was some success but it seemed to be very intermittent.

I ended up writing the program (Four In A Row) in BASIC and it was rather slow, particularly the animation of the tiles falling into the board (good enough to keep my mother amused however).

I was wondering if anyone knew why my attempts were spurious at best.

---

Addendum:

Regarding the possibility of the hardware scrolling, I'm not sure that was the case. From memory, running my program immediately after boot/load-from-tape, when no scrolling had taken place, was problematic.

And, once running, it was still intermittent - I wouldn't have thought scrolling would take place if my code was just poking memory and not using any regular things like print statements. Still, I haven't seen the ROM so can't discount this totally.

Answer 1

According to the COMX-35 Wikipedia entry (my emphasis):

The VIS [Video Interface System] ran on 5.626 MHz for a PAL and 5.67 MHz for an NTSC machine. This frequency was divided by 2 and output via CPUCLK (pin 38) to the CDP 1802 for timing of the CPU (2.813 and 2.835 MHz).

The VIS was also responsible for the timing of the interrupt (50/60 Hz) and timing of the non display period via PREDISPLAY (pin 1).

Video memory could only be accessed during the non display period which allowed for execution of 2160 machine cycles on a PAL and 1574 on an NTSC machine. Provided that not more instructions were executed than the indicated maximum number of machine cycles video memory could be accessed during the interrupt routine.

Alternatively the program could be paused by waiting for a non display period by checking EF1.

This is confirmed in the COMX35 Technical Reference Manual in the section dealing with display memory F800 - FFFF:

This area is write-only and can only be
accessed during the non-display period.
The program may wait for the non-display
period and directly write to this area, eg:

B1   $    ; check EF1, await non-display
STR  R7   ; write to the area.

So that seems to account for the unreliability. It's not enough to just poke values into that memory whenever you want. The non-display period only forms a portion of the actual time (about 1/3 according to this site but I'm not sure this is a real problem, see below) so you had to use the method shown to ensure the bytes were written successfully.

The write-only nature probably also complicates things as you can't check to see if the value you wrote is there.

---

That same technical reference manual shows an interesting approach to screen updates:

In COMX 35, the display output routine does not access the screen memory directly. Instead, the output characters are buffered in a FIFO memory. Interrupts are generated by the PREDISPLAY' signal (50/60Hz). The interrupt routine will flush the output characters in the FIFO memory into the page memory at the appropriate screen location.

So, instead of every individual character output waiting around until EF1 says it can be written (which could slow things down considerably), multiple characters are buffered without delays, and written as a unit in the interrupt routine called when PREDISPLAY' activates.

Answer 2

The wikipedia article says that the video interface system consists of CDP1869/CDP1870. The data sheet of the CD1869 states on p.377 that the "Out 7" instruction could be used for scroll operations:

The instruction uses 9 data bits to load the home-address register bits [...] The home-address register outputs are transferred to the refresh-address counter at the end of each display frame.

So as Greg Hewgill remarked in the comment, the most likely reason you were not able to "reliably" inject them into memory locations was because you didn't take scrolling into account, and the "intermittent" success occurred when the scroll origin was reset.