UK Vintage Radio Repair and Restoration Discussion Forum - View Single Post

SiriusHardware · 12th Feb 2023, 2:56 pm

That's an interesting bit of info in and of itself because it implies that if you had typed in valid code filling the entire 'original' user RAM from 0F12 - 0FFF then the very act of trying to save it to cassette would damage several bytes towards the end of the code. I hadn't previously considered that.

I presume this also means that any code you attempt to load in using the fast loader can't include code to be loaded in over 0FF8, 0FF9, 0FFA otherwise it will 'break' the operation of the loader in mid-load.

My question would be, are there another three RAM bytes which would be more suitable to use?

Looking at an MK14 fully populated with 640 bytes of onboard RAM the areas available for user code are:

0F12-0FFF - (0F00-0F11 are used by the monitor)
0B00-0BFF
0880-08FF

It could be better to re-use three of the OS 'system variable' bytes at 0F00-0F11 for the simple reason that most existing user code avoids using those locations and indeed any code originally written with keypad injection loaders in mind has to avoid that RAM area because they use the OS to facilitate the upload, therefore the uploader must not overwrite those bytes during the load process. If there is an actual need to place code at 0F00-0F11 it has to be loaded into 'spare' RAM such as the 8154 RAM and then block copied into 0F00-0F11 after control has been handed over to the user program.

This restriction does not apply to the fast-loader which is entirely independent of the OS. Once you enter the start address of the fast loader and press 'Go' the SC/MP is entirely under the control of the fast loader and the OS is not using those reserved bytes, so they are momentarily free for use by the fast loader.

After the code has fast loaded, the loader either hands control over to the loaded program if it is an auto-run program, or restarts the monitor which of course re-initialises the contents of 0F00-0F11, so as far as I can see these bytes would be 'safe' for the fast loader to use and would free up 0FF8, 0FF9, 0FFA for user code, giving an uninterrupted run of usable RAM from 0F12-0FFF.

12th Feb 2023, 2:56 pm	#178
SiriusHardware Dekatron Join Date: Aug 2011 Location: Newcastle, Tyne and Wear, UK. Posts: 11,556	Re: Yet another MK14 tape interface (ESP32). That's an interesting bit of info in and of itself because it implies that if you had typed in valid code filling the entire 'original' user RAM from 0F12 - 0FFF then the very act of trying to save it to cassette would damage several bytes towards the end of the code. I hadn't previously considered that. I presume this also means that any code you attempt to load in using the fast loader can't include code to be loaded in over 0FF8, 0FF9, 0FFA otherwise it will 'break' the operation of the loader in mid-load. My question would be, are there another three RAM bytes which would be more suitable to use? Looking at an MK14 fully populated with 640 bytes of onboard RAM the areas available for user code are: 0F12-0FFF - (0F00-0F11 are used by the monitor) 0B00-0BFF 0880-08FF It could be better to re-use three of the OS 'system variable' bytes at 0F00-0F11 for the simple reason that most existing user code avoids using those locations and indeed any code originally written with keypad injection loaders in mind has to avoid that RAM area because they use the OS to facilitate the upload, therefore the uploader must not overwrite those bytes during the load process. If there is an actual need to place code at 0F00-0F11 it has to be loaded into 'spare' RAM such as the 8154 RAM and then block copied into 0F00-0F11 after control has been handed over to the user program. This restriction does not apply to the fast-loader which is entirely independent of the OS. Once you enter the start address of the fast loader and press 'Go' the SC/MP is entirely under the control of the fast loader and the OS is not using those reserved bytes, so they are momentarily free for use by the fast loader. After the code has fast loaded, the loader either hands control over to the loaded program if it is an auto-run program, or restarts the monitor which of course re-initialises the contents of 0F00-0F11, so as far as I can see these bytes would be 'safe' for the fast loader to use and would free up 0FF8, 0FF9, 0FFA for user code, giving an uninterrupted run of usable RAM from 0F12-0FFF.