(obviously the infinite waitstates case means the CPU gets no bandwidth at all, but I fear the other cases may not be cycle-accurate with the current approach?)
The "waitstate count" idea smells to me. This seems like a VRAM bandwidth issue, so if the CPU has to "slot in" between display controller accesses (which would naturally take priority) then I would expect wait states to be *variable* depending on when CPU accesses land? @endrift
-
-
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
I was thinking this too, a waitstate count seems exceptionally unlikely for hardware, a memory arbiter that can halt the CPU on simultaneous access seems most likely.
-
Waitstate count only makes sense to me if there is a hardware line buffer, so the display controller renders faster, and they actually have the CPU take priority. Then they could precompute consistent wait states such that they guarantee display is on time. Seems convoluted tho.
- Show replies
New conversation -
-
-
It's definitely not waitstates. I started doing some preliminary research into how/when it stalls in other modes and...well, I need to do a lot more work. The 2-layer mode 2 thing clearly starves the CPU though, which was easy enough to implement and fixed the bug.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.