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

SiriusHardware · 6th Oct 2020, 7:08 pm

There is another outstanding issue in the send14 script, not as serious as the one mentioned above, but it needs fixing.

If there is an execution address in the code at address FFFE-FFFF, the code is automatically run from the address found after it has been loaded.

Problem: The execution address is also, as a unwanted side effect of the use of this feature, typed into addresses 0FFE and 0FFF. The reason this could be a problem is that when you type something into address 0FFF using the monitor (which the uploader does) a copy of that data is placed in the status register, several bits of which control the state of Flag 0, 1 and 2.

If you have something being controlled by the Flag outputs, i.e. the VDU or that Death Ray project you've been secretly working on, then unintentional modification of their state is undesirable.

There's a bit in the code which is supposed to recognise when the address in the line is 'FFFE' and it turns off writes to the MK14 for the rest of the line. I believe that bit is actually working.

However, there is another separate part of the code which keeps a running record of the last address advanced to during data entry.

If the last address advanced to equals the start address of the current line, the script just stays in data entry mode and carries on entering the data from the current line.

If the last address advanced to does not equal the start address of the current line, the script switches to address entry mode, enters the start address of the current line, changes back to data entry mode and carries on entering the data from the current line, starting at the new address.

I think this last feature is finding the start address=FFFE and comparing it with the last address advanced to - finding it is not the same, changing to address FFFE and entering the two data bytes from the line into xFFE and xFFF.

However, I haven't yet decided on the most elegant way to fix this. Making substantial changes to Python code can be a nightmare because of the way code blocks are denoted by indentation rather than by something sensible, like curly brackets.

6th Oct 2020, 7:08 pm	#15
SiriusHardware Dekatron Join Date: Aug 2011 Location: Newcastle, Tyne and Wear, UK. Posts: 11,586	Re: MK14 programming interface - Arduino version There is another outstanding issue in the send14 script, not as serious as the one mentioned above, but it needs fixing. If there is an execution address in the code at address FFFE-FFFF, the code is automatically run from the address found after it has been loaded. Problem: The execution address is also, as a unwanted side effect of the use of this feature, typed into addresses 0FFE and 0FFF. The reason this could be a problem is that when you type something into address 0FFF using the monitor (which the uploader does) a copy of that data is placed in the status register, several bits of which control the state of Flag 0, 1 and 2. If you have something being controlled by the Flag outputs, i.e. the VDU or that Death Ray project you've been secretly working on, then unintentional modification of their state is undesirable. There's a bit in the code which is supposed to recognise when the address in the line is 'FFFE' and it turns off writes to the MK14 for the rest of the line. I believe that bit is actually working. However, there is another separate part of the code which keeps a running record of the last address advanced to during data entry. If the last address advanced to equals the start address of the current line, the script just stays in data entry mode and carries on entering the data from the current line. If the last address advanced to does not equal the start address of the current line, the script switches to address entry mode, enters the start address of the current line, changes back to data entry mode and carries on entering the data from the current line, starting at the new address. I think this last feature is finding the start address=FFFE and comparing it with the last address advanced to - finding it is not the same, changing to address FFFE and entering the two data bytes from the line into xFFE and xFFF. However, I haven't yet decided on the most elegant way to fix this. Making substantial changes to Python code can be a nightmare because of the way code blocks are denoted by indentation rather than by something sensible, like curly brackets.