32016 Bas32 port to Linux.

[gtoal]

I thought I should start a clean new thread for this project (and I've marked the others that were about specific questions I had as "SOLVED")

I'm porting Bas32 to Linux (or I guess Windows or MacOS - anything with a C compiler) by creating a replacement interface layer for 32016 SVC calls (Tiny Kernel/Pandora) which is linked in to the new bas32 executable along with the 32016 executable code itself, so that it looks like a native program on whichever system you're building it. (This is the first step in a larger project but I'll make it a goal in itself and put up the code on github when it's ready).

Meanwhile as a tease, ... I've just now added simple file I/O - at least enough to load and save Basic programs - and while doing so, came up with a way to save file attributes on Linux in a rather clean way - no more "$FILE" or "FILE.inf" companion files needed, which were problematic to keep in place with the actual data files. This is done by using 'extended attributes', which are available on most linuxes. Anyone porting to Windows could add code to use 'Alternative data streams' instead, and I guess the old ".inf" files or ",f00" naming convention could still be used as a fallback for systems that don't support forks. (I haven't implemented these alternatives - just the linux version).

Code: Select all

NS32016$ ./bas32
BBC Basic IV for 32000 (c) Acorn 1986
>10 REM test of saving load/exec address on saving basic file
>20 PRINT PI
>SAVE"testbas"
>QUIT
NS32016$ getfattr -d testbas2
# file: testbas2
user.acorn_exec="0x000021b0"
user.acorn_load="0x00006c91"

The base for this project is in place - all it needs to be useful is to write code to emulate the various Pandora SVCs which in turn need code to implement functionality equivalent to BBC Micro MOS calls. I've written skeleton code, and whenever someone hits a call that they need to make a program work, they can flesh out the skeleton with a solution. I'm just going to do a few that are needed for my purposes but I guess we can use github to merge other people's additions too, if this is useful to anyone else. (I do warn however that I'm a github newbie and haven't done anything with pull requests yet so it may take a little time for me to get up to speed... And give me a couple of days before I upload an initial source to github.)

If you saw the earlier threads, you'll know this is based on the 32016 emulator from Hoglet's PiTubeDirect project ( https://github.com/hoglet67/PiTubeDirec ... rc/NS32016 ).

I wonder if there is any existing code for simulating MOS functionality that also doesn't emulate a complete BBC Micro? Maybe in some of the modern replacement Basic ports? I did find some code in the 'go' language ( https://github.com/ivanizag/bbz ), but I couldn't use any of its actual implementation - I just borrowed some of its structure as a hint to create the skeleton for where new code is to be placed.

(Btw it occurs to me that a similar program could be written to port ARM applications for Brazil/Arthur, with a lot of the MOS simulation code being shared.)

Graham

[BigEd]

Nice one!

For minimal MOS emulation, there are a few bits in Ian Piumarta's run6502 code:
https://www.piumarta.com/software/lib65 ... /run6502.c
(See particularly functions osword, osbyte, oscli.)

(Although I'm not 100% with you on the file attributes idea, as it's a departure from common practice and a bit of a challenge to portability. Awkward though the inf file is, it works on all systems and passes through zip and unzip safely. And we're all used to it. But maybe I'm just being reactionary.)

[jgharston]

The standard way of mapping between Acorn and Unix file attributes is described at the BeebWiki.

[KenLowe]

Meanwhile as a tease, ... I've just now added simple file I/O - at least enough to load and save Basic programs - and while doing so, came up with a way to save file attributes on Linux in a rather clean way - no more "$FILE" or "FILE.inf" companion files needed, which were problematic to keep in place with the actual data files. This is done by using 'extended attributes', which are available on most linuxes. Anyone porting to Windows could add code to use 'Alternative data streams' instead, and I guess the old ".inf" files or ",f00" naming convention could still be used as a fallback for systems that don't support forks. (I haven't implemented these alternatives - just the linux version).

(Although I'm not 100% with you on the file attributes idea, as it's a departure from common practice and a bit of a challenge to portability. Awkward though the inf file is, it works on all systems and passes through zip and unzip safely. And we're all used to it. But maybe I'm just being reactionary.)

If going down the Linux extended attributes route, it's worth being aware that PiEconetBridge project also uses these, so it would be ideal if they were being used consistently.

Edit: These are what they look like in PiEconetBridge:

Code: Select all

pi@raspberrypi:~/econetfs/0Disc-01/Games/OZMOO/Zork1 $ ls -l
total 244
-rw-r--r-- 1 pi pi     83 May 21 13:29 '!BOOT'
-rw-r--r-- 1 pi pi    120 May 21 12:45  BUILD
-rw-r--r-- 1 pi pi    793 May 21 12:45  CACHE2P
-rw-r--r-- 1 pi pi 105264 May 21 12:46  DATA
-rw-r--r-- 1 pi pi    498 May 21 12:46  FINDSWR
-rw-r--r-- 1 pi pi     74 May 21 12:46  INSV
-rw-r--r-- 1 pi pi   7060 May 21 12:46  LOADER
-rw-r--r-- 1 pi pi  10675 May 21 12:46  OZMOO2P
-rw-r--r-- 1 pi pi  11998 May 21 12:46  OZMOOB
-rw-r--r-- 1 pi pi  12242 May 21 12:46  OZMOOE
-rw-r--r-- 1 pi pi  12529 May 21 12:46  OZMOOSH
drwxr-x--- 2 pi pi   4096 May 21 12:46  SAVES
-rw-r--r-- 1 pi pi     30 May 21 12:46  TURBO
pi@raspberrypi:~/econetfs/0Disc-01/Games/OZMOO/Zork1 $ getfattr -d *
# file: !BOOT
user.econet_exec="00000000"
user.econet_homeof="0000"
user.econet_load="00000000"
user.econet_owner="0002"
user.econet_perm="03"

# file: BUILD
user.econet_exec="00000000"
user.econet_homeof="0000"
user.econet_load="00000000"
user.econet_owner="0000"
user.econet_perm="37"

# file: CACHE2P
user.econet_exec="ffff2c00"
user.econet_homeof="0000"
user.econet_load="ffff2c00"
user.econet_owner="0000"
user.econet_perm="37"

# file: DATA
user.econet_exec="00000000"
user.econet_homeof="0000"
user.econet_load="00000000"
user.econet_owner="0000"
user.econet_perm="37"

# file: FINDSWR
user.econet_exec="ffff0900"
user.econet_homeof="0000"
user.econet_load="ffff0900"
user.econet_owner="0000"
user.econet_perm="37"

# file: INSV
user.econet_exec="ffff0a33"
user.econet_homeof="0000"
user.econet_load="ffff0a00"
user.econet_owner="0000"
user.econet_perm="37"

# file: LOADER
user.econet_exec="ffff8023"
user.econet_homeof="0000"
user.econet_load="ffff1900"
user.econet_owner="0000"
user.econet_perm="37"

# file: OZMOO2P
user.econet_exec="00003b66"
user.econet_homeof="0000"
user.econet_load="000012d0"
user.econet_owner="0000"
user.econet_perm="37"

# file: OZMOOB
user.econet_exec="ffff6cd4"
user.econet_homeof="0000"
user.econet_load="ffff3f08"
user.econet_owner="0000"
user.econet_perm="37"

# file: OZMOOE
user.econet_exec="ffff5bb8"
user.econet_homeof="0000"
user.econet_load="ffff2cf8"
user.econet_owner="0000"
user.econet_perm="37"

# file: OZMOOSH
user.econet_exec="ffff6fec"
user.econet_homeof="0000"
user.econet_load="ffff400d"
user.econet_owner="0000"
user.econet_perm="37"

# file: SAVES
user.econet_exec="00000000"
user.econet_homeof="0000"
user.econet_load="00000000"
user.econet_owner="0000"
user.econet_perm="15"

# file: TURBO
user.econet_exec="000000d0"
user.econet_homeof="0000"
user.econet_load="000000d0"
user.econet_owner="0000"
user.econet_perm="37"

pi@raspberrypi:~/econetfs/0Disc-01/Games/OZMOO/Zork1 $

[gtoal]

Found it. Can't say I like the implementation (decimal numbers for everything including owner names??!), but I take your point.
As to BigEd's comment - I did suggest that if saving to a file system that didn't support extended attributes it would fall back
to .inf files. (OK, admittedly I didn't say so here, it's buried in a comment in file you haven't seen yet, in a locked filing
cabinet marked 'beware of the leopard'... - https://gtoal.com/acorn/pandora-WIP/NS32016/Pandora.c - but the point is
I did think of that...)

if (getxattr((const char *) path, "user.econet_owner", attrbuf, 4) >= 0) // Attribute found
{
attrbuf[4] = '\0';
r->owner = strtoul((const char * ) attrbuf, NULL, 16);
}

if (getxattr((const char *) path, "user.econet_load", attrbuf, >= 0) // Attribute found
{
attrbuf[8] = '\0';
r->load = strtoul((const char * ) attrbuf, NULL, 16);
}

if (getxattr((const char *) path, "user.econet_exec", attrbuf, >= 0) // Attribute found
{
attrbuf[8] = '\0';
r->exec = strtoul((const char * ) attrbuf, NULL, 16);
}

if (getxattr((const char *) path, "user.econet_perm", attrbuf, 2) >= 0) // Attribute found
{
attrbuf[2] = '\0';
r->perm = strtoul((const char * ) attrbuf, NULL, 16);
}
if (getxattr((const char *) path, "user.econet_homeof", attrbuf, 4) >= 0) // Attribute found
{
attrbuf[4] = '\0';
r->homeof = strtoul((const char * ) attrbuf, NULL, 16);
}

[BigEd]

I have a strict policy always to be beware of leopards... it looks like this should work on Mac and Linux, which is a jolly good start, and enough for me. But I know there are Windows users just a stone's throw away. Sounds like they will get the fallback behaviour, so everyone should be happy, although passing files from one system to another might need care and attention.

[SKS1]

Wasn't BCPL also a plain Pandora image, not requiring Panos? And I don't recall the early versions of the 16032 assembler needing Panos.

[jgharston]

In 'tother thread:

There's the BBCMOS module in the Serial Tube Host, which is called by the serial Tube transactions, and the similar EMT module in PDPEm and the MOS module in 6809Em which do the same.

And of course there's the hostio.c module in cZ80Tube, a Z80Tube emulator written in C.

The coding style is.... well, let's just say I wrote it 30 years ago, and it was my first "big" C project. From a quick check it doesn't implement random access file I/O, just OSFILE file I/O.

[gtoal]

Thanks, if there's anything there I can use I will do.

Tutu: I haven't found a standalone versions of bcpl or asm32/zasm but they may still be out there somewhere. Hey - change of subject, but while you're here - did you keep an original copy of the 6502 Pascal BL-code interpreter source or Lionel's pascal compiler before you started converting it for Arm?

G

[SKS1]

Tutu: (snip) Hey - change of subject, but while you're here - did you keep an original copy of the 6502 Pascal BL-code interpreter source or Lionel's pascal compiler before you started converting it for Arm?

G

Alas, not as such. A great loss. Not through neglect at the time at Acornsoft or Acorn, as copies were lodged in the D.O. and we had a production archive at Acornsoft too. Acornsoft languages took over maintenance of BBC ISO Pascal, so we did have updated HiPascal etc from time-to-time, but there were really very few bugs to fix I only took away from Acorn things that could/would need attention in the near future, like the Filer (fed updates back for RISC OS 2.01) and 65Host (nothing was asked for, and they even released the wrong version). I have a vague memory that there had been discussions about resurrecting 'my' ARM ISO Pascal - maybe as a cheap language option for schools - otherwise I would have nothing of that here, but clearly nothing came of that.

I have uncovered* a very early version of the Pascal compiler for ARM (started under ARMulator; this is early 1986) [Edit: it compiled on the BBC Micro plus 6502 Tube, before bootstrapping over to ARM once we had an actual A.E.S.]. It produces a trivially-modified BL code that could be fed into a BCPL translator to produce ARM code. This version hasn't actually changed from Lionel's original (as fixed by Acornsoft) very much. All my changes do appear to be documented and tagged Tutu. Both myself and Tony ('Sam') used lower-case code to readily distinguish it from the original. Most of the changes that I made for ARM do seem to have the original code there for reference, simply commented out.

http://croftnuisk.co.uk/exports/TutuPascal1986.zip

Stuart (aka Tutu for those that weren't aware)

* thank you working floppy drive! And quality floppies for a change.

[gtoal]

Have I got a surprise for you!

https://gtoal.com/acorn/arm/TutuPascal2/ (I've put your files next to it in https://gtoal.com/acorn/arm/TutuPascal/ )

I *did* once have the full sources for the 6502 Pascal from Ben & Lionel, but I just can't find those files again. I found those files of yours when grepping all my disk images for "Haines" when looking for the Beeb code! - I can't remember how I acquired them - I have a vague recollection of starting a Pascal compiler port myself and having a look at what you'd done.

I *do* have the source of Ben's Editor from the Pascal system - I've just now uploaded it to http://gtoal.com/acorn/beeb/Pascal_Editor/ - but it doesn't include the BenLionelcode interpreter. It would have been nice to have found enough of it to rebuild.

PS Sorry; I called you TuTu in the mail because I couldn't remember if you were a Stuart or a Stewart, so I used the name I could remember to spell Quite understand if you've grown out of it and didn't want it resurrected. I see now you're a Stuart which I'll use in future. (So does your name explain why you live in Perthshire nowadays? I didn't realise you were a fellow Scot!)

G

[SKS1]

Have I got a surprise for you!

https://gtoal.com/acorn/arm/TutuPascal2/ (I've put your files next to it in https://gtoal.com/acorn/arm/TutuPascal/ )

I *did* once have the full sources for the 6502 Pascal from Ben & Lionel, but I just can't find those files again. I found those files of yours when grepping all my disk images for "Haines" when looking for the Beeb code! - I can't remember how I acquired them - I have a vague recollection of starting a Pascal compiler port myself and having a look at what you'd done.

I *do* have the source of Ben's Editor from the Pascal system - I've just now uploaded it to http://gtoal.com/acorn/beeb/Pascal_Editor/ - but it doesn't include the BenLionelcode interpreter. It would have been nice to have found enough of it to rebuild.

PS Sorry; I called you TuTu in the mail because I couldn't remember if you were a Stuart or a Stewart, so I used the name I could remember to spell Quite understand if you've grown out of it and didn't want it resurrected. I see now you're a Stuart which I'll use in future. (So does your name explain why you live in Perthshire nowadays? I didn't realise you were a fellow Scot!)

G

Ha! I bet it wouldn't take much effort to peel back those changes and get it generating the same BL code as the release on a 6502 system. I think I was somewhat more careful doing that variant, having been a bit cavalier earlier adapting it for the Communicator's 65816.

Glad that Ben's Editor source resurfaced though. I did have good experience of using that, and even worked on it a little, including CMOS-ising it for the Master. I don't recall seeing a commented disassembly of the Pascal ROM (#1?) BL code interpreter & Edit; having the Edit source to hand might go a long way to help with that, as maybe might ATran / ADisasm for the BL code interpreter bits.

Tutu is fine, I think that Jon T and Brian C still call me that! Not actually Scottish (proud Yorkshireman) but my grandmother was a Stewart. Perthshire can be explained by Anne's folks coming from Aberfeldy; I had always wanted to retire somewhere hereabouts and the opportunity presented itself twenty years ago. A couple of cousins have moved to the area too.

Stuart

[SKS1]

Meandering back to the topic, does anyone have the Bas32f source? I think the 32016 emulator does support the FPU.

[gtoal]

Wasn't BCPL also a plain Pandora image, not requiring Panos? And I don't recall the early versions of the 16032 assembler needing Panos.
Meandering back to the topic, does anyone have the Bas32f source? I think the 32016 emulator does support the FPU.

I found BCPL - it was hiding under the name "B16"

I'm putting what Pandora binaries I can find in https://gtoal.com/acorn/pandora-WIP/bin/

G

[gtoal]

(Btw it occurs to me that a similar program could be written to port ARM applications for Brazil/Arthur, with a lot of the MOS simulation code being shared.)

Very belatedly I discovered that there *is* such a thing. You guys mostly will know this already I guess. It's called "riscose". I was very pleased to find it as it was exactly what I was considering trying to write myself, and seeing how big it is already I realise I would never have got anything running!

I've now built riscose three times because after each build I discovered a later release by a different maintainer!

Original: https://riscose.sourceforge.net/ (very old)

Moved to github: https://github.com/hamishcoleman/riscose (slightly old)

Currently maintained on a private repo: https://repo.or.cz/riscose.git (up to date)

Unfortunately the most recent one doesn't seem to have an obvious place to post comments unlike the github.com issues page.

There does appear to be a huge amount of work needing to be done before running anything useful. I'm looking at this for the same reason I was looking at the 16032 kernel layer - running the IMP compiler for ARM. I did get it working under Arculator but many of the programs have to run from ADFS rather than HOSTFS and I've not yet been able to get a hard drive going - just floppies. (not looking for help there, I know what I need to do...)

Graham
PS Tangentially relevant: are you aware of the ARM1 to Thumb JIT at https://dmitry.gr/?r=05.Projects&proj=27.%20rePalm ? The author says it should be easy to extract for other projects.