Engineer’s Log, Labdate 0726.15. We are traveling at warp 4.5 now. Scott and Spock are still trying to reach warp 5.
Found the missing pixels. They have been buried under some missing NOP instructions. Hmm, ok, it’s nearly impossible to bury anything under something that is missing but I managed it somehow. 😉
Now HRE has full resolution of 640 x 250 = 160,000 pixels!
A simple interface should read commands from the CBM userport. How do we implement this feature? It depends on the time between successive commands and on the transmission time for a single command. I’ll write a small transmit loop in BASIC and measure the execution time. A datassette has the honorable duty of being responsible for a save and reliable storage.
I don’t care about command structure at this stage. All I want to measure is the time for the fastest possible change of signal levels at the userport (BASIC only). Will the execution speed change if we put two BASIC statements in a single line?
1000 POKE 59459,255
1010 POKE 59471,255:POKE 59471,0
1020 POKE 59471,255
1030 POKE 59471,0
1040 GOTO 1010
Wow! 7.281 milliseconds! What a blazing speed! That equates to a bandwidth of more than 137.343 bytes/s! Eat your heart out Nvidia!
Putting two statements in a single line doesn’t make any difference.
Ok, let’s assume the 6502 is going to train for CPU olympics. Hence, further calculation will be based on a value of 5 ms to be on the safe side. If we sample the userport at each HSYNC interrupt we get more than 80 samples per level change. That’s more than adequate. Currently there are about 170 free cycles at the beginning of the HSYNC ISR so I intend to handle the userport communication there. It’ll be somewhat challenging because the HSNC ISR must be cycle exact. So what? May I remind you that this is a retroCHALLENGE entry?
Now we should think the protocol through. The absolute minimum number of bytes per command (without considering compression) will be four:
1 byte for instruction (e.g. 1 = SetPixel, 2 = MoveCursor, 3 = DrawLine, …)
2 bytes for X coordinate
1 byte for Y coordinate
Unfortunately the HRE wouldn’t be able to identify the single bytes. For example the command SetPixel(256,1) will translate to $01 $01 $01 $01. Not a single bit does change during the whole data transfer! How do we separate the bytes?
We’ll use only 5 bits of a byte for data and 3 bits for synchronisation. That adds some complexity to the protocol which reduces bandwith even more but we can strive for speed in an upcoming Retrochallenge. 😉
The following table of the three most significant bits shows the unique coding of each byte:
000 => command
001 => X-coordinate low
010 => X-coordinate high
011 => Y-coordinate low
100 => Y-ccordinate high
101 => future expansion
110 => future expansion
111 => future expansion
So we have to transmit a total of five bytes per command.
Looking forward to my first non trivial BASIC program since the 80th. 🙂