yeah I threw it on cloudt to try it :) Greg
On Tue, Mar 6, 2018 at 7:31 PM, Kevin Becker <[email protected]> wrote: > Was that on actual hardware? I tried to tune it so that I could wail on > the keys as fast as I could and didn't get off the black bar on both my > real M102 and VirtualT set explicitly to 2.4Mhz. Maybe it needs more > tweaking though, lol. > > > > On Tue, Mar 6, 2018 at 9:35 PM, Gregory McGill <[email protected]> > wrote: > >> cool.. i jumped around to the other side! :) >> >> Greg >> >> >> On Tue, Mar 6, 2018 at 5:18 PM, John R. Hogerhuis <[email protected]> >> wrote: >> >>> >>> On Tue, Mar 6, 2018 at 3:43 PM Ken Pettit <[email protected]> wrote: >>> >>>> >>>> On 3/6/18 2:19 PM, John R. Hogerhuis wrote: >>>> > >>>> > Ah. Well, CloudT dynamically inserts delays to simulate the Model T >>>> > processor speed. If you look at the number at the bottom of the screen >>>> > it should over around 2.4Mhz. But being written in Javascript and >>>> > running off timer event callbacks, I can't get cycle accuracy. >>>> > >>>> >>>> Ahh, that's how you are emulating the 2.4MHz speed. I was wondering. >>>> What do you use to determine the number of cycles to dynamically delay? >>>> >>> >>> >>> Well it’s basically on cpu cycles per instruction. There are definitely >>> some inaccuracies beyond just the JavaScript event driven model (I don’t >>> get to be the only code on my thread or get a guaranteed time slice). But >>> it ought to be close enough. >>> >>> The JUMP game seems to work off how fast inkey$ runs. I am guessing the >>> issue is that CloudT does some queueing beyond what the model t provides >>> due to some very fancy keyboard stuff going on in mobile browsers >>> (predictive text and such). So keys batch up and allow the man run faster >>> than he should. >>> >>> — John. >>> >> >> >
