#6 V1.7 slow, compared to 1.6
It seems like screen output on v1.7 is extremely slow, compared to version 1.6. Booting the emulator takes a long time, ijnstead of the <2 seconds 1.6 takes, and doing anything that draws to the whole screen.... you can watch the screen update line by line, very slowly. (Like it takes 5 seconds to scroll by one line.)
I just ran some benchmarks, and 1.6 is very close to a real 102's speed, taking 286 seconds on the real computer and 281 seconds on the emulator to run my prime number test.
The 1.7 emulator takes 290 seconds to run the test... if I disable scrolling by printing @0 every time I write to the screen. When I allow scrolling, the screen takes 3.8 seconds to update every time it scrolls by one line. By comparison, the real computer (and v1.6) takes less than one second to scroll a screen full of text.
Something happened in 1.7 that makes screen updates extremely slow and completely out of line with the real computer.
I've converted the repo to git... if you could bisect from 1.6 (82a9ab) to 1.7 (bc298f) and figure out where the time difference occurs, it should be fairly simple to fix. There's a history of large combined commits in this repo, so it's hard to figure out exactly which commit corresponds to the change.
Sure. i have not been able to build the project yet - I am still messing with getting the missing library components in the right place. I am hoping to get a chance to play with it this weekend.
Hey Guys,
I know where the problem is. A few years back when I was working on AsciiPixels, I had noticed that my code would work fine in VirtualT, but would not update the display on a real M100 / 102 correctly. The issue was in the response times of the LCD driver chips. So in V1.7, I tried to add emulation of the driver chip delays. I think this delay is a bit too much, and that is what is causing the slow response you are seing.
Ken
The issue is in io.c on line 1272. The code is checking the hirestimer to see if enough time has passed prior to reporting the LCD controller as ready after an access. Commenting out lines 1268 - 1274 causes the emulation to add zero delay, but I found this is actually faster than the real hardware, and code that runs in VT may not actually run on a real machine.
A better approach would probably be to profile the time a little better than I did in 2015 and change the the line:
if (lcdTime[c]+.000014 > hirestimer())
To a smaller delay value, like .000005 or something.
Ken
Thanks. I still can't get the code to link - fltkz.lib is missing. I'm wondering if I have the wrong fltk version.
** Edit: never mind. Figured it out. It requires FTLTK 1.1.
Last edit: Tom Wilson 2020-03-14
@kpettit1 This works
I wrapped the affected lines in an #if block, and the performance looks much like my T102.
Thank you!
Updated source file