I was aware of the 132 col x 65 rows, it was the 4 * 65 = 260 part I was missing.JustBurn wrote:The controller actually is 132 columns by 65 rows.Tauwasser wrote:How do you come up with those numbers? 65 columns times 4 rows of 24 pixels or something?
According to SED1565 datasheet:
Page 31 shows the clocking signal of a frame, CL and FR can be seen there.
Page 73 shows a table with the clocking rate.
fCL = fOsc / 4
fFR = fCL / 260 (260 is 4 x 65)
That proves 18720 Hz will result in a frame rate of 72 Hz
Then maybe that's not the FR terminal after all? Until now I had thought that the ribbon cable is just some physical adapter. Maybe there's another controller on there to generate FR from CL? I find that somewhat unlikely though...JustBurn wrote:Like I've said, FR should be always toggled for the controller to properly drive the voltage into the LCD, it has nothing to do with any shading. (Look page 31 and up).
Well, they could have scaled that clock for certain internal parts. My point was, they didn't for the PRC.JustBurn wrote:The system does indeed runs at 4Mhz (250ns).
That's what I thought. However, I should surely see more than one frame being copied in that case? Maybe something else makes the PRC hang and therefore the CPU never gets out of the stall?JustBurn wrote:PRC will need to access the main BUS to get the data and read/write into the framebuffer. That means when PRC is being accessed the CPU will stall during the rendering and copy process. What you saw in your logic analyzer was the "copy" period.
The BIOS does some raw writes to the LCD (including clearing pixels) at startup before initializing (the PRC is still unconfigured at this point).
After all initialization if it detects that there's no cartridge, it will runs a "No cartridge" animation, this time it will use the PRC.
Using a cartridge won't actually change much or even anything.
I guess I'm going to try again, see if I can get it to work continuously or something.