TWIN editor? BBC BASIC 1.0?

TWIN editor : Did this editor survive till the RISC OS days, or was it dropped prior to RISC OS 2?

Either way, setting the filetype to Absolute and double clicking it, actually starts it, and you can actually edit stuff with it :)

On a Raspberry Pi 4, and using the version from the ARM evaluation system.

ARM BBC BASIC also starts up, but crashes due to a BICHIS PC,R14,#(clear carry) instruction (it still manages to get back to the >prompt each time, and *Desktop works to get back to the RISC OS 5 desktop, which remains intact despite having run ARM BBC BASIC 1.0 just prior

Edit : typing a ‘clear carry then MOV PC,X14’ in Zap on the end of BBC BASIC 1.0, and replacing BICHIS with BHI to that, gets it working a bit more – PRINT 5 works, PRINT, CLS, HELP . :)

MANDEL doesn’t work, though. Is there any source code for MANDEL anywhere? :D

I believe David Pilling was a major user of Twin.

Various “modern era” hacks to the code exist to get it working on RISC OS 5:

• https://www.croftnuisk.co.uk/coltsoft-downloads/other/Twin.zip

• https://heyrick.eu/random/twinhack.zip (mine is big because it comes with a PDF user guide made from scans, and sources)

The TWIN & TWINO commands were removed from BASIC v1.54 in 2013.

tymaja asked

Is there any source code for MANDEL

I added it to nemoBasic in 2022:

It’s an optimised rewrite of the code in the AB interpreter from the ARM Evaluation CoPro. i.e. it goes faster, but it’s still the same (frankly odd) syntax.

Its token was reused for WAIT, so in addition to adding a new token for MANDEL (C8,A5) I made WAIT polymorphic so existing 1986 era demos still work!

It produces this kind of output, not terribly quickly:

@Rick : I will definitely check these out soon! (I didn’t know there were versions available; I don’t know what TWIN even looks like when running, so look forward to finding out!). !Zap is my main editor for RISC OS though (and for pretty much any system – I regularly dump stuff onto a USB flash drive from Linux or Mac so I can actually look at it ‘properly’)

@nemo : nice! I bet it runs a lot faster than my current, deliberately unoptimised BASIC Mandelbrot software! I had a quick look at the ARM Evaluation system BASIC when I first posted above; ‘MANDEL’ seemed to ‘clash’ with some other keyword (presumably WAIT, but can’t remember), so I couldn’t find where the code was. However – I have since realised that I was looking in the wrong place, probably (because BASIC uses two different versions of each keyword, like ‘a%=TIME’ versus ‘TIME=0’ :)

tymaja suggested:

BASIC uses two different versions of each keyword

Only in six cases – a small number of psuedovariables, originally to make tokenisation easier on the Beeb:

PTR
PAGE
TIME
LOMEM
HIMEM

The statement tokens are 64 greater than the function tokens for those. Note that despite PTR getting two tokens, EXT only gets one even though it is syntactically identical. Blame the “hysterical raisins”.

There’s also two ELSEs so it can tell the difference between single-line and multi-line contexts (you can use the single-line ELSE in a line even if you haven’t used IF – it just means “skip the rest of this line”. But ELSE as the first statement of a line gets a different token, as that’s part of a multi-line IF...THEN structure, and means “skip to the matching ENDIF”.

Martin chided:

TWIN & TWINO commands were removed from BASIC v1.54 in 2013

But have not been elsewhere cos Twin works. And as Alias$Twin can be defined anywhere, there’s no good reason to remove it. Never is.

Mind you, thanks to my custom OS_ReadLine I can EDIT 100 to edit an existing line immediately – in addition to INPUTEDIT a$ for editing variables.

I noticed that ELSE and REM are dealt with in the same way in parts of the BASIC code – that makes a lot of sense!

I am very tempted to obtain one of those working 32-bitted TWIN programs, and link it in to the TWIN / TWINO commands! (of course … a challenge exists because I am running on an ARM64 CPU!).

However, I can’t exactly do *DESKTOP from the Aarch64 BASIC, so it would be nice to be able to invoke an editor from it! (which could just involve doing a C malloc() to grab some workspace for TWIN (the software itself, and workspace for it), which would allow editing of the BASIC program from ARM64 BASIC.

I would need to write an ARM32 emulator, but once that is done, TWIN could call a C function, which allocates a buffer for TWIN (allowing TWIN to think it is in a normal &8000 onwards situation, or at least that BASIC starts at &8000), copy the BASIC program over to that buffer, run (emulated) TWIN, then copy the memory back over to the active 64-bit BASIC workspace when done.

(I don’t know how TWIN works, or how it uses workspace, so the idea above would need to adapt based on that). I guess a decent set of SWI support code would be needed, as well as reasonably compatible Acorn VDU driver code for TWIN to draw stuff, and keyboard input code accessible via SWIs too). On that note, I am about to post something to the ‘Porting BBC BASIC to ARM64’ thread :D

I do think that, one day, if a group of us combined our efforts and stuff we have learnt, we could make some good advances for RISC OS :)

A thought about TWIN/TWINO;

I think the sources are (not available), but I could be wrong about this;

Do we know if TWIN is ‘owned’ (not the correct term, but still…) by ROOL / Risc OS Developments, or under the same license as the current RISC OS 5 source code?

