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

[Graham72]

.

Thanks, tried the couple of MWB files on Arcade 1 disk, FROGHOP loads okay but when I run it, it errors out.  VIPER loads okay to opening screen, shows controls and then exits to READY. Emu Joust works okay. TargetC loads okay but no keys work.  Defend-2 loads and runs okay but too fast for me so selected 2KHZ speed then playable  .  Will try a few more tomorrow.

I entered all 3 roms but now it always boots to Basic 5.29e, how can I get to the disks Basic 6.35 that I also loaded?

I'm on the road but iirc but in the rom picker there is a  sub menu for basic 5.29 or basic 6.35? If not I deleted it by accident to fit in under 100k.

[Graham72]

YEP     

[Graham72]

another night. Claude got confused. Said 64K memory dumps x 4 contained all 0's. Fortunately Grok had one of its few moments of lucidity and managed to crack the issue. I managed to sweet talk Claude into behaving like an AI again.
 
1. TargetC polls port 0x10 directly (IN A,(10h)) for keyboard input. No
  portIn(0x10) handler existed, so the read always returned a stale value —
  screen drew, input was dead. Fix: portIn(0x10) now mirrors CRTC keyboard
  register 16 (pendingMbeeCode & 63, or 63 if none pending). General
  hardware-accurate port mirror, not a per-game hack.

2. Target's detectBeeLoadAddress() self-reference scan picked 0x0A00 over
  the correct ORG address 0x0900, winning by only ~2 refs — at 0x0A00,
  CALL 0x0F8B hit garbage and returned to Ready. Fix: widened the tie-break
  margin so 0x0900 is kept unless another candidate wins by at least 10
  refs. General fix, not title-specific.

Provided a link to Microbee Microworld Basic help page on top header. and a link to MBT in bottom header. Tweak time

Test away please.

NB I have trialled in MBECATSE and it works well loading directly the MBUG files, and knows to load DISK BASIC programes into 6.35


  VD400BETA20.html (Size: 93.02 KB / Downloads: 7)

