Making a co-pro non-Hi Language, Hi

[dhoggan]

What with the ease of using the Pi-Zero co-pro, I tend to just leave it enabled these days when programming as it makes the speed difference between COMAL and BASIC a non-issue. However, COMAL never had a "Hi" version released and I could really do with the extra 14K or so in a similar vein to the way Hi-BASIC gives over its non-high equivalent.

Can languages be relocated? I'm guessing that Acornsoft performed some special trickery to make Hi-BASIC a thing...?

[BigEd]

If you have the sources, I think it's as easy as reassembling with a different load address.

There's a more sophisticated approach - is it perhaps with 3.50 on the Master? - where the ROM data is accompanied by a relocation table so the same 16k ROM can be loaded at the usual 8000 or at some specific Hi address.

But if you don't have the sources, you need, I think, to start out with a disassembly to find out all the bytes which need changing. These days, that's easier than ever, but it's still a thing that needs a bit of time and trouble.

[dhoggan]

Ah thanks, BigEd. Sounds like it would be easier for me to just write my code more efficiently!

If only BBC Basic had CASE statements and multi-line IFs then I might be tempted, but I do find them very nice structures to use.

[hoglet]

If only BBC Basic had CASE statements and multi-line IFs then I might be tempted, but I do find them very nice structures to use.

TubeLink's Advanced Basic might be worth a look:
https://mdfs.net/Software/BBCBasic/BBC/AdvBasic/

. Over 35 new keywords
. New program loop structures (CASE, WHILE, etc)
. Multi-line'IF' statements
. New graphics commands (CIRCLE, ELLIPSE, etc)
. New error handling and TRACE debugging modes
. Instant on-screen help on keywords and status
. New statements and functions
. Mouse support (new MOUSE keyword)
. New string handling features
. INSTALL and LIBRARY commands for procedures
. Extended assembler
. Includes Aoorn's very latest 1987 Hi-BASIC

abasic.ssd

(85 KiB) Downloaded 38 times

[dhoggan]

Oh, OK - that seems to tick all the boxes.

I've downloaded the SSD file but haven't been able to find much in the way of documentation on the webinet. As such what I'm doing is probably wrong but I can't get it to work. In BeebEm, I've exported the ABROM file and renamed it to ABASIC.ROM and then tried adding it to BeebEm's ROM config. If I remove the BASIC2 ROM in slot 14 I get the following upon reset:

If I then add the BASIC2 ROM back in and try using *FX142,12 I get the following:

and it just hangs.

Clearly something is amiss. I also found a copy of ABASIC v1.02 on the web but get the same results. Also tried with the 1770 DFS as seen in your photos. Same issue. Other ROMs load just fine.

Any ideas?

[hoglet]

Any ideas?

I was using the Master.

I just booted the disk image, which loads:
- HIBASIC to slot 4
- Advanced Basic to slot 5

I then did *CONFIGURE LANG 5 followed by a Control BREAK.

Dave

[dhoggan]

AH, that works for me too when using as a Master 128.

When booting off disk on the BBC model B I get:

which makes me wonder if this is not the Beeb version. The advert accompanying the SSD does say that you need to state version of second processor when ordering - I'm nor sure if that could imply different versions for different machines too.

[hoglet]

You need to use a ROM that includes *SRLOAD, for example the 1770 DFS.

Dave

[jgharston]

AH, that works for me too when using as a Master 128.

When booting off disk on the BBC model B I get:

Abasic-fail3.JPG

which makes me wonder if this is not the Beeb version. The advert accompanying the SSD does say that you need to state version of second processor when ordering - I'm nor sure if that could imply different versions for different machines too.

Do you have SRLOAD in your Beeb? Either in ROM or on disk?

[dhoggan]

Thanks both, once I worked out that selecting the floppy controller was not enough (the lack of DFS message upon boot should have been a clue!) and that I also needed to put a suitable DFS on there too (in my case v2.26), all is working.

Hoping that it won't offer me enough - if it does then my COMAL crusade will be tough to justify

Perhaps one more for JGH: was there ever a manual the discussed the extensions, format etc?

[hoglet]

was there ever a manual the discussed the extensions, format etc?

There was a manual, but I don't think it's even been scanned.

The best reference is the HELP file, which is very-nearly a plain text file:
https://acorn.huininga.nl/pub/docs/sour ... IC/BASHELP

Dave

[Mince]

