UK Vintage Radio Repair and Restoration Powered By Google Custom Search Vintage Radio and TV 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.

Closed Thread
 
Thread Tools
Old 1st Jul 2020, 5:36 pm   #101
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
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:	77
Size:	121.2 KB
ID:	210040Click image for larger version

Name:	SCIOSkeyboard.png
Views:	101
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  
Old 1st Jul 2020, 6:41 pm   #102
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
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 offline  
Old 1st Jul 2020, 6:54 pm   #103
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
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  
Old 1st Jul 2020, 7:26 pm   #104
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
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 offline  
Old 1st Jul 2020, 7:35 pm   #105
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
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  
Old 6th Aug 2020, 7:56 pm   #106
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Mk14 vdu

Up and running on this again, first test with the MK14 VDU pointed at the 'new' RAM area 0200-03FF. The simplest possible indicative test, I just linked it into graphics mode and typed the ASCII codes for '0200' into 0x200-0x203 and the ASCII codes for '0300' into 0x300-0x303, followed in both cases by some trailing spaces (0x20).

To display 0200-03FF the page selects etc need to be configured as follows:

B9 - connected to B17 'top page'
B10 = 1
B11 = 0
B12 = 0

Also B15 (swap pages) = 0

As we know, B17 (top page) is high when the upper half of the screen is being rendered and low when the lower half of the screen is being rendered. If we don't alter anything else, this means that RAM area 0300-03FF is displayed on the upper half of the screen and RAM area 0200-02FF is displayed on the lower half of the screen.

This in turn leads to an awkward break in the run of addresses as we go from the upper half of the screen to the lower half or vice versa. It would make drawing anything like a line or a sprite which happens to cross or straddle the centre of the screen unnecessarily complicated. What we really want is for the screen addresses to flow in one continuous run from left to right going across and from top to bottom going down.

Fortunately there is a way to make this happen - just set 'swap pages' (b15) = 0 and the contents of locations 0200-02FF are then displayed in the upper half of the screen and 0300-03FF in the lower half of the screen. I propose that this should always be the default B15 setting for any new software which uses the 'new' RAM at 0200-07FF as screen RAM.

Here's the VDU displaying 0200-03FF. If the letters look a bit grainy, it is because the (mono) image is being displayed on a colour CRT screen.
Attached Thumbnails
Click image for larger version

Name:	VDU_0200_03FF.jpg
Views:	115
Size:	111.9 KB
ID:	212867  
SiriusHardware is offline  
Old 6th Aug 2020, 8:05 pm   #107
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

Excellent work - I am hoping to have time this weekend to look at my RAM expansion as well... getting exciting.
Timbucus is offline  
Old 6th Aug 2020, 8:32 pm   #108
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Mk14 vdu

Quote:
Originally Posted by SiriusHardware View Post
just linked it into graphics mode
Duh, I meant 'linked it into character mode', of course. Yes, I hope you do manage to get some RAM running in the memory hole over the weekend.

That's when things usually accelerate, when you get directly involved.
SiriusHardware is offline  
Old 6th Aug 2020, 11:35 pm   #109
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Mk14 vdu

Played a little bit more before putting everything away. Two Image files loaded into 0200- onwards for the VDU to display. These are off-screen shots.

The second image is the mysterious image referred to back in #82. Shamelessly ripped off from similar, earlier, better efforts by Tim and Karen, of course.

I'm not too sure what's causing the 'jail bars', vertical black lines marking the boundary between one screen memory byte and the next. Also the spurious white bits above left and below left of the logo in the second image. They were present when the display was being rendered from the onboard RAM so it's nothing to do with the new RAM add-on.

I'm hoping both of these are caused by the composite-in on the monitor objecting to the lack of a back porch signal on the video output signal, next time I try this I will bring down my proper mono portable TV to see if the artefacts are still there on the image displayed on that.

I've also stumbled across quite a bad little bug in my send14 uploader script - Intel Hex lines with a checksum value of '00' at the end of the line will not load. Amazing this has never come up before.

I already know what it is, I'll ask for the Pi-uploader thread to be re-opened and post a fixed copy of send14.py there. I'll also detail the fix so that anyone who has heavily customised theirs for timing values, extra features, etc, can just fix theirs.
Attached Thumbnails
Click image for larger version

Name:	Clive_From_VDU.jpg
Views:	121
Size:	82.0 KB
ID:	212878   Click image for larger version

Name:	SCMP_From.VDU.jpg
Views:	95
Size:	42.6 KB
ID:	212879  
SiriusHardware is offline  
Old 7th Aug 2020, 8:55 am   #110
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

They look great I really want to get on with mine.

I think I have experience that bug once or twice as I have had assembled files that will not upload - I change a byte to something else and it works. As it has been when I am developing that has not been an issue so I never looked very closely at it!
Timbucus is offline  
Old 7th Aug 2020, 9:01 am   #111
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Mk14 vdu

I've put the 'DIY' fix in DA52's thread for his Arduino version of the uploader, it's very straightforward, just swap two lines around. I'll edit both versions and post the fixed versions to their respective threads. May take me a day or two.
SiriusHardware is offline  
Old 7th Aug 2020, 6:08 pm   #112
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Mk14 vdu

Probably jumping the gun a bit, but if you do get your RAM add-on up and running and working with the VDU, here are the image files of the two images in #109.

These are Intel Hex files with embedded line addresses so the uploader will automatically 'type' the code directly into the screen RAM at 0x200 onwards. You just need to have the VDU pointed at that area of RAM, as outlined in #106.

The files contain no executable code, so you will have to set the VDU control line states in whatever way you usually use to do that.

One of these files has a line with a checksum byte='00', that's how I discovered the checksum bug, so you will need to fix the script before the uploader will upload it.

