Another problem that had to be worked around was the use of indirect addressing through zero page registers. All of zero page is written over during the transfer process, so registers in that area can't be used as pointers. Again, self-modifying code had to be used to point to source and destination addresses for memory transferring. In theory, switching in and out the variables will allow multiprocessing. But, as usual, theory and practice do not see eye to eye. The main problem with multiprocessing using this technique shows up when it comes to editing in direct mode while also in multiprocess mode. Some characters typed on the keyboard will go to the screen you see, but others will go to the other environment, and will only show up when you switch over using the F3 key. Not good. What we need is a local keyboard as well as a local screen for each environment. In order to do that, a bit of mucking about with the kernal (operating system) is in order.
That's roughly how localized keyboards are accomplished, although there are a few more details involved which may be seen in the source code (listing 2). With the keyboard problem taken care of, it should work fine, right? Unfortunately, there are a few more problems which have to be solved to make AUTOSWAP useful.
Luckily, the C64 has the unusual capability of allowing ROM and RAM to exist in the same address space, and allowing either to be selected by software. This capability can be used to change the operating system in ROM: just copy the existing ROM into the underlying RAM, select the RAM and disable the ROM, then make changes to the RAM. With this technique we can change the operating system depending upon which environment we are in and which screen we are viewing. The problem with patching into the ROMs in this way is that the resulting code may not be compatible with all of the different ROM releases (there have been three that I know about for the 64 to date). AUTOSWAP works with the most common ROMs, not the early ones or the very late ones. I haven't tested it with other ROM versions, but if the program doesn't work on your machine, use a machine language monitor to check your ROMs against the ROM patch in the source listing (listing 2). The code at lines 4470-4540 should appear in the ROM starting at $EB34. You serious hackers out there should be able to find the equivalent patch locations for different ROM versions. We'd be glad to print these as a follow up in a future issue. If you do have different ROMs, you can still use AUTOSWAP: just delete lines 1730 to 1760 in the source listing, or make the indicated change in the basic loader program (listing I). This will disable the ROM patches; AUTOSWAP will still work, but typing in direct mode while in multiprocess mode will be problematic. To explain how each environment is given its own keyboard buffer, first consider all the different combinations of environments and screens: Environment I, screen Environment I, screen Environment 2, screen Environment 2, screen
I 2 I 2
Besides localizing the keyboard buffer, the STOP key must be handled independently as well. If a program is being worked with in environment I while another one is simultaneously running in 2, pressing STOP should only affect the program in environment I . This is taken care of by using the "check STOP key" vector to trap the stop, and ignore it unless the environment and screen are the same. A minor problem, easily fixed. It also means, though, that the new stop key code is being continuously executed; changing AUTOSWAP after it has been initialized could cause a system crash. Make sure to disable AUTOSWAP with a RUNSTOP/ RESTORE before doing any playing about with the code (like reassembling new source). Another problem that sadly has no easy fix is colour memory. Ideally, colour memory would be local to each environment just like screen memory. That would mean that switching environments, changing all the character colours on the screen, and switching back, would change nothing. Unfortunately, implementing such a scheme is a problem because colour memory must always start at the same address, $0800. The VIC video chip and the operating system in ROM both assume it to be there. The ROMs we could change, but the chip's memory addressing we couldn't- short of performing some major surgery to the circuitry inside the 64 (put down your soldering iron; we're not going to do it). So what to do about colour memory? Well, colour memory is not that important - AUTOSWAP will usually be used when editing and debugging programs, or for other primarily text applications where only one character colour is desired. We can't just ignore colour memory, however, because whenever the operating system clears a line of text on the screen, it fills the corresponding line in colour memory with the background colour. This behaviour varies with different ROM releases: If you can clear the screen on your machine, then see the effects of POKEing to screen memory, the problem doesn't exist, and you
To give a local keyboard to each environment, AUTOSWAP uses the following logic. If the environment and the screen are the same, then characters are sent to the keyboard buffer at $0277 as usual. If, however, the processor is in one environment, and the
The Transactor
screen being viewed is that of the other, then the characters are sent to the image of the keyboard buffer in the storage area for the processor's environment. For example, suppose that the CPU is in environment I , meaning that all the environment I parameters are occupying pages zero to four. At the same time, the screen being viewed (and thus the keyboard to be enabled) corresponds to the second environment. In this case, the interrupt routine, instead of putting the characters from the keyboard into the regular keyboard buffer, puts them into the storage area for environment 2. The next time the swap takes place, the storage area for environment 2 will be moved into pages 0-4, replacing the keyboard buffer. Thus. all keystrokes that took place while the CPU was in the non-visible environment will appear when it switches back to the visible one. It's pretty tricky, and again, makes the program a bit difficult to visualize, but this is a non-typical application, so programming must be done accordingly.
71
Volume 5, Issue 04