On 22/06/2019 20:21, paulhar...@btinternet.com wrote: > My suspicion is that it is memory trampling in the font caching > implementation in the emulated VCB02 device in SimH. The VCB02 device > uses the same memory planes for font caches as for screen bitmaps - > the manual says: > 1.6.1.1 Font Storage and Access Fonts are stored in an undisplayed portion of > the bitmap. Ordinarily, a font is stored only in one plane and is transmitted > from that plane to itself and > others when a character is written. .... Fonts are normally stored in the > off-screen portion of the VCB02 bitmap. > > Calling Matt Burke - can you spot anything odd in your implementation of this > aspect of the VCB02? > When I released the VCB02 I mentioned that there were known problems with VWS and UWS. Although DECwindows appeared OK with my testing it's not surprising that it's also affected. I hope to fix this eventually but it might not happen for a while as experience tells me it will take many hours to track this one down.
Basically you have to enable debugging so that every drawing operating is logged then wait for the screen to get corrupted. You then need to count the exact pixel offset and size of the corrupted area. Next the debug log file (which is likely several gigabytes by this point) is searched to try and find the exact drawing operation that caused the corruption. Then the manual needs to be consulted to find out what subtle functionality was missed from the implementation. A change is made, which usually breaks something else and the cycle continues :) Matt _______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
