UK Vintage Radio Repair and Restoration Powered By Google Custom Search Vintage Radio Service Data

Go Back   UK Vintage Radio Repair and Restoration Discussion Forum > Specific Vintage Equipment > Vintage Computers

Notices

Vintage Computers Any vintage computer systems, calculators, video games etc., but with an emphasis on 1980s and earlier equipment.

Reply
 
Thread Tools
Old 1st Jul 2020, 5:36 pm   #101
Timbucus
Hexode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 388
Default Re: Mk14 vdu

Quote:
Originally Posted by SiriusHardware View Post
To be fair, I did state that you would need to add whatever makes your VDU 'go' in #82. I'll have another look at it tonight.
You did indeed I just can't believe the blind luck that the corruption made the value cause the picture to appear when I first ran it, so it did not when I tried the no auto run for you. I was genuine it was a diversion...

I even read the SoC manual again (V1 by accident) for the listing of SCIOS - have you ever noticed that it is still called SCMPKB and includes the original function of the keys that are mapped on the Novus Calculator they based the Keyboard kit on...

Click image for larger version

Name:	SCIOSisSCMBKBa.png
Views:	8
Size:	121.2 KB
ID:	210040Click image for larger version

Name:	SCIOSkeyboard.png
Views:	9
Size:	116.2 KB
ID:	210041

I note in the V2 manual the it was D.J.D (David Johnson-Davies) who did the adaptations (and of course all the program examples in both manuals except Serial In/Out and N.J.T. (Nick Toop) who did the Tape Routines...
Timbucus is offline   Reply With Quote
Old 1st Jul 2020, 6:41 pm   #102
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 4,245
Default Re: Mk14 vdu

I understand from something which the elusive 'circuitryboy' posted that the calculator is the reason for the odd key matrix used by the National Introkit and MK14, because the calculator chip used in the original calculator needed the key matrix laid out that way.

It may even account for the slightly odd canonical layout of the MK14 keypad connector connections, as it may have been laid out with the connections of the novus calculator keypad in mind.

Anyway... your experience with the VDU switching by writing to the last two locations is making it pretty clear that it is not possible to overwrite the location used for the status register without physically affecting the flags. It so happens that I am still using pluggable wire links and not the 8154 or the Flags for VDU control, so that is why this was not an issue for me.

I have to admit this didn't really occur to me but it seems as though the registers - P1, P2, A, E, Status, physically exist or are mirrored in locations 0FF9 onwards, like this:-

0FF9, 0FFA - Pointer 1
0FFB, 0FFC - Pointer 2
0FFD - A
0FFE - E
0FFF - S

Are these locations the actual physical registers or just shadow copies of them maintained in RAM by KITBUG? Because if this is the actual location of the registers then no wonder things go a little bit awry when I copy the image data over the top of them.

Obviously the way out of all of this is just to add the 1.5K memory expansion and point the VDU at that, then it will be straightforward to just load 512 consecutive bytes into the screen RAM without having to worry about it being trashed by anything else.
SiriusHardware is online now   Reply With Quote
Old 1st Jul 2020, 6:54 pm   #103
Timbucus
Hexode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 388
Default Re: Mk14 vdu

They are just copies that are the first thing SCiOS does when it goes in at START 0x22 (V2) that is the address in P3 when you do the XPPC P3 to go back - so if you have damaged it just set it but, becomes SCIOS version dependent.

They then get restored as is when it goes back out - so the last part of your picture is in P1,P2,A,E and S (for the bits that are reversible obviously) as you say the only one with a risk is the last one the Status register which will affect the Flags when SCIOS does the CAS - you would just need a small wrapper if you needed to use SCIOS which handled it setting the correct flags - not the end of the world - I.e. just set the last two bytes in your code to what you want in the picture and a sensible value as the last byte loaded for the flags...
Timbucus is offline   Reply With Quote
Old 1st Jul 2020, 7:26 pm   #104
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 4,245
Default Re: Mk14 vdu

So to fix your problem we need to exclude 0FFF from what is currently the 0F18-0FFF block upload and keep the byte which needs to go into 0FFF somewhere else until the system is under user program control where a write to 0FFF will be just that, a write to a memory location and not to the status register.

However this still doesn't explain my original problem, that of the execution address appearing in 0FFE-0FFF, only if the code has been auto-run. I don't know if you tried it, but if you don't have the program auto-run after upload and instead run it manually from 0880, there is no corruption of 0FFE-0FFF.

For each line of Intel Hex, the send14 script fetches the address from that line and first looks to see if the address is FFFE, if so it captures the first two data bytes from the line to use as the execution address after upload and then it sets the OutputMode variable to 0 (off) so that as it works through the rest of the line checksumming it as usual, no part of it, neither the address or data, is actually sent out to the MK14. It seems as though the script is somehow seeing this line as a normal line and therefore changing to address FFFE before starting to enter the data (2 bytes) from the line as it would for any other line of data.
SiriusHardware is online now   Reply With Quote
Old 1st Jul 2020, 7:35 pm   #105
Timbucus
Hexode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 388
Default Re: Mk14 vdu

Yes indeed I did try manually running it and you are correct there is no corruption and that meant I had a blank screen as at that time I had not added the enable code - which made me realise something was nuts as I could not see how it worked before - hence searching send14 for a reason like you but, suspecting an extra Reset at the end maybe before the execute - which of course would have corrupted the register area from 0FF9...

My python is not great (I am still trying to do a version of your send for the SCRUMPI on the serial port and struggling... ) so I could not see why it was happening either. It will be something simple and you will kick yourself.
Timbucus is offline   Reply With Quote
Reply

Thread Tools



All times are GMT +1. The time now is 6:26 pm.


All information and advice on this forum is subject to the WARNING AND DISCLAIMER located at https://www.vintage-radio.net/rules.html.
Failure to heed this warning may result in death or serious injury to yourself and/or others.


Powered by vBulletin®
Copyright ©2000 - 2020, vBulletin Solutions, Inc.
Copyright ©2002 - 2020, Paul Stenning.