Modern development environment for Archimedes

[kieranhj]

Hey all, I've recently started dabbling in some ARM development again, as a change from several years of 6502, targeting the 'classic era' Archimedes machines, so A310 through A5000, but mostly focused on A30x0 as a standard configuration.

I thought I'd start a thread on setting up a modern development environment for the Archie to see what other folks think. As I do most of my hobby coding whilst commuting on the train, it's not really feasible to use real hardware and as awesome as Arculator v2 is, I don't really want to write code inside the emulator itself as the tools of the era now really show their age.

My requirements are:

• Windows based
• Proper code editor
• Fast assembly direct to an executable binary
• Fast testing of output executable in an emulator

What I've ended up with is quite similar to my BeebAsm setup:

• VSCode as the editor
• vasm assembler built for Windows with the standard syntax module, ARM cpu module and simple binary output module
• Arculator v2 emulator (awesome)
• A simple make.bat batch file for assembly and copying to hostfs folder for rapid iteration in the emulator

Essentially my workflow then becomes: edit -> type make in cmd -> press F12 and type *<executable name> in open Arculator window. The turn around time is seconds as the assembler is pretty much instant and Arculator just picks up the new file in the hostfs folder instantly.

Some gotchas / things that could be improved:

• I was using simonm's BeebAsm syntax highlighter plugin for VSCode but literally just installed an ARM assembly highlighter - will let you know how I get on!
• I could run the build commands from directly inside VSCode and/or use proper make - old habits die hard, I guess
• The standard syntax module for vasm takes a bit of getting used to - could potentially write my own BeebAsm / BBC Basic assembler syntax module...
• The worst part is that the ARM assembler in vasm has some bugs of which I've fixed a couple:
  • mov reg, #imm sometimes results in using a non-obvious / unnecessary shift - fixed(ish)
  • adrl just flat out didn't work at all - fixed
  • sometimes the assembler fails to resolve all symbols after 8 passes due to an alignment issue - temporarily adding a mov r0,r0 NOP anywhere fixes it
  • looks like conditional assembly flag is getting confused with the opcode mnemonic - e.g. adrleq is interpreted as adrle
• For now I'm just assembling one output binary but it is possible to build object files with vasm then link them with vlink

If anyone is interested I'm happy to share the resulting source / binary. I'm on vasm version 1.8e whilst the latest version is 1.8g.

This has proven to be pretty efficient for me. My only missing feature is a debugger in the emulator but !DDT works reasonably well within RISCOS once you get used to the shortcuts, it's a bit slow though. Does anyone else have a similar setup or particular thoughts on this topic?

EDIT: I guess this could have been in the 'development tools' forum. I'll leave it up to the mods if they feel like moving it.

[myelin]

Very nice!

For bare metal stuff, which is a pretty particular case as I doubt anyone else is trying to write ROMs for the Arc, I used the embedded ARM GCC (arm-none-eabi-gcc and friends). It turns out that it will build for ARMv2 if you turn off the Thumb options and don't try to compile stuff like "bx lr". After battling through the process of setting up the C stack, I could happily link C++ and assembly together, which really made things a lot easier.

Code: https://github.com/google/myelin-acorn- ... bootloader

I also use Arculator for testing, although I have to restart every time, so I have a "build and run" script that builds the bootloader (and Arculator, if necessary, because I sometimes add debug print statements in there), and launches the whole thing.

[VectorEyes]

Some gotchas / things that could be improved:

• [...]
• I could run the build commands from directly inside VSCode and/or use proper make - old habits die hard, I guess
  [...]

You can do this. The tasks.json file inside the .vscode folder defines what happens when you 'Build' and/or 'Run' in VSCode. For BeebAsm-based development I have 'Build' set up to run a shell script that calls make, then takes the resulting SSD and copies it to various places, and 'Run' spawns JSBeeb and passes it the appropriate arguments to boot up the SSD. Because 'Build' and 'Run' are just calling shell scripts, you can basically customise the build and run to your heart's content, so you'd probably be able to get them to run your build.bat file or do anything else you like.

The nice thing about the tasks.json is you can specialise it for Windows, Mac and Linux, so if you happen to be doing x-plat development, you can have different build and run steps for each platform. The not so nice thing is that the tasks.json layout is a bit esoteric. It's not actually complicated, it just takes a bit of Googling and reading the VSCode documentation before you get it right.

[sirbod]

Outside of RISCOS I also use Visual Studio Code, with an ARM addon along with Ghidra to debug problematic games. I do most development within RedSquirrel on a Windows 10 laptop though.

As "work" laptops can't be used for personal use, I'd need a 2nd laptop, so would probably use real hardware such as a pi-top or the R-Comp ARMbook. Only problem is I already commute with two work laptops, so ceased development back in March 2019 as I'm not carrying three around London! As I'm nearing the end of the project to remove one of the laptops, I might investigate the ARMbook to develop during the commute.

Modern does not mean you necessary need to use Windows 10, Mac or Linux.

[kieranhj]

Just a quick update on this, I decided rather belatedly to just contact the author of vasm to report the bugs. Lo & behold he fixed them all in less than 24 hours. I wish I had done this sooner.

There hasn't been a new official release of 1.8i yet but you can grab the nightly sources with all known bugs fixed in the ARM backend from here: http://sun.hasenbraten.de/vasm/index.php?view=source

It's a super-fast assembler and I've been enjoying using it with Arculator as my dev environment. I've had to get used to the 'GNU as standard' syntax but I'm sure I could write a BBC BASIC assembler / BeebAsm syntax frontend if I really cared about it that much.

[ericde45]

thanks for this thread, i nearly did the same setup, and i enjoy the fast compilation and execution in emulator.

[dpsharp]

It's a super-fast assembler and I've been enjoying using it with Arculator as my dev environment. I've had to get used to the 'GNU as standard' syntax but I'm sure I could write a BBC BASIC assembler / BeebAsm syntax frontend if I really cared about it that much.

In case you missed it, MarkMoxon has just released a BBC BASIC assembler -> vasm-compatible pre-processor in Python for exactly that purpose.
viewtopic.php?t=28562