TWIN editor? BBC BASIC 1.0?
tymaja (278) 143 posts |
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 |
tymaja (278) 143 posts |
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 |
Rick Murray (539) 13751 posts |
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:
|
Martin Avison (27) 1479 posts |
The TWIN & TWINO commands were removed from BASIC v1.54 in 2013. |
nemo (145) 2496 posts |
tymaja asked
I added it to nemoBasic in 2022: It’s an optimised rewrite of the code in the Its token was reused for It produces this kind of output, not terribly quickly: |
tymaja (278) 143 posts |
@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’ :) |
nemo (145) 2496 posts |
tymaja suggested:
Only in six cases – a small number of psuedovariables, originally to make tokenisation easier on the Beeb:
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 Martin chided:
But have not been elsewhere cos Twin works. And as Mind you, thanks to my custom OS_ReadLine I can |
tymaja (278) 143 posts |
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 :) |
tymaja (278) 143 posts |
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) |
Colin Ferris (399) 1798 posts |
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 |
Rick Murray (539) 13751 posts |
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 1 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…
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. 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. 1 This is my yardstick. If something in Adobe’s document format works with Adobe’s software, then anything else is just plain wrong. |
Steve Pampling (1551) 8125 posts |
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. |
Rick Murray (539) 13751 posts |
T’was created on RISC OS, so that’s not going to be a problem. ;) |
nemo (145) 2496 posts |
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. |
Steve Pampling (1551) 8125 posts |
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. |
Rick Murray (539) 13751 posts |
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”. 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.
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. |
nemo (145) 2496 posts |
BTW that PDF looks fine to me, and Google is happy with it despite it containing no text: |
Colin Ferris (399) 1798 posts |
What’s the easiest way of OCRing this file? |
Stuart Swales (8827) 1326 posts |
Pretty sure the GCAL source is around… |
John McCartney (426) 143 posts |
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. |