' BEE BASIC emulation in the browser(local)/on the desktop

[Graham72]

Some games are running way too fast. Ive incorporated a for x=1to300 loop in Asteroids. Froghop is way too fast. I cant edit each game. So am testing a slider. Funny : for 48 years I wanted computers to go faster, now I am chasing the slowdown.

I dont quite understand why 2mhz is not 2mhz when games are involved. I get that on real hardware the 6545 steals cycles, and I thought VDU tick mimicked that, but obviously not. I spent way too many hours getting emujoust working but it depends on the emulator adjusting for ej. I need one solution fits all. Any suggestions?

The basics of a "real-time" run loop is as follows :

1. work out how many clock cycles ( or t-states ) should execute per second  ( i.e 2 million for 2mhz )
   
2. then decide how often the emulator will pause to take a snapshot of state ( registers, memory, screen etc ).   typically this can be 50 times a second to align with screen refresh.  typically known as the frame rate
   
3. divide the clock cycles per second by the frame rate to get tstates per frame
   
4. count the tstates executed per instruction and when you get to the tstates per frame value,  emit a snapshot and then pause the emulator if you are ahead
   
5. rinse and repeat
   

this ensure no matter how fast your cpu is,   you will always execute at the desired clock speed and delays will be consistent

counting loops aren't sufficient as they don't align to elapsed "wall time"

At the moment,  Novato uses a base clock of 3.375mhz.  It will execute a 10 second delay for 10 seconds of "real time" ( using 1x speed multiplier ) and the same delay for 1.25 of "real time" using the 8x multiplier.

Thanks
Tony

Thanks Tony, I've created another problem with not being able to load froghop properly. Clause has tracred to it to  5 failing lines dense in bracket/digit "graphics repeat" syntax 

Code:

[A1 142][A3 140]

etc.) with very few actual BASIC keywords relative to their length. Each non-keyword character position may trigger a full sweep through BASIC's ~95-entry keyword table before giving up and treating it as literal text resulting in following lines such as line 2260 RETURN being entered as line 60 RETURN etc.  I'm thinking of just having the emulator load the .mwb file directly into memory rather than the visual line by line input. Two issues to resolve. I'll try to resolve the line entry issue first then the speed problem. So it goes.