Coding is an art which can be heavily disturbed by insufficient tools, which cannot do what you want them to. This was the feeling the FairLight’ers have felt many times, while pushing our utilities to their outer limits.As the Assembler and the ML monitor are the utilities we use the most, we tried to improve them as much as possible. The main problem is that having the assembler, the source, music, data, graphics and so on on the memory makes you realise that 64Kb isn't all that much.
To overcome these limits you can produce an assembler porting the code through a cable (As Bonzai and Chromance did/do), but this requires an additional machine. It can aslo be done on another machine like an Amiga or a PC. Never the less, we all hate cables and we all hate not having enough room on the desks, don't we? The other way is to adapt the assembler into working with the 17XX expansion memories. This is the way we have chosen. XMem Ass is a system which removes all limits you've felt before in your coding deeds. The XMem Asm 3.3 is so far THE assembler for the C64.
XMem Ass features the same commands as the original TurboAssembler 5.2 (see that docments), but for the command "<-"+"p" (Protect). We've found this command not only unnecessary, but also truly stupid!! In practice it doesn't feature any protection, so why mess with it? Beware of early, unfixed, versions of the assembler. They might contain $33 as the EOR value. (Read more on the subject "eor protect" later on in this text!)
All memory commands are now directed to the expansionmemory, rather than the internal memory. So the fill, load, save, "<-"+"6" datafetch and all the others work on the bank selected. The assembler now uses two banks in the expansion memory, called objectbank (for all the data and the code) and one called the source bank, containing the source, a monitor (optional), the main assembler and the 17XX communication routines.Some new commands are supported: ("<-" and the following characters. Note that they are all shifted!)
| B | Select objectbank. Default is 1. |
| D | Select diskdevice (From 3.3) |
| H | Hunt for a specified label, NOT all the references to it. |
| M | Go to TronMon (17XX monitor) |
| P | Enter page for return routine. Default page in memory is $0800, but this is now changeable. |
Bankselect is for selecting which banks in the memory to use (default is recommended!). Default is bank 0 as source bank and bank 1 as object! Banks from 0 to 7 are supported (512 KB memory). None of the FairLight’ers have any bigger one, so we found no need for further expansions. Anyone with a 2 MB one that needs support?
New features from X-Mem Ass 3.3 are the ability to select your workdevice, to something else than 8. It took Tron and me (Bacchus) some time to hack all the hardcoded 8's, so we know why it wasn't done before on any version!
Page is the routine dumped into the object bank when you select "s" after assembling! When you start this routine, you will go back to the assembler! (The three bytes are NOP's, so it's OK to put it at $0800, even if the three first bytes get destroyed at a reset here. You only make it back 6 cycles faster by sys:ing 2051 ($0803)
More on TronMon in a special document REU operation
Since the computer cannot address the Expansion Memory as TRUE memory (thus, you can not LDA from it nor execute code in it) it is necessary to "flip" the source and object banks back and forth when switching between the assembler and the finished code. It works something like this :When you start editing the source, the assembler, source, x-mem routines (and monitor ?) resides in the c64's conventional RAM. It also exists as "a backup" in xmem bank 0.
Upon performing any memory-using action such as loading, saving, filling and assembling, all access is redirected to the Xmem, into the OBJECT bank (default is 1!).When starting your assembled program, the assembler will copy the RAM to the SOURCE bank (0) and then copy the OBJECT bank (def.1) into the RAM, and then start the program. None of these actions will be visible to you, as virtually nothing has changed, except for the memory redirection. It is necessary though to understand what actually happens to be able to comprehend the following.
Along together with your Object Bank, a "return" routine has been transferred. To return to the assembler, you simply start this routine with a SYS, JMP command or whatever. The routine uses 1 page of memory and resides at the page specified by using the "<-"+"P" (shift+p) command.
NMI is also automagically redirected to the "return" routine (Not on all versions!), so pressing RESTORE will also allow you to go back to the source bank. Once in the "return" routine, you will be prompted to specify what to do with the current RAM bank. The coded working here is the so called "return routine".
Pressing CR will send an copy of the current memory back into the OBJECT bank, and everything will appear as usual. You may want to save the memory to another bank, just to study the effects on the RAM after a crash or similar, without fucking the original object bank up. In this case just select a spare bank! This is one of the biggest advantages of using the XmemAss system. Both the source and object banks are safely protected inside the xmem. (Remember to assemble once so the source lands in bank 0). If something destroyed the whole contents of your standard 64 K RAM, you would still be able to get it all back by copying it back from the xmem. If the RAM is so badly mutilated that even the return routine has gone bonkers, you may load it from disk. On some disks it's called "!", on some "xass(!)" and again on others "obj.transfer". It might be handy to have this one available on your work disks!
Also the new main advantage: We had some trouble as Tron's first TurboAssembler was a 5.0 with the EOR code set to $33, and this wasn't found until MUCH later. Swapping sources got to be a pain in the arse, as we had removed the "<-"+"p" option and therefore had to convert them by loading some old and normal version of the assembler. I got fed up with this so I coded a EOR hacker. This program gave the correct EOR code for the file, if it had the tab set to $09 (99% of them have!). From this idea Tron built in his implementation of the same idea, but he did a more advanced one. (As usual, he wanted to brag ... =o) This new feature will AUTOMAGICALLY deprotect the source you load, and it will base it's guess of the EOR-code on the macro on F6 (99.9% have row delete here). You can see the EOR code used while loading! All saving will be done with a $00 EOR.
Also, the DIR routine is now also interruptible. Pressing R/S halts the output!