Easy way to get a BASIC program from a text file into an emulator

[Diminished]

Is there a simple way to do this? It seems astonishingly difficult.

I'm working on a BASIC program in a text file under Linux, and I would like a way to be able to just splat it into an emulator, preferably B-em 2.2, as that's what I'm using.

I've tried CTRL-Ving it into BeebEm, B-em, and jsbeeb. No dice. My admittedly very half-hearted attempt to make B-em "connect" its RS423 input to a file on the local filesystem and read the thing in using *FX 2,1 hasn't borne any fruit, and I don't seem to be able to find any Linux utilities that will let me do something nice like drop the file into a disc or tape image, load the image in the emulator and *EXEC it.

Any ideas?

TIA

[richardtoohey]

find any Linux utilities that will let me do something nice like drop the file into a disc or tape image, load the image in the emulator and *EXEC it

Maybe not "easy", but you can use Stephen's MMB Utils to do the copy-file-to-SSD part:

https://sweh.spuddy.org/Beeb/mmb_utils.html

[Diminished]

Ah, that looks like what I wanted. Thanks.

[tricky]

Easiest way is to use beebem on Windows and copy the text to the clipboard, then use the paste option.
You can also use beebasm (see retrosoftware) to convert a BASIC program from text to an .ssd image - PUTBASIC.

[Diminished]

Ah, this looks good too, thanks.

[Diminished]

Coding like it's 1984 now guys, thanks a lot! Didn't even have to look up how to redefine a function key to do the *EXEC part. Amazing how that knowledge is still in my brain, somehow.

[Coeus]

I've tried CTRL-Ving it into BeebEm, B-em, and jsbeeb. No dice. My admittedly very half-hearted attempt to make B-em "connect" its RS423 input to a file on the local filesystem and read the thing in using *FX 2,1 hasn't borne any fruit...

The GitHub version of B-Em has VDFS which allows you to use a subset of the filesystem on the host you're running the emulator on as a proper Acorn filing system. The easiest way is to set the environment variable BEM_VDFS_ROOT before starting B-Em to point to a directory on Linux (or Windows) which will become the root as viewed from within the BBC, Choose "Enable VDFS" from the Disc menu and then you can select this filing system with S-Break or *VDFS. Everything under that directory is now accessible in the Acorn hierarchical filing system way, i.e. '$' for root, .'. for directory separator etc. a bit like NFS or ADFS (without raising PAGE like ADFS does).

For an occasional one-off I don't think this can complete with the convenience of BeebEm's clipboard paste but was much easier to implement portably.

[Matt Godbolt]

Bit late to the party but jsbeeb (sorta) supports editing in github and loading from there:

* Create a gist with your code. https://gist.github.com/ e.g. https://gist.github.com/mattgodbolt/fc8 ... 13719c8341
* Get the "Raw" link by clicking "raw" and copying the URL . In the case above that's: https://gist.githubusercontent.com/matt ... 5c/foo.bas
* Add that after "https://bbc.godbolt.org/?autorun&loadBasic=" or similar, e.g. https://bbc.godbolt.org/?autorun&loadBa ... 5c/foo.bas

Hooray! Note that every update you make means you need to make a new raw link. Not ideal, but hey, it (mostly) works

[leenew]

Is there a simple way to do this? It seems astonishingly difficult.


I've tried CTRL-Ving it into BeebEm, B-em, and jsbeeb. No dice.
Any ideas?

TIA

You almost had it with the CTRL-V.
Copy the text but instead of CTRL-V into BeebEm, use the EDIT/PASTE option from the menu.
This was mentioned above but you may have missed it.
Hope this helps.

Lee.

[Diminished]

For an occasional one-off I don't think this can complete with the convenience of BeebEm's clipboard paste but was much easier to implement portably.

This does sound like the right solution. I've seen the thread on the improvements to B-Em since 2.2 and it looks like lots of excellent new things have gone into it, but I had an issue last time I tried to built the git version (IIRC, configure detects JACK not installed, but make fails with a missing JACK header file anyway. Admittedly, I could probably fix this in a few seconds just by installing JACK).

Bit late to the party but jsbeeb (sorta) supports editing in github and loading from there:

