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

SiriusHardware · 30th Jun 2020, 9:56 pm

Just had the MK14 and VDU back up and running in order to sort out the problem of the last two bytes of the 0F00-0FFF block being corrupted. The .asm is in #82 of this thread.

If you want to load a full screen 64 * 64 pixel image to the VDU and maintain it on the screen using only the standard, 'extra' and RAM I/O RAM, you can, sort of.

For the upper half of the image which will be in 0F00-0FFF there is a slight problem, as the OS uses 0F00-0F11 whenever it is accepting key presses and maintaining the display.

The approach adopted in the image.asm code, then, is to upload the first three lines of the image to RAM I/O memory at 08C0-onwards

The rest of the image data for the upper half of the screen is loaded into 0F18-0FFF

The image data for the lower half of the screen is loaded into 0B00-0BFF.

A short piece of actual code is loaded into the I/O RAM at 0880 onwards, and when run, it first shifts the data for the upper three lines of the display from 08CO to 0F00, overwriting the system variables, and then it puts the CPU into a loop to prevent it from returning to the OS, which would otherwise start using 0F00-0F11 again.

All of that nearly works except that when I try this, the last two bytes of the 0F00-0FFF block get corrupted somehow. I've now looked into this and the bit pattern left in 0FFE and 0FFF is 0880, which is the execution address of the shifter code.

If I remove the autorun segment from the .asm file and reassemble it so that the code only loads and does not auto-run, then manually run the code (0 8 8 0 Go) the top of the image is shifted into place and the two bytes at 0FFE and 0FFF do not get corrupted.

Autorun is invoked by including two bytes in the Intel Hex code at fictional addresses FFFE and FFFF, and the send14 python script, when it encounters this line of Intel Hex, is supposed to harvest the address and then continue working through the line without sending any key presses to the MK14 for the rest of the line. It signals this by setting variable OutputMode=0 when it finds data in the file at address FFFE-FFFF. I have a feeling this is not working and that the script is typing the execution address into FFFE and FFFF regardless which, due to the incomplete address decoding, maybe places it in 0FFE and 0FFF but if so, I can't fathom out what is causing this.

Tim, you noticed the slight corruption of the test image as well, if you get a moment can you comment out the autorun lines in image.asm, assemble it, upload it and manually run it from 0880 to see if you still get that little bit of corruption of the right hand side of the image?

30th Jun 2020, 9:56 pm	#98
SiriusHardware Dekatron Join Date: Aug 2011 Location: Newcastle, Tyne and Wear, UK. Posts: 11,586	Re: Mk14 vdu Just had the MK14 and VDU back up and running in order to sort out the problem of the last two bytes of the 0F00-0FFF block being corrupted. The .asm is in #82 of this thread. If you want to load a full screen 64 * 64 pixel image to the VDU and maintain it on the screen using only the standard, 'extra' and RAM I/O RAM, you can, sort of. For the upper half of the image which will be in 0F00-0FFF there is a slight problem, as the OS uses 0F00-0F11 whenever it is accepting key presses and maintaining the display. The approach adopted in the image.asm code, then, is to upload the first three lines of the image to RAM I/O memory at 08C0-onwards The rest of the image data for the upper half of the screen is loaded into 0F18-0FFF The image data for the lower half of the screen is loaded into 0B00-0BFF. A short piece of actual code is loaded into the I/O RAM at 0880 onwards, and when run, it first shifts the data for the upper three lines of the display from 08CO to 0F00, overwriting the system variables, and then it puts the CPU into a loop to prevent it from returning to the OS, which would otherwise start using 0F00-0F11 again. All of that nearly works except that when I try this, the last two bytes of the 0F00-0FFF block get corrupted somehow. I've now looked into this and the bit pattern left in 0FFE and 0FFF is 0880, which is the execution address of the shifter code. If I remove the autorun segment from the .asm file and reassemble it so that the code only loads and does not auto-run, then manually run the code (0 8 8 0 Go) the top of the image is shifted into place and the two bytes at 0FFE and 0FFF do not get corrupted. Autorun is invoked by including two bytes in the Intel Hex code at fictional addresses FFFE and FFFF, and the send14 python script, when it encounters this line of Intel Hex, is supposed to harvest the address and then continue working through the line without sending any key presses to the MK14 for the rest of the line. It signals this by setting variable OutputMode=0 when it finds data in the file at address FFFE-FFFF. I have a feeling this is not working and that the script is typing the execution address into FFFE and FFFF regardless which, due to the incomplete address decoding, maybe places it in 0FFE and 0FFF but if so, I can't fathom out what is causing this. Tim, you noticed the slight corruption of the test image as well, if you get a moment can you comment out the autorun lines in image.asm, assemble it, upload it and manually run it from 0880 to see if you still get that little bit of corruption of the right hand side of the image?