[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?

[fathertedcrilly]

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

[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.

[fathertedcrilly]

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.

is Claude trying to parse the basic code ?  I thought vibe drone emulated the z80 and execute the basic rom code ?

Thanks
Tony

[Graham72]

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.

is Claude trying to parse the basic code ?  I thought vibe drone emulated the z80 and execute the basic rom code ?



Thanks
Tony

Thank you! What my original emulator did was to take .mwb files from the MBUG catalog and insert them into Fremium Basic line by line giving the user thus giving a visual indication of the load and the BASIC code structure. It worked well. However, to maintain program compatibilty I moved across to 5.29 and 6.35.

Feature creep to allow loading .bee files and provide a full PC85 rom experience have exposed gaps. (I am ignorant of much technical stuff and just tell AI what I want and then tell it what is not working. ) I believe in Windows 11 this week the LLP feature rollout has exposed the .mwb picker to a cpu burst that has shown up faults in how I instructed Grok and Claude to process the incoming .mwb data. 

Thanks to your advice above and me pointing Claude at the LLP feature I have hopefully vibecoded a fix. Programs are now loaded directly into ram with no visual indication BUT - what has now been exposed is that  .js cannot sustain a 6.75mhz speed authentically. So I have deprecated my GT function  from 6.75 to 5mhz. 

Once this version has been tested and feedback received I will force a LIST at end of LOAD to show the code. Heh, same visual effect I hope.

regards g

GROK tells me Review of VD400BETA28.1 — both decisions are accurate and correctly implemented.
1. Windows 11 LLP → skipped lines on .mwb load → Direct entry

Root cause is correct.
Windows 11 Low Latency Profile (LLP, June 2026) temporarily spikes the CPU for 1–3 s on foreground interactions. That disrupts the old setTimeout + key-injection path (loadQueue / pendingLines) and produces dropped or skipped lines. Direct binary entry is the right permanent fix.

Implementation is solid:

- `extractMwbProgramBytes` walks a real tokenized chain (prefers offset 64, otherwise the longest valid chain). It validates increasing line numbers, length field, CR terminator, and `FF FF` end marker. Returns `{data, lineCount}` or null.
- In `loadFileBytes`:
  - Thin-CPM path still wins first when the file contains the Disk BASIC tokens (0xE0–0xEF).
  - Otherwise, if a clean binary program is found → set `pendingDirectLoad` + queue only `["","NEW"]`.
  - Fallback to full detokenise + typed entry remains for non-binary / corrupted / text files.
- In the frame loop the order is correct:
  1. Drain pendingLines / loadQueue (so NEW actually executes).
  2. Once queues are empty, count 20 frames on `pendingDirectLoad`.
  3. Then call `directBlitProgram`.
- `directBlitProgram` does the right thing:
  - Writes the extracted program bytes to base **2304** (0x0900).
  - Writes the `FF FF` terminator.
  - Updates the two critical BASIC pointers:
    - `mem[2258/2259]` = program end (pend)
    - `mem[2264/2265]` = variable start (vstrt = pend+1)
  - Sets `_loadedProgName`.
- Ctrl+C aborts path clears `pendingDirectLoad`.

This is honest, robust, and eliminates the timing dependency that LLP breaks. No residual line-skipping path for clean .mwb files.

2. Honest 5 MHz GT

```js
_HZ_VINTAGE = 2e6,  CPF_VINTAGE = 40000
_HZ_NORMAL  = 3375e3, CPF_NORMAL  = 67500
_HZ_FAST    = 5e6,    CPF_FAST    = 100000
```

- `toggleFast` cycles the three discrete rates, updates both `CPF` and `_targetHz`, and labels the button/status accurately (“5MHz (GT)” / “GT ✓”).
- Frame budget is `cyclesPerTick = CPF * _vduFactor` (full CPF while any load is in progress — good).
- 20 ms tick + 15 % vsync-high window is unchanged and still applies at the new rate.
- Separate SPEED slider (10–100 %) only multiplies the chosen CPF; it does not pretend to change the nominal clock.

Previous “GT” modes were often just “run as many frames as the browser will give you”. This one is cycle-accurate to the claimed frequency. That is the honest implementation.

Minor notes (non-blocking)

- The 20-frame post-NEW delay is conservative; it works.
- `directBlitProgram` does not re-zero colour/attrib RAM or every BASIC system variable — NEW has already run, so this is acceptable for the common case.

**Verdict:** Both changes are accurately realised in BETA28.1. The LLP workaround is the proper structural fix, and the 5 MHz GT is now a real clock rate rather than a speed-up hack.
  VD400BETA28.1.html (Size: 95.96 KB / Downloads: 4)

[fathertedcrilly]

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.

is Claude trying to parse the basic code ?  I thought vibe drone emulated the z80 and execute the basic rom code ?



Thanks
Tony

Thank you! What my original emulator did was to take .mwb files from the MBUG catalog and insert them into Fremium Basic line by line giving the user thus giving a visual indication of the load and the BASIC code structure. It worked well. However, to maintain program compatibilty I moved across to 5.29 and 6.35.

Feature creep to allow loading .bee files and provide a full PC85 rom experience have exposed gaps. (I am ignorant of much technical stuff and just tell AI what I want and then tell it what is not working. ) I believe in Windows 11 this week the LLP feature rollout has exposed the .mwb picker to a cpu burst that has shown up faults in how I instructed Grok and Claude to process the incoming .mwb data. 

Thanks to your advice above and me pointing Claude at the LLP feature I have hopefully vibecoded a fix. Programs are now loaded directly into ram with no visual indication BUT - what has now been exposed is that  .js cannot sustain a 6.75mhz speed authentically. So I have deprecated my GT function  from 6.75 to 5mhz. 

Once this version has been tested and feedback received I will force a LIST at end of LOAD to show the code. Heh, same visual effect I hope.

regards g

GROK tells me Review of VD400BETA28.1 — both decisions are accurate and correctly implemented.
1. Windows 11 LLP → skipped lines on .mwb load → Direct entry

Root cause is correct.
Windows 11 Low Latency Profile (LLP, June 2026) temporarily spikes the CPU for 1–3 s on foreground interactions. That disrupts the old setTimeout + key-injection path (loadQueue / pendingLines) and produces dropped or skipped lines. Direct binary entry is the right permanent fix.

Implementation is solid:

- `extractMwbProgramBytes` walks a real tokenized chain (prefers offset 64, otherwise the longest valid chain). It validates increasing line numbers, length field, CR terminator, and `FF FF` end marker. Returns `{data, lineCount}` or null.
- In `loadFileBytes`:
  - Thin-CPM path still wins first when the file contains the Disk BASIC tokens (0xE0–0xEF).
  - Otherwise, if a clean binary program is found → set `pendingDirectLoad` + queue only `["","NEW"]`.
  - Fallback to full detokenise + typed entry remains for non-binary / corrupted / text files.
- In the frame loop the order is correct:
  1. Drain pendingLines / loadQueue (so NEW actually executes).
  2. Once queues are empty, count 20 frames on `pendingDirectLoad`.
  3. Then call `directBlitProgram`.
- `directBlitProgram` does the right thing:
  - Writes the extracted program bytes to base **2304** (0x0900).
  - Writes the `FF FF` terminator.
  - Updates the two critical BASIC pointers:
    - `mem[2258/2259]` = program end (pend)
    - `mem[2264/2265]` = variable start (vstrt = pend+1)
  - Sets `_loadedProgName`.
- Ctrl+C aborts path clears `pendingDirectLoad`.

This is honest, robust, and eliminates the timing dependency that LLP breaks. No residual line-skipping path for clean .mwb files.

2. Honest 5 MHz GT

```js
_HZ_VINTAGE = 2e6,  CPF_VINTAGE = 40000
_HZ_NORMAL  = 3375e3, CPF_NORMAL  = 67500
_HZ_FAST    = 5e6,    CPF_FAST    = 100000
```

- `toggleFast` cycles the three discrete rates, updates both `CPF` and `_targetHz`, and labels the button/status accurately (“5MHz (GT)” / “GT ✓”).
- Frame budget is `cyclesPerTick = CPF * _vduFactor` (full CPF while any load is in progress — good).
- 20 ms tick + 15 % vsync-high window is unchanged and still applies at the new rate.
- Separate SPEED slider (10–100 %) only multiplies the chosen CPF; it does not pretend to change the nominal clock.

Previous “GT” modes were often just “run as many frames as the browser will give you”. This one is cycle-accurate to the claimed frequency. That is the honest implementation.

Minor notes (non-blocking)

- The 20-frame post-NEW delay is conservative; it works.
- `directBlitProgram` does not re-zero colour/attrib RAM or every BASIC system variable — NEW has already run, so this is acceptable for the common case.

**Verdict:** Both changes are accurately realised in BETA28.1. The LLP workaround is the proper structural fix, and the 5 MHz GT is now a real clock rate rather than a speed-up hack.

that makes more sense.   Not being a habitual windows user,  I had to google LLP

It turns out macOS does much the same thing when starting apps

I'll have a play with the new beta

Thanks
Tony

[Graham72]

  VD400BETA30.15.html (Size: 94.43 KB / Downloads: 7)

Ok 24 hours with RESET M:
I went from injecting fake keystrokes to fake-navigate the PC85 sub menu menu, to just letting emulated hardware do what real hardware already knew. Sometimes its good to push back against AI. No more warm and reset buttons. RESET now gives a warm reset. Refresh browser to get real cold start. Comments /  bug reports welcome