8bitkick / bbcmicrobot Goto Github PK

Owlet's JSbeeb instance has a breakpoint set at when the OS is first ready for keyboard input. This appears to be at cycle 581402. At this breakpoint the user program is then written to memory and executed.

In theory we should be able to adjust the breakpoint timing in client.js of BBCmicrobot (currently 725000) to match this identically. However this will require checking / regeneration of test frame checksums potentially.

(FYI @ojwb who noted some timing differences - these have been reduced from 500ms to ~50ms already but we can get it closer with suggested change above)

Eg https://twitter.com/bbcmicrobot/status/1274799303907737606?s=21

Suspect there’s a case sensitive regex or string comparison in there need to take a look

Currently we disable the GXR in Rocket mode (and the other long running modes) because apparently it makes things slow with beebjit. I tried it to see, but it seems to not affect the speed for me (here I patched in a different rocket emoji to run beebjit with the GXR loaded - compare the beebjit command lines in the log messages):

$ echo '🚀REP.P."POO";:U.0'|time node client try
[11/12/2020 13:57:33 ] [LOG]    Cli0: 
[11/12/2020 13:57:33 ] [LOG]    Cli0: Running try from @try
[11/12/2020 13:57:33 ] [LOG]    Cli0: 
 {
  emulator: 'beebjit',
  flags: '-cycles 25600000000 -frame-cycles 21600000000 -opt video:border-chars=0',
  compressed: false,
  input: 'REP.P."POO";:U.0',
  isBASIC: true,
  rude: false
}
[11/12/2020 13:57:33 ] [LOG]    Cli0: Loading OS from roms/master/mos3.20
[11/12/2020 13:57:51 ] [LOG]    Cli0: cd beebjit && ./beebjit -fast -headless -frames-dir ../tmp/ -cycles 25600000000 -frame-cycles 21600000000 -opt video:border-chars=0 -commands 'breakat 725000;c;loadmem ../tmp/tweet.bas 1900;loadmem ../tmp/keys.bin 03e0;writem 02e1 e4;writem 0000 11;writem 0001 19;writem 0002 11;writem 0003 19;writem 0012 11;writem 0013 19;c'
[11/12/2020 13:57:51 ] [LOG]    Cli0: beebjit DONE in 17.739s 
[11/12/2020 13:57:51 ] [LOG]    Cli0: Captured 1 frames (1 unique) ./tmp/beebjit_frame_
[11/12/2020 13:57:51 ] [LOG]    Cli0: Ffmpeg DONE in 0.169s 
[11/12/2020 13:57:51 ] [LOG]    Cli0: Generated image/png
18.10user 0.20system 0:18.35elapsed 99%CPU (0avgtext+0avgdata 64812maxresident)k
0inputs+2856outputs (1major+26212minor)pagefaults 0swaps
$ echo '🙯REP.P."POO";:U.0'|time node client try
[11/12/2020 14:08:34 ] [LOG]    Cli0: 
[11/12/2020 14:08:34 ] [LOG]    Cli0: Running try from @try
[11/12/2020 14:08:34 ] [LOG]    Cli0: 
 {
  emulator: 'beebjit',
  flags: '-rom 7 roms/gxr.rom -cycles 25600000000 -frame-cycles 21600000000 -opt video:border-chars=0',
  compressed: false,
  input: 'REP.P."POO";:U.0',
  isBASIC: true,
  rude: false
}
[11/12/2020 14:08:34 ] [LOG]    Cli0: Loading OS from roms/master/mos3.20
[11/12/2020 14:08:51 ] [LOG]    Cli0: cd beebjit && ./beebjit -fast -headless -frames-dir ../tmp/ -rom 7 roms/gxr.rom -cycles 25600000000 -frame-cycles 21600000000 -opt video:border-chars=0 -commands 'breakat 725000;c;loadmem ../tmp/tweet.bas 1c00;loadmem ../tmp/keys.bin 03e0;writem 02e1 e4;writem 0000 11;writem 0001 1c;writem 0002 11;writem 0003 1c;writem 0012 11;writem 0013 1c;c'
[11/12/2020 14:08:51 ] [LOG]    Cli0: beebjit DONE in 17.194s 
[11/12/2020 14:08:51 ] [LOG]    Cli0: Captured 1 frames (1 unique) ./tmp/beebjit_frame_
[11/12/2020 14:08:51 ] [LOG]    Cli0: Ffmpeg DONE in 0.215s 
[11/12/2020 14:08:51 ] [LOG]    Cli0: Generated image/png
17.71user 0.12system 0:17.82elapsed 100%CPU (0avgtext+0avgdata 67300maxresident)k
0inputs+2840outputs (1major+25819minor)pagefaults 0swaps

