iss wrote: ↑
Tue Oct 15, 2019 9:45 pm
The program pokes 28 (60 Hz HIRES display) in every cell in range #BF40-#BF67 and waits 500ms after each to allow ULA to "interpret" the attribute - the result is vertical frequency remains at 50Hz.
Good, puzzled as to why, but good
: Does ULA really read memory during 40-63 ? If so, the internal address "pointer" must be NOT incremented during 40-63, because every next line starts exactly after 40 bytes of the previous line.
You misunderstand what's happening in the ULA -- you are right that the "next line" starts directly after in memory.
But: There is no "internal address pointer", the address is created from the H and V counters (multiplication and adding #A000) -- Note: speculation sent to me in the past that there is a separate memory counter and a H/V counter working separately as the only sensible design were proved to be 100% wrong.
So, on the first scan line of Oric's screen, with the horizontal count running 0-39, 40 bytes are looked up and used to make picture.
The next 24 microseconds/counts/columns are all done with the ULA's output forcibly blanked to black. ULA continues to read bytes 40 through 63, yes that's next line, and it even acts on them. Don't panic. In this period of time, we are producing the black right border, sync signal, black LEFT border and then when the vertical counter increments to the next scanline, the horizontal overflows from 63 to 0, and we start reading bytes 41 through 80, this time for real, with video output enabled.
If video wasn't forced to black, you'd see the edge of the screen at the left/right filled with repeats of stuff from onscreen.
It's a consquence of doing #A000 + X + (Y*40) with X ranging 0-63 -- there is over-reading/double-reading of memory.
Although this is provable as a "hardware thing" by staring at the electronics inside, it's borne out by the maths that the electronics is doing, and from simulation of the circuit.