8-Bit Software Online Conversion

                In theory you must use CONTROL+BREAK to initialise a rom image after loading it into sideways ram. Roms pushed into your machine are initialised on power up. The problem is how to initialise a rom image from a !BOOT file. To load a Rom image you just put: *SRLOAD image 8000 6Q or whatever slot you want. The rom image will now load but not work as a hard break is required first. If you then perform a hard break and boot the disc in again using SHIFT+BREAK, you will find that the rom image is loaded in again and you are back to square one. One answer is to have a disc with the rom image, that you boot in first and then a second disc with the software that uses the rom image. So that you can first of all boot in the rom image and then perform a hard break. You can then boot in the second disc that will then load in the software etc that utilises that rom image. The problem with this is that it would be far simpler to have all the software and rom on one disc. When initialising a rom image the MOS does two things: 1. Reads the type byte from the rom image (seventh byte &8006). This byte is then saved into the vector table which begins at &2A1. The type byte is held at &2A1+rom slot number. 2. The rom is given a chance to claim any workspace that it may require. Any rom that does not need to claim workspace can be initialised very simply by inserting its type byte into the correct position into the vector table. So the !BOOT file could be set up to first of all load in the rom and then insert the correct type byte into the table. The !BOOT file could then carry on to load in any relevant software such as a menu. I hear you asking "how do I tell if a rom needs to claim workspace?" There is a very simple way and that is to just try it. Just like the advice I give to people that don't know whether their disc drive is single or double sided. Try and format side 2. So load in your rom image in the usual way and initialise it in the usual way using CONTROL+BREAK. Now type PRINT ?(673+slot number) I am using decimal here to make it easier for those of you that cannot add up in hex. The answer printed in response to this instruction is the type byte of the rom image. In future, you can now load in the rom image and try initialising it by typing: ?(&2A1+slot)=(whatever the number was) So a typical !BOOT file could be set up as follows: *BASIC *DIR $ *SRLOAD rom 8000 6Q ?&2A7=194 CHAIN"Menu" Another way to do this is to set up a !BOOT file that checks to see if a rom image is already loaded. If the image is there, then a menu is loaded. If not, then the image is loaded. This can be done very easily in a similar way to this: First look at the Rom table at &2A1 plus the slot offset to see if the type byte is already there. Then if the type byte is not there, load in the rom image. If the type byte is there then chain in the menu. That is the principle. In practice he disc is booted in the first time and the rom image loads. You then do a CONTROL+BREAK. You then !BOOT the disc in for a second time. This time the menu is chained and you are away with your game/application etc. The programming of the !BOOT file will go in a similar way to this: First of all find the type byte of your image in the same way as previously described (load in the image and examine the table at &2A1). Now you are ready to build your !BOOT file. Something like this: *BASIC *DIR $ IF ?&2A7=194 THEN CHAIN"Menu" ELSE OSCLI"SRLOAD rom 8000 6Q":PRINT"Now do a CONTROL+BREAK":END The number 194 there is the type byte that you earlier prized out of the table. That's it really, simple eh?    