I have been working on some Rexx scripts to manipulate sound list binary files exported from Rasmus' soundlistripper. I ran into a few problems here and there, and found these problems were mostly due to my experience in ARexx, Amiga REXX, which has some differences compared to various Rexx interpreters. To demonstrate my lacking in "standard" Rexx I went back to basics and wrote a simple dump program.

This is also where the statement OPTIONS AREXX_BIFS AREXX_SEMANTICS comes into play.

This requires the latest Regina Rexx (3.9.1 at the time of this writing.) In particular because earlier versions (not sure where the cut-off is, but for certain 3.7) seem to only allow a stream of around 1.5k bytes. The Regina manual states the limit on a single line with READLN() in ARexx is 1,000 characters, while the rest can be read via READCH() or additional READLN(), but I found some sources which indicate a maximum of 64k bytes. In any case, there was definitely a limitation on Win64 reading some long sound lists via READCH() which was resolved by upgrading from Regina 3.7 to 3.9.1.

I had to make some other adjustments to get my ARexx-fu to work in Regina, but at least now it does work and I can go back to the larger manipulation program and fix my stuff. (For one thing, I need to make the program more modular and have just a single section for input and output rather than in each manipulation.✝)

If you have .rexx associated with Regina and Regina is in your PATH, you can execute the script below like this:

sound_list_dump.rexx filename

The input file is a raw binary dump of an ISR sound list, the output is 9900 assembler BYTE statements representing the contents of binary, one statement per row. This does no checking on the content of the file other than watching for a duration of "0" which indicates the end of a sound list. So unpredictable results occur if you feed it something else.

/*   sound_list_dump.rexx   *//* Basic ISR sound list format:  numbytes (byte)    Number of command bytes to follow    ...cmd bytes...    Fed directly to the TMS-9918 sound chip duration (byte)    Duration of command-set in jiffies (1/60th second)*/OPTIONS AREXX_BIFS AREXX_SEMANTICSparse arg filenameif ~open('sound_list_source', filename, 'r') then exit 30 /* also catches missing filename */row = 0do until eof('sound_list_source')    /* load sound list binary */   row = row + 1     num_bytes=readch('sound_list_source', 1)  /* first byte, number of bytes */        sound_list.row = num_bytes || readch('sound_list_source', c2d(num_bytes) + 1) /* extra byte is duration */   duration = right(sound_list.row, 1)  /* check duration for end-of-list marker */   if c2d(duration) == 0 then leaveendsound_list.0 = row      /* use stem var to store its own number of tails */say 'Sound list decode:'call close 'sound_list_source'do row = 1 to sound_list.0     /* decode sound list in compound variable */   call writech 'STDOUT', 'BYTE >' || c2x(substr(sound_list.row, 1, 1))   do byte = 2 to length(sound_list.row)      call writech 'STDOUT', ',>' || c2x(substr(sound_list.row, byte, 1))   end   call writeln 'STDOUT', ''     /* newline */endexit 0

✝ The last update I made to this post includes changes to use a stem or compound variable, which is essentially an array, to store the loaded sound list. This make manipulations far easier. For instance, swapping or copying channels, changing tone frequencies, changing channel attenuation, etc. As well, I made changes to the way I was calling WRITELN() and WRITECH(). I had not used these in ARexx so I was not following a proper convention, calling them as functions. Using CALL corrects this.