* Create a gist with your code. https://gist.github.com/ e.g. https://gist.github.com/mattgodbolt/fc8 ... 13719c8341
* Get the "Raw" link by clicking "raw" and copying the URL . In the case above that's: https://gist.githubusercontent.com/matt ... 5c/foo.bas
* Add that after "https://bbc.godbolt.org/?autorun&loadBasic=" or similar, e.g. https://bbc.godbolt.org/?autorun&loadBa ... 5c/foo.bas

Hooray! Note that every update you make means you need to make a new raw link. Not ideal, but hey, it (mostly) works :D

This is neat ... there isn't a similarly undocumented feature for enabling write access to an SSD uploaded by the user, is there? Just asking. :P

You almost had it with the CTRL-V.
Copy the text but instead of CTRL-V into BeebEm, use the EDIT/PASTE option from the menu.
This was mentioned above but you may have missed it.
Hope this helps.

Lee.

Thanks. I dare say this works on Windows, but the Linux version of BeebEm I have is an oldie (the 0.0.13 version based on the BeebEm 3.5 Windows codebase), and I don't think this is supported.

[Matt Godbolt]

This is neat ... there isn't a similarly undocumented feature for enabling write access to an SSD uploaded by the user, is there? Just asking.

Kind-of, yes. There's limited Google Drive support and you can copy files to Google Drive and then use them as writable SSDs. But that's nasty...I need to work on "writable, but thrown-away discs" support. I think? What would you like it to do?

[Matt Godbolt]

(see also https://github.com/mattgodbolt/jsbeeb/issues/112 )

[Diminished]

What would you like it to do?

"writable, but thrown-away discs" support

^^ Exactly this. Essentially using the uploaded disc as temporary storage for the duration of the session. There is no requirement to keep the disc's contents around once a game has been completed.

As I mentioned in my release notes, this problem would be better solved on my side by using in-memory patching rather than on-disc patching. Then it would work in any situation (including using write-protected discs on the original hardware), but it would require me to dissect the game's loader. One advantage of the current method is that it ought to make the randomiser compatible with all existing cheat loaders, but anyway.

[lurkio]

I need to work on "writable, but thrown-away discs" support. I think?

Yes, that would also help with the games in the "Games that don't work because they need write-access to the game disc" section in this bug report:

• https://github.com/mattgodbolt/jsbeeb/issues/140

It's at the top of my wishlist of new JSBeeb features!



What would be ideal is a URL param (a switch) that would make any disc-image that's loaded into JSBeeb writable for the duration of the browser session. There'd be no need to write to the original disc-image file -- only the copy of the disc-image in the browser cache would need to be writable. E.g.:

Code: Select all

http://bbcmicro.co.uk/jsbeeb/play.php?autoboot&disc=http://bbcmicro.co.uk/gameimg/discs/nnn/Game.ssd&writable

You'd need a separate writability param for drive 2 as well, for games that need two .SSDs in two separate drives, both writable (or only drive 2 writable).

[sweh]

find any Linux utilities that will let me do something nice like drop the file into a disc or tape image, load the image in the emulator and *EXEC it

Maybe not "easy", but you can use Stephen's MMB Utils to do the copy-file-to-SSD part:

https://sweh.spuddy.org/Beeb/mmb_utils.html

Indeed, and it becomes quite easy to script
eg

Code: Select all

% cat ./build
#!/bin/sh
IMAGE=mydisk.ssd
rm -f $IMAGE
tr '\012' '\015' < srcfile > dstfile
beeb blank_ssd $IMAGE
beeb putfile $IMAGE dstfile

The "tr" command converts from Linux line-end character (0x0A) to Beeb line-end (0x0D). So now you can just do "./build" and a new SSD image is built from the source.

[Coeus]

This does sound like the right solution. I've seen the thread on the improvements to B-Em since 2.2 and it looks like lots of excellent new things have gone into it, but I had an issue last time I tried to built the git version (IIRC, configure detects JACK not installed, but make fails with a missing JACK header file anyway. Admittedly, I could probably fix this in a few seconds just by installing JACK).

Someone else also reported that and since then I have made a change aimed at fixing that. It's to do with the M4000/M2000 emulation where it will offer the option to use JACK if it is there but it can also do ALSA both ALSA SEQ and ALSA raw MIDI. Of course, if you don't have those either then it won't do MIDI at all and those emulations won't do anything useful but is should still compile and failure to do so is a bug

Other branches may be experimental but if at any time master fails to compile it's worth raising an issue on GitHub or you can mention in here.