yeah I threw it on cloudt to try it :)

Greg

On Tue, Mar 6, 2018 at 7:31 PM, Kevin Becker <ke...@kevinbecker.org> 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 <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