If you just want a fast, more featured BASIC with lots of memory, the one built into the ARM Native copro on the PiTubeDirect would be simplest. If you load GXR the the extra graphics commands work, too.

Also, being the ARM BASIC, the manual from the Archimedes is easily used.

(It’s a pity the HELP command from the Arc isn’t there — would be handy if that could be added!)

[dhoggan]

I guess it boils down to how far off the beaten trail you want to go. Hi-BASIC seems the most "true" to BITD whilst being most common, but with the "limits"* of the original; ABASIC adds some nice language extensions and still for common hardware of the day; ARM BASIC would give oodles of memory, but is pretty off-piste for what was common in the day.

I've been playing with ABASIC for a few hours trying to convert a game I've written on COMAL to it and it's not plain sailing. Whilst it supports nested IF statements, the inner IFs can only be single-line variants. Not an issue if you're coding with that in mind, but converting a program is effectively a logic rewrite.

I think - for this project - I'll just try and squeeze the code to get more space and then use ABASIC for the next project.

---
*I'm using "limits" advisedly here, of course. Whilst COMAL wins out in terms of structure, BBC BASIC was pretty much the best incarnation there was, and was one of the fastest to boot.

[Bobbi]

For my O level Computer Studies course we did a lot of COMAL I think it was just cos our teacher was a fan of it. But I still have a soft spot for the language.

[Coeus]

Back to high COMAL, I have made a start at disassembling it to be able to re-assemble as a high version. The code is on GitHub at: https://github.com/SteveFosdick/AcornComal

Here it is running in b-em:

I don't promise it is bug-free at the moment. I think I have found the references that need to be symbolic/be changed. There is the BRK handler, a table of error messages, the table of token text, separate jump tables to execute command tokens and function tokens found in expressions, some floating point constants and tables of constants, possibly series expansion for trig functions, which has been discussed elsewhere on here in connection with BASIC.

What I am less sure of is that part of the parser is table-driven in a not so obvious way. To rewind a little, like BASIC, when a line is entered it is tokenised and then either added to the program or executed immediately depending on whether it has a line number at the start. Compared to BASIC, COMAL does more thorough parsing of the line when tokenising it and the execution engine then assumes lines in the program are correct. This parsing is driven by a set of tables which ultimately produce an address of some code to execute but there is not a straightforward 1:1 relationship between high bytes and low bytes which would make it easy to replace the bytes in the assembler source with MSB/LSB expressions around a label - in some cases that would work but some labels look like they are off-by-one and some seem implausible.

So what I have done instead is, having spotted a table of high bytes, adjusted them for the new higher address. That means this cannot be reassembled to any random address, it must move relative to the original by a whole number of 256-byte pages. The hifile version starts at an odd address because I have removed what would be redundant service code from that version and kept the language part of the ROM at the same address as the high ROM version.

The other thing that complicates disassembly slightly is that this ROM makes extensive use of BIT instructions to skip over another instruction rather than using a branch, i.e. it skips a one-byte instruction with the BIT zp instruction (opcode &2A) and a two-byte instruction with the BIT absolute instruction (opcode &2C).

Anyway, here it is in b-em again, executing the DRAWING example program from the manual.

[BigEd]

Splendid!

[Coeus]

Here's a pre-built version for anyone who wants to experiment, updated 5th Nov. after both bugs (see below).

[Coeus]

I have found a bug.

For testing, I hacked on b-em slightly to implement range breakpoints, i.e. so one could set a breakpoint that is hit whenever execution occurs inside a range of addresses rather than at one specific address and likewise for read/write breakpoints. Using that I set an execution range break on all of &8000 to &B84B, i.e. where the low ROM would have been, excluding the small overlap at the top and likewise a write breakpoint range for B44B to F7FF, i.e. to check if it was overwriting itself.

I then ran all the example programs - thanks DV8 for supplying them on an SSD with the manual - and checked that the output was the same as running the same program with the low version of the ROM (in a 2nd b-em instance). That was all fine. Then I LISTed each program to a *SPOOL file and used *EXEC to read it back in. That called a subroutine in the low ROM area from the high version. I was able to use the 'trace' command in b-em to re-run that test and find what happened immediately prior to that and found a subroutine that had been disassembled as data and therefore wasn't updated to use a label. After fixing that it passes the test of being able to load all the examples as text with *EXEC without crashing.

I'll commit the change and update the SSD.

[dhoggan]

