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

[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