Perhaps this got resolved in beebjit? Or does it only affect certain cases?

As noted by @ojwb and described here
https://twitter.com/bbcmicrobot/status/1307147917065506816?s=20

The MODE7 interlace colour blending trick gives a very flickery video now:

0A%=19:B=&3C00:C=1205449:D=1459417:E=H.:F.S=1TO7:G=32:F.Y=0TO2:!E=&1D00OR7A.C:!B=&1D00OR7A.D:E=E+40:B=B+40:N.:C=C/8:D=D/8:N.:F.L=2TO3:$E=CHR$L+"MODE 7 rainbow using interlaced colours":E=B:N.:!-512=&B3402
1V.23;12,G;0;0;USR-12:G=72-G:G.1

If I revert to jsbeeb locally the bot produces a static image (which is what it produced before). I don't have real hardware to hand to test on, but I'd expect that it would look like the static image (but slightly blurrier, so the colour blending would if anything actually be more effective).

I suspect this is due to when the screen gets snapshotted no longer being directly linked to vsync.

Currently the bot loads DFS, which seems entirely useless but raises PAGE by 2816 bytes. Even in the best case of MODE7 and rocket mode, that's a 10% reduction in the available RAM to BBC BASIC. In MODE2 and with the GXR loaded it's a whopping 35% reduction.

I've butted up against this restriction and been annoyed by it multiple times, but I didn't propose changing it before as doing so would break programs which assume the value of PAGE (and while you really shouldn't assume the value of PAGE in general, in the context of squeezing the most out of every byte of code for the bot it's often handy to do so).

However the move to mastodon gives us a good opportunity to reconsider this - it seems more reasonable that existing programs from the bot may not work unmodified in this brave new world.

If there are some genuine uses for having DFS loaded (or if we just want to provide a simple way to run old programs which assume PAGE without reworking them), we could support a floppy disk emoji to reenable it.

Happy to provide a patch, though that really requires git to be up to date.

I've pushed changes to the mastodon branch and the testsuite now passes again for me locally.

However it fails in CI like so:

Run npm ci
  npm ci
  shell: /usr/bin/bash -e {0}
npm ERR! Error while executing:
npm ERR! /usr/bin/git ls-remote -h -t ssh://[email protected]/mattgodbolt/jsbeeb.git
npm ERR! 
npm ERR! [email protected]: Permission denied (publickey).
npm ERR! fatal: Could not read from remote repository.
npm ERR! 
npm ERR! Please make sure you have the correct access rights
npm ERR! and the repository exists.
npm ERR! 
npm ERR! exited with error code: 128

However package.json says:

package.json:    "jsbeeb": "https://github.com/mattgodbolt/jsbeeb.git#78eeeb3299c4640ca709df189c76d7447977258f",

It seems npm thinks it's so smart and knows better than us, so it rewrites that to an ssh URL, which then doesn't work. I've read the help but can't work out how to stop it doing this.

Any idea how to fix this? It's frustrating to be so close to having this working once more.

Perhaps we should just rewrite the bot in BBC BASIC so it can be self hosting...

There are some very long-running programs being written and I'd like to start them then get on with other stuff that I am doing. However, I've noticed that when the browser's tab loses focus (switching to another or away from the browser itself), the emulator pauses.

Now, I am not sure if this is just the browser doing this. But if it is the emulator, would it be possible to remove that constraint?

Thanks.

@ojwb take a look at this in particular the second half on minification tricks. The me know if you spot any inaccuracies / omissions. It's a write up of some of your stuff in fact!

https://github.com/8bitkick/BBCMicroBot/blob/master/docs/user%20guide.md

@8bitkick mentioned this on mastodon - creating an issue for it so we can track progress better

https://docs.joinmastodon.org/spec/microformats/ has the specs

The bot code in the repo will generate a PNG if all captured frames are the same, and the tests seem to show that works.

However, the live bot doesn't seem to do this. For example, this is a static image but produced a video:

https://twitter.com/Kweepa/status/1272280506114211841

However if I copy that code into a new test then I do get a PNG!

Is the live code different to the code in this repo?

Looking here

Before reading below check this awesome [interactive BBC BASIC tutorial](https://www.bbcmicrobot.com/learn/index.html) first if you aren’t familiar or want a refresher. The guide below is more about using the bot and how to minify code rather than covering the BBC BASIC language.

This links to https://www.bbcmicrobot.com/learn/index.html (source unknown)
That page links to the Twitter edition of the bot... and that's the real thing I came here to try to help fix...! Let's get that to point at https://mastodon.me.uk/@bbcmicrobot

😄