Programming: AMPLE and FORTH

Hi.

I was wondering if anyone knew of a FORTH system for RO5, over which an approxomation of the AMPLE music Nucleus could be implemented.

AMPLE was a music programming system on the BBC Micro and I’d like to use something like it on R05/Pi.

A few years ago an incomplete !Ample system was developed (and released online) but I’ve been unable to find it. It was not sadly as interactive as its BBC counterpart.

There is a nearly free FORTH system on Windows, BB4WFORTH developed by Richard Russell, which could perhaps be ported. (Arguably a forth system on ARM/R05 should be more straightforward than on Windows/x86)

So does anyone want to have a go at implementing AMPLE for Ro5 and ultimately the Pi?

AMPLE…the hours I spend coding in that!

Your own post from 2009 links to RO Ample here

I note that the AmpMod module in !Ample.modules (0.27) is not 32-bit compatible.

And sadly, that version isn’t 32bit owing to one Module :(

Oh well..

Sadly the original domain is down so it’s not possible to find the author to enable the app/module being made 32 bit.

So How do you write a RISCy FORTH?

OK update – There is an ’’ARMForth’’ on an FTP server, but it’s dated 1992. (So isn’t ANSI as such).

However like BB4WFORTH on PC, the source seems to be a BBC BASIC hosted assembler.

Hmm…

I’ve just 32bitted Ample for you

Who’s the man!?

I wouldn’t get too excited, although I’ve 32bitted it – its dependent on IOC! Didn’t spot that until after I’d posted.

There is a nearly free FORTH system on Windows, BB4WFORTH developed by Richard Russell, which could perhaps be ported. (Arguably a forth system on ARM/R05 should be more straightforward than on Windows/x86)

Crap… You contacted me about this, didn’t you?

That’s the problem with reading mail on an iPad. You can’t do anything useful with funny foreign stuff like zip files, and with a memory like mine…

I’ll go download the module from jaspp now and see if I can convert it to use HALtimer. Just let me go pop the kettle on…

I’ve just posted the source for you, I hacked it together for ExtBas so you might want to convert it to something more useful first.

Thanks.
Don’t have ExtBas on the Pi; changing “CPSR_all” to “CPSR” (line 17470 (more or less)) does the trick.

Please tell me this Service Call handler is a joke. This module is HORRIBLE! Scant commenting, and – if I read correctly and Ba2% (yes, the variables have names like that) is the service call routine, it appears to finally get around to checking the service call number (for Service_MIDI) a mere seventeen instructions and one branch later. WTF!? I wish there were more comments so I could figure out what all this crap it is doing on every service call was for…

Anyway, got myself the IOC data sheet. Stocked up on Babybel. Put the kettle on again… <sigh>

Well I tried the new version under RO 5.20 in RPCEmu, No module eror, but it now does an abort on Data fetch. Thank you for your assistance..

This has me wondering if it’s not just the Module that needs examination for 32bit issues :(

Might be quicker at this point to just write a new !AMPLE 32bit from scratch, based on code in various ARMForth’s (BB4WFORTH etc..)

Also, I think the original 26bit port was not open source as such sadly…

Rick – I disassembled it from the original module…hence the mess. It didn’t look like too much work, I counted around 5 or so read/writes to IOC all Timer 1 related.

On the subject of FORTH’s Generally… -
ARM FORTH :
http://downloads.orpheusweb.co.uk/pub/RISCOS/StuttgartFTP/riscos/lang/forth/
The file is aforth.spk

I’m not sure what version of the FORTH standard it’s using…

BB4WFORTH (Richard Russel’s tweaked version of JonesForth) passed Most of the ANS core(ie the 1994 standard), but could presumably be further tweaked. (It’s SYSCALL function is Windows specific for example, and it does it’s own implementation of certain OS calls that are native in RISC OS)- A version of BB4WForth used to be in BB4WFORTH Yahoo! Group file archive, but would given issues with Yahoo! Groups best obtained from them directly.

!ArmForth on Ro.520 (in RpcEmu) crashed with an error from RPCEmu about some kind of FDC error 56.
(I suspect it’s not been fully evaluated for 32bit yet.)

Both !ArmForth and BB4WFORTH seems to have fairly liberal distribution terms, and have the advantage there code can nominally be rebuilt using the in-built assmeblers on the respective platforms..
ARM FORTH appears to have an ARM2/3 era assembler, BB4WFORTH does not have an assembler..

OK Thanks for looking into this people..

(Oh and a final note, IIRC some UEFI based Bios code for extension devices, utilises a FORTH like subset.. UEFI support in RISC OS is a 20 years in the future item though.)

Rick Murray – It’s not compiled C code is it?

This has me wondering if it’s not just the Module that needs examination for 32bit issues :(

Drop the runimage onto Armalyser and look at the stats – 407 instances of non-32bit code. Ouch!

At this stage it would be quicker to write new version, possibly using the ArmForth/BB4WFORTH sources I linked as a possible basis.

OK So what does AMPLE have that most FORTH’s don’t?

• String stack
• Stack “Frames” for events (like notes)
• Concurrency – I.E Multiple players.
• (Not sure if AMPLE on the BBC had pre-emption for multiple players)
• Modularisation… OK so loading Binary modules from the BBC Micro won’t be possible.

In terms of RISC OS specfics for an AMPLE like music player

• Dynamically built Voice Generator,
• Portable timing (i.e HAL_Timers) for multimedia.
• Channel mixing. – I.E Some trackers have at least 32 tracks.

Hmm.. (me has a sudden vision of being able to program the DR WHO theme entirely in AMPLE and have it sound exactly like the TV… I’m dreaming :( )

I disassembled it from the original module…hence the mess.

Ah… This is automatic. That helps explain the terseness. ;-)

Interestingly, it links in to SharedCLib to do stuff. I’m working on unwinding that so I can see what is going on.

Oh, and this tickled me:

.setV
  STR   R0, [R13, #-4]!
  MOV   R0, #1 << 31
  ADDS  R0, R0, R0
  LDR   R0, [R13], #4

I’ve commented that out and replaced it with:

.setV
  CMP   R0, #1<<31
  CMNVC R0, #1<<31

Okay… For now I’m just going to nuke all the IOC stuff, and replace it with nothing. Let’s at least get the module to load, eh?

Have a look at the code that calls SWI “XSharedCLibrary_LibInitModuleAPCS_32”. There’s some really fruitcake stuff going on there.

Oh, it wouldn’t work anyway. Extra functions were included in the APCS-32 version, so all the workspace and such needs to be jiggled around. I don’t appear to have any docs about how the SWI changed and what the extra calls are.

As it happens, it is failing before even this… at the patch-ourselves stage (.Ba140%). Maybe, perhaps, the modern processor is kinda objecting to all this self-modifying malarkey. It is, to be frank, a very very peculiar way to write a module!

Here’s my code version, if you want to poke around:

http://www.heyrick.co.uk/random/ampmod_source,ffb

I am going to stop for tonight. And, to be honest, I’m not certain I will carry on. This seems like flogging a dead horse – perhaps looking to write an interpreter for the AMPLE music files (whoa, bizarre language!) might be a simpler proposition in the long run?

The player, for what it is worth, does not work correctly under RISC OS 5 on a Pi. It can be coaxed into starting without the module, (run the !RunImage directly, choose MIDI export), however it makes a real mess of interpreting its own file format – Nocturne throws an error interpreting a comment. Birthday will start, throw a error about “Bad bar in word RUN” when trying to save MIDI, and it will think it has done it, but __EXPORT__ in !Scrap will be left open (and with some junk in it) and the MIDI file (whereever) will be also left open (and empty).

For a laugh, I threw the !RunImage at ARMalyser. I’m surprised it worked at all, if you want to fix it to at least not behave in the 26 bit PSR munging way, there are 407 things that will need changing. And that’s just for starters. [edit: okay, Steve said the same thing two hours ago – shows how long it has taken to write the message and “do stuff”]

Really. Dead horse. Floggage. Much.

Oh well…we tried. It should run under Aemulor.

OK So what does AMPLE have that most FORTH’s don’t?

I know nothing about FORTH. The language used looks extremely weird, but at least the documentation is pretty detailed.

Modularisation… OK so loading Binary modules from the BBC Micro won’t be possible.

Binary how? Compiling music into executable code? If the format is known and regular, it may be possible to load and parse. Not something I’d stick on the v1 feature list, though…

Dynamically built Voice Generator,

Mmmm, I’m not the best qualified for stuff like that. Too much maths. I’d stick to using sound commands on voices. It would be cool to have SoundFont playback, but not yet on RISC OS…

Portable timing (i.e HAL_Timers) for multimedia.

…? The OS provides a tick at a hundred times a second. Is this not sufficient resolution for timing music?

Channel mixing. – I.E Some trackers have at least 32 tracks.

…because “they could”? I recall in the Amiga MOD wars, tracker editors came out with more and more insane features just to be “better” than the last thing released. A guy I knew back then gave up on that and learned piano instead. ;-)

It is worth pointing out that the basic RISC OS sound system supports eight voices.
General MIDI supports 16 channels (well, 15 as #10 is reserved for percussion/drumkit). XGLite supports 16 channels. General MIDI level 2 is worse – 16 channels with #10 and #11 reserved for percussion.

On the other hand – most MIDI devices differ from trackers and basic software synth in that one channel can play multiple notes simultaneously. General MIDI supports 16 melodic voices at once and XGLite raises this to 32 (with XG3 taking this to 128!). If I want a piano to play a chord and a note from the melody, I just push all four notes out to the channel at the same time. Hmmm, I wonder if AMPLE supports this?

Rick Murray and Jon Abbot. Thank you for trying.

It seems I’m going to have to find someone that willing to write a 32 bit clean AMPLE from scratch. :(

And to do that needs someone to find and 32bit an appropriate FORTH first :(

(ARMForth exists and loads on R05.2 but when I move into the window RPCEmu throws an unexpected FDC error)

Open question to the floor? Anyone here able to explain FORTH to Mr Murray?

http://www.ece.cmu.edu/~koopman/forth/hopl.html is an introduction to FORTH.

A while back someone OCR’ed “FORTH on the BBC Microcomputer” ( It’s on the 8BS site IIRC)

For a much much longer explanation I suggest reading the various standards ..

Also – http://galileo.phys.virginia.edu/classes/551.jvn.fall01/primer.htm

I’m just pining to get my Music 500 up and running again! I’ve got the demo tape somewhere as well…fond memories. Have to search the net for the Music 5000 demo tracks…