HI Coeus,

I've just seen this. I'm downloading now and will give it a test tomorrow. I have a few programs written and will report back.

And many thanks for taking the time to do this. Comal on a co-pro... that's my weekend gone!

Dave

[dhoggan]

I've been playing with this and whilst I am having issues with getting the ROM images working, the on-demand load works just fine. Is there a special knack for the ROM image? I've extracted it from the SSD and loaded it into the B-em ROM configuration but it doesn't seems to be recognised. It's a small thing but I tend to boot straight into COMAL, or remove the BASIC ROM altogether on my stick Beeb where free sockets are at a premium.


It also makes a big difference for my homage to Trek project - here's a before and after shot - available memory jumps sharply!

With that free space I can now implement a sub-mission (or two) for the game. After all, there's no point in writing a Trek clone if you don't add your own unique bit!

Regardless of whether the ROM images are operational, then I'm still massively grateful for the effort you've put in! I don't think that Acorn really pushed the 6502 co-pro as much as they should and the (comparative) lack of software for it didn't help.

[Coeus]

I've been playing with this and whilst I am having issues with getting the ROM images working....

I just tried it on an emulated Master by *SRLOADing into bank 4. It shows up in the output of *ROMS but suppresses the start-up message so something strange is going on. I'll run through the ROM server calls in the debugger and let you know.

[Coeus]

Ok, I have found the bug - the service code was being assembled for the wrong address, i.e. as if to run on the tube processor when it always runs on the I/O processor. I think I probably introduced that when re-arranging slightly to create a slightly short file version.

I have updated the SSD up-thread. The change is in GitHub: https://github.com/SteveFosdick/AcornCo ... 4dc67f0c98

[dhoggan]

Yep, that works a treat!

Seems to drop FREE by a few bytes but still got more than enough. In the interim I had a brainwave and put the on-demand version in the Library directory of my EconetFS. Other than a slight delay upon *COMAL you'd never know it's not a ROM. For my non-Econet Beeb, the HiRom is perfect. Haven't tried in in the Electron yet.

Of course this now means weeks of implementing warp-capable Kilingons and a subspace relay system but devil makes work for idle hands and all that!

[BeebMaster]

It would be good if some of the 32K language ROMs could be made "high", or even just compatible with the second processor. I'm thinking particularly of Inter-Word which refuses to run in a second processor. I think it would be impossible though, as it would need constant copying of different parts of the ROM code into the language area in the second processor. Maybe if it could be reorganised to put the main 16K bit as the language part, copied into the second processor, and the other code accessed from ROM. But we don't have the source code.

[dhoggan]

For me, the next obvious one would be MicroProlog as it is the only other Acornsoft ROM language that does not either have co-pro veriosn or a version that automatically takes advantage of the co-pro. Also, by the time you load the SIMPLE environment you have a tiny block of free RAM to work with - 6K or so!

Acornsoft Lisp and Forth are missing them too, but I haven't got around to playing with them yet!

[Coeus]

....I think it would be impossible though, as it would need constant copying of different parts of the ROM code into the language area in the second processor...

I don't see why that should be a problem, though, AFAIK, the OS/tube host doesn't provide any support for the client to load blocks of code from ROM on the host side. The Z80 co-pro installs an OSWORD handler to the host side of the tube to transfer blocks of data between the two (rather the existing OSWORD which just does individual bytes). The 1.2 CP/M BIOS uses this for a directory cache. A language could do the same, then use that to load overlays from one of more ROMs on the host into the client as required.

But I think the issue is that each language ROM is different. Until the relocation scheme introduced by MOS 3.50, and I am not sure if there are any commercial ROMs that take advantage of it, there is no general solution and t is a case of looking at each language in turn to see what can be done.

[SKS1]

For me, the next obvious one would be MicroProlog as it is the only other Acornsoft ROM language that does not either have co-pro veriosn or a version that automatically takes advantage of the co-pro. Also, by the time you load the SIMPLE environment you have a tiny block of free RAM to work with - 6K or so!

Acornsoft Lisp and Forth are missing them too, but I haven't got around to playing with them yet!

I believe Acornsoft LISP should already work 'Hi' with the 6502 Co-Pro. viewtopic.php?t=23053

[dhoggan]

Ah, good to know. I wasn't sure as it was (and still is ) on my list of languages to have a play with.

I have to say though that the HiComal is just awesome and still loving using it!