p7simES and Type 340 woes

[Bill E]

Well, things were going too well. p7simES can't keep up with the 340 using correctly simulated times. Drawing a lot of long vectors causes it to massively drop points. The web js version handles it just fine.

The 340 can really push the bits out, 1.5 usec per point in a vector, and for full width vectors, that's 1024 points each. My load test draws 10, 1024 point vectors in a loop. This is all done in a 340 instruction set which blasts out all 10,024 points in a pretty continuous 1.5 usec per stream, only a 35 usec break between them (move to next vector line).

I can avoid the problem by drastically throttling the 340, but that's not even close to realistic. Sigh.

Digging into p7sim is not a rabbit-hole I want to go down, it's quite complex and chews up a lot of time doing something in that complexity. I increased a buffer size, didn't really help.

I've tuned the pidp-1 side in the display manager with its buffers to get the best success I could.

So, for now, the 340 will run as it is supposed to, just don't draw too many long vectors without a break.

Bill

[Bill E]

I guess I shouldn't be that concerned. I've tweaked p7simES, (yes, went down the rabbit hole, but only part way) its cpu loading has gone from ~280% to ~165% running flat-out.

End-to-end maxes out at about 650,000 displayed points per second. I guess that really should be enough. It's what a real 340 could manage. However, it would have drawn all the vectors in my stress test, it would have just taken 2 seconds instead of just losing a bunch of points.

This also verifies my timing in the 340 emulator I haven't checked anything in yet, I will soon. It would be nice if some other daring person would wade into p7sim and try to optimize it more. It uses 3, million item arrays, must be some better way. Finally, I always have to fear it's something in my emulator or low-level display code, but I'm not seeing anything.

Bill