If not, that would be a good reason for using ARM32 emulation for this (in a future processor-agnostic version of RISC OS)

There seems to be source of ‘Twin’ on Rick’s site.

Seems odd that PDFs in a Archive can’t be loaded by my phone :-(

Cannot display PDF ’twin.pdf is invalid format

Cannot display PDF ’twin.pdf is invalid format

Are you using Google’s Drive PDF Viewer? I find that to be rather inconsistent at dealing with PDFs.

Works perfectly fine with the latest version of Adobe Acrobat Reader ¹ and also Xiaomi’s Mi PDF Viewer. Just tested it on my phone. Also works with !PDF (v3.02) on RISC OS, though for some reason the title bar says “OvationPro”. Hmmm…

That being said…

Seems odd that PDFs in a Archive can’t be loaded by my phone :-(

It’s worth noting that more recent versions of Android are a lot more restricted in what applications can/cannot do. I use an old (pre-malware) version of ES File Explorer and up to Android 10 (or 11?) it’s perfectly able to open an archive and let me view a PDF simply by tapping on it and choosing what to open it with.
As of Android 12, I now need to extract the file to the filesystem and then view it. I think what is happening here is that the file is temporarily being extracted to a private area belonging to ES File Explorer (maybe in /Android/Data), and the OS is blocking Adobe Reader from being able to access it because it’s data belonging to another app.

So if, like me, you’re used to tapping a file in an archive to view it and you’re using a recent Android, maybe that’s the issue? Extract it first, then view it.
Unless you’re using Drive PDF Viewer, in which case…use something else…

¹ This is my yardstick. If something in Adobe’s document format works with Adobe’s software, then anything else is just plain wrong.

If something in Adobe’s document format works with Adobe’s software, then anything else is just plain wrong.

Or just not able to deal with this week’s random additions to the Adobe “standard” – most features seem to come with bugs and security holes.
The “End User Compute” guys are checking whether Edge/Chrome do all that is required, with a view to removing AAR from the standard build.

Or just not able to deal with this week’s random additions to the Adobe “standard”

T’was created on RISC OS, so that’s not going to be a problem. ;)

If something in Adobe’s document format works with Adobe’s software, then anything else is just plain wrong.

NO

Let’s be clear – Adobe submitted the PDF standard to the ISO, and I was asked by the Chairman of the ISO PDF committee to explain how fonts work in PDF so that it could be documented correctly in that international standard. (Adobe did this to counter Microsoft’s extreme paranoia about format ownership at the time, that led them to develop the XPS document format which I was also involved in, being part of the team that wrote the reference implementation)

The explanation of how to work with fonts in PDF is basically formulated as “do this, or else do that, or maybe do this other thing, or maybe try this heuristic, and if none of that works, do whatever you like” (look it up, you’ll see the shape is exactly this). This is entirely due to the actions of the Acrobat team who, every time the PDF standard was published, then went and added some additional complexity… perhaps to solve some pressing compatibility issue for an important customer… or perhaps to ensure that Acrobat always displayed things that 3rd party implementations weren’t able to because they were following the defined rules – I spent many years fixing Adobe-related compatibility problems, and Acrobat was always the one breaking the rules.

PDF is an international standard (thanks Microsoft!), so Adobe’s wonky implementation absolutely is not the definitive version.

due to the actions of the Acrobat team who, every time the PDF standard was published, then went and added some additional complexity… perhaps to solve some pressing compatibility issue for an important customer… or perhaps to ensure that Acrobat always displayed things that 3rd party implementations weren’t able to because they were following the defined rules

As I said: “Or just not able to deal with this week’s random additions to the Adobe “standard””

I look at it from the customer support point of view – which is that the goalposts move constantly, therefore Adobe are a-holes.
If ever there was a reason to push the idea of using third party file generation applications – PDF is a prime reason.

I spent many years fixing Adobe-related compatibility problems

That’s a fair point.

What I meant was that if something not created using Adobe tools (in this case, created by RISC OS) works on Acrobat but not something else, I’d be inclined to suspect the something else rather than thinking “broken PDF”.
It would be a different story if something created using Adobe tools worked with Acrobat but failed on other readers.

For the PDF in question, I have four data points: Acrobat, Mi PDF Viewer, and !PDF work; Google PDF Viewer doesn’t. So it’s Google’s fault, not mine.

It may well be that Google’s PDF Viewer misbehaves because it’s trying to work around Adobe’s mess and makes a mess all of its own… whatever, it’s broken.

If ever there was a reason to push the idea of using third party file generation applications – PDF is a prime reason.

That you can get for free (the likes of GhostScript) what they charge a pretty penny for is a prime reason. Okay, fair enough, their tools are the ones that allow you to embed completable forms and JavaScript for entry field validation…..which is an abomination that should be nuked from orbit.

BTW that PDF looks fine to me, and Google is happy with it despite it containing no text:

What’s the easiest way of OCRing this file?

Pretty sure the GCAL source is around…

What’s the easiest way of OCRing this file?

Just ask someone who’s already done it.

Back in 2021, I was in touch with Stuart about saving the user manual from neglect. I have it in several formats: Impression; TechWriter; PDF file.