Funnily enough the uploader had no problem uploading the exact same image to 0F00-0FFF and 0B00-0BFF, but that was because the load addresses were different, and the load address is included in the checksum - so the checksum was different.
Attached Files
File Type: zip VDU_Images_0x200.zip (1.3 KB, 77 views)
SiriusHardware is offline  
Old 7th Aug 2020, 7:03 pm   #113
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: Mk14 vdu

I'd love a SC/MP inside T-shirt
Slothie is offline  
Old 8th Aug 2020, 1:30 am   #114
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 vdu

Quote:
Karen could probably replicate the whole SOC VDU with a single PIC chip if asked nicely. Direct video output from PICs is something of a speciality for her.
I'm kinda coming around to the idea of trying that!

I have some practical experience of using the SC/MP NENIN signal now, and I feel confident I can replicate the SOC VDU functionality, perhaps on a single PIC!

Or am I too late to the party

I have no Mk14 to test it on but I'm sure I can lash up something...
Karen O is offline  
Old 8th Aug 2020, 1:31 am   #115
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Mk14 vdu

I'm sure there are companies who will print whatever design you want onto a T-shirt, maybe borrow a higher resolution version of the logo from Tim or Karen?

Perhaps we should all get one made? If we ever all went somewhere together we might get mistaken for a stag / hen party though...

Karen, don't let us stop you from making a one-chip VDU. The character generator presents a particular problem for anyone who aspires to build the real thing, there aren't very many left, so if you can reproduce all of that in software, that would be a much better alternative.

Last edited by SiriusHardware; 8th Aug 2020 at 1:40 am.
SiriusHardware is offline  
Old 8th Aug 2020, 1:25 pm   #116
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 vdu

I've had a little rummage and I think I have the parts to build a functional Mk14!

I'd use EPROM for SCIOS, I've got some display latches etc. I could arrange that all non-ROM, non-keyboard memory is RAM - Mk14-MAX!

Add: PIC fast loader and PIC VDU!
Karen O is offline  
Old 8th Aug 2020, 1:44 pm   #117
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Mk14 vdu

Ian has several of his 'issue VI' replica PCBs with their nice rear edge connectivity just itching to be built into working machines, seriously frustrating for him that most of them are in a lockup he can't get to at the moment.

If you do build one from scratch remember to knock out the unwanted ROM images at 0200-07FF (as was finally done on the original issue V) and map RAM into that space.
SiriusHardware is offline  
Old 8th Aug 2020, 2:56 pm   #118
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: Mk14 vdu

Quote:
Originally Posted by Karen O View Post
I've had a little rummage and I think I have the parts to build a functional Mk14!

I'd use EPROM for SCIOS, I've got some display latches etc. I could arrange that all non-ROM, non-keyboard memory is RAM - Mk14-MAX!

Add: PIC fast loader and PIC VDU!
A functional MK14 made with more modern components could be made easily on perf board. A replica is harder because of PROMS and old RAM chips that are hard to get and objectively not worth the money when you can get 1000 times bigger ones for half
the price!

If Karen really wants one I can send the spare 'black' board I have to her, I'm not going to be able to use it untill I get access to my lockup with all my components and the other 5 spare boards I have...!

I'd certainly be interested in a PIC version of the VDU. I have seen character generators on eBay for ~£15 so theyre out there, but for how long? Emulating dissapearing hardware at least preserves the heritage somewhat. Even some TTL is fast disappearing.
Slothie is offline  
Old 8th Aug 2020, 7:09 pm   #119
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Mk14 vdu

I think Karen originally did own an MK14, so she might possibly like the idea of owning one again for old time's sake.

I picked up four DM74S571 PROMs recently, as yet unprogrammed, I'd be happy to programme a pair and let them go to a good home in what would undoubtedly be a good cause.

The RAM, though, yes, that's a headache. The AM9111 equivalent can be found for around $6 stateside which is not bad but by the time you have been hammered for carriage, duty, and then charged for having to pay duty you can end up paying around £50 for your four RAM ICs - pretty much what happened to me.

Your issue VI is uniquely suitable for use in another compromise arrangement, leave the PROMs and the RAM off the main board and plug a PCB or veroboard into the rear edge connector. On there, put a modern ROM, RAM, and address decoding designed to make the modern devices appear in the appropriate places in the memory map. This was actually your suggestion originally.

With that compromise the only 'awkward' ICs to find are the 'original' 7408s and the 8154, if that is required. (A portion of the big RAM device on the extension PCB could be mapped into the I/O RAM area, so you'd have the RAM even if you didn't have the ports).

Taking things a stage further, if you are going to plug a PCB bearing ROM, RAM and address decoding into the rear end of the Issue VI PCB then it might as well have a VDU (PIC style) on it as well.

The nice thing about this compromise is that it is non-destructive - the main issue VI PCB does not need to be modified in any way at all, so one could always adopt this approach and, over time, and when parts come up at reasonable prices, gather the necessary components to fully populate the main PCB and make it into a stand-alone replica.
SiriusHardware is offline  
Old 8th Aug 2020, 7:46 pm   #120
Mark1960
Octode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,265
Default Re: Mk14 vdu

It may be worth trying utsource for AM9111BPC. I ordered a set of 10 in March, two of them running in my MK14.

Markings are similar to those on my original no longer working ram chips. Shows both AM9111BPC and P2111A-4, but a later date code.

My order history is now showing them as utsource certified used, but they looked unused.

Utsource are now showing utsource certified original parts date code 78, so may be worth a try.
Mark1960 is offline  
Closed Thread

Thread Tools



All times are GMT +1. The time now is 12:12 am.


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 - 2024, vBulletin Solutions, Inc.
Copyright ©2002 - 2023, Paul Stenning.