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 <arcadeshop...@gmail.com>
wrote:

> cool.. i jumped around to the other side! :)
>
> Greg
>
>
> On Tue, Mar 6, 2018 at 5:18 PM, John R. Hogerhuis <jho...@pobox.com>
> wrote:
>
>>
>> On Tue, Mar 6, 2018 at 3:43 PM Ken Pettit <petti...@gmail.com> 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.
>>
>
>

Reply via email to