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 16th Jun 2020, 9:18 pm   #81
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

I was trying to be clever and put them ready standing on a wall but, got distracted... it is great to see this working for you - have fun with the others - we need to collect anything we can find that is contemporary.
Timbucus is offline  
Old 16th Jun 2020, 10:32 pm   #82
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

I managed to disengage a bit sooner than expected so, here's something to try, my first attempt at loading and holding a full screen image on the VDU using only the original RAM (0F00-0FFF), extra RAM (0B00-0BFF) and I/O RAM (0880-08FF) - all three are needed.

The code does not include whatever is needed to switch the VDU off during loading and on again afterwards, you can either add that yourself or just manually disable the VDU with a wire link, upload the code (which auto runs) and re-enable the VDU with a wire link.

The .asm and .hex files are attached in a .zip file.

For the purposes of dramatic tension, I will not say what the image actually is.
Attached Files
File Type: zip image.zip (2.2 KB, 89 views)
SiriusHardware is online now  
Old 16th Jun 2020, 11:09 pm   #83
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

That is brilliant! I love it... and of course my sendv14 script disables the VDU while loading so it is a great surprise now everybody has to get a VDU card to see it...
Timbucus is offline  
Old 16th Jun 2020, 11:14 pm   #84
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

You do need to blit in the last 8 bytes as well as SCIOS uses them for variables so they corrupt... not that it notices until I studied the ASM
Timbucus is offline  
Old 16th Jun 2020, 11:18 pm   #85
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

I was hoping you would tell me if that happened for you. I wasn't sure if it was just the uploader sending spurious stuff at the end (I was using DeltaAlpha52's Arduino version of the uploader, which I have now built separately as an Arduino Uno 'shield').

I take it you are referring to the last line of the upper half of the screen. (0FFx). I noticed the right hand side of the image was getting 'damaged' right at the end.
SiriusHardware is online now  
Old 16th Jun 2020, 11:22 pm   #86
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

Posh - I must get around to building a HAT for my PI to make it neater to just clip on the side.

I have to ask how did you draw the graphic I was thinking of making up some kind of tool to convert and work on them. Although the ideal when we have 1.5K expansion will be an MK14 art package - we will need a light pen then...
Timbucus is offline  
Old 16th Jun 2020, 11:27 pm   #87
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

In Windows Paint, believe it or not, and then I used a very crude bit of Python code to rip the image from the saved .BMP file to .DB statements, which I then cut and pasted into the source file.
SiriusHardware is online now  
Old 16th Jun 2020, 11:55 pm   #88
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

Final thought -

DA52 didn't optimise his Arduino uploader for speed and neither did I (yet) so it works even when the VDU is enabled. I can therefore leave the VDU enabled and watch the image being built up on the screen as it loads and the corruption of the image seems to happen significantly after the 'blit' of the first three image lines to 0F00-0F17, immediately after which the CPU should go into a tight loop so the OS should not get the opportunity to run a wrecking ball through those pixels.

I wonder if this is something to do with the fact that some of the pointers and registers are apparently mapped or mirrored in the last few addresses of the 0FFx range.
SiriusHardware is online now  
Old 17th Jun 2020, 2:48 pm   #89
cmjones01
Nonode
 
Join Date: Oct 2008
Location: Warsaw, Poland and Cambridge, UK
Posts: 2,669
Default Re: Mk14 vdu

Quote:
Originally Posted by SiriusHardware View Post
Where's the character generator I wonder? Built into the 6847 perhaps?
Yes, the 6847 has a built-in character generator. It's quite distinctive for its sharply rectangular '0' digit, as seen on the Tandy CoCo, Dragon and Acorn Atom.

Chris
__________________
What's going on in the workshop? http://martin-jones.com/
cmjones01 is offline  
Old 17th Jun 2020, 7:18 pm   #90
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

Ah yes I have a flight of Dragon's here... very distinctive and a lovely keyboard.
Timbucus is offline  
Old 17th Jun 2020, 8:48 pm   #91
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

I tried out a Dragon on my first visit to the Centre For Computing History, yes, they do have a nice keyboard. Some friends picked one up when they were still contemporary but I had just bought an Atari ST and all my attention was focused on that, so I never really got to know the Dragon machines at the time.

Been busy with the easel again - this (attached, enlarged) 64 * 64 pixel image is not the image referred to in #82 above. I haven't yet converted it to .DB statements.
Attached Thumbnails
Click image for larger version

Name:	Clive_64by64Mono.jpg
Views:	166
Size:	30.4 KB
ID:	208721  
SiriusHardware is online now  
Old 17th Jun 2020, 9:01 pm   #92
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

Oh pretty - you are really good at this... puts the Apple I Steve Jobs demo to shame...

We bought a Dragon 32 just after the Spectrum I think with an FX80 printer to print manuals and do letters for the business... Had to teach mum to type 10 PRINT #-2,"Dear X"
Timbucus is offline  
Old 17th Jun 2020, 11:34 pm   #93
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

Well I think this is good enough to play now:

; MK14 MINEFIELD
;
; V.W. Morley of Staffordshire
;
; From Microbus - Practical Electronics June 1980
; Originally designed for the PE VDU
;
; Typed in from HEX listing disassembled and added a CLS
; and converted for SoC VDU by T.J.Gilberts May 2019
; Execute at 0F21 with a clear screen a minefield will be displayed. Pressing
; GO a second time sets in motion a tank, represented by 'X' moving to the
; mines. To jump and difuse a mine press the 'F' key at the right moment.
; BANG will appear if this fails and a new tank starts from the beginning.
; The number of tanks used 1-10 will be displayed - after 10 the program stops.
; Pressing GO twice then reloads the minefield and starts the game again, with
; the last BANG still displayed as the target to beat.

TJG has added some extras though so a failed jump will leave the unexploded ordnance to get past BAN@. If you can clear the minefield in under ten tanks then it now does not crash but, restarts a little faster - how fast can you go...

If you press F when it should be GO then ABORT,F,2,1,TERM,GO,GO to restart. If you just hold down F and think you have a clever hack... be warned it could all blow up on you...

Edit: It Autoruns with a PI Uploader so just press GO to start the tanks rolling
Attached Files
File Type: zip MineField.zip (2.4 KB, 120 views)
Timbucus is offline  
Old 17th Jun 2020, 11:56 pm   #94
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

Got it thanks, although I won't be able to test drive it properly for a little while because my issue VI PCB still does not have keys at the moment.

The green toppers arrived but I notice they have quite a high 'click force' - it so happens we have some items at work which need replacement 12mm tact switches so I have ordered enough to keep us going for a while - more than 20 in fact, and I have ordered ones with a relatively low click force.

We should get those in the next few days and then I will decide, on the basis of how those ones 'feel'. whether to use those or use the green top switches (with replacement black caps) after all.
SiriusHardware is online now  
Old 19th Jun 2020, 8:07 pm   #95
Mark1960
Octode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,264
Default Re: Mk14 vdu

Quote:
Originally Posted by SiriusHardware View Post
I'm certain you're right, otherwise if the uP was halted in mid-action it would probably have to rewind to the start of the action. It would be much more logical for the uP to notice the request for the buses, finish what it is doing, release the buses and then signal that they are available.
I was re-reading the datasheets for the sc/mpII again and noticed something interesting about the bus utilization on page 10.

Quote:
If NENIN is returned high during an input/output cycle, the input/output cycle is repeated when NENIN is again returned low.
I then went back and checked the original sc/mp spec again and found a similar description in Note 4 of Figure 4.

This could mean that the sc/mp was the first microprocessor to support bus transaction retry, which would be a requirement for virtual memory support, but only if some other processor or hardware was handling the memory management.
Mark1960 is online now  
Old 19th Jun 2020, 11:13 pm   #96
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

Interesting observation, Mark, thanks. Exactly the way I said it obviously wouldn't work.

Can't help but notice that you are in Canada, so I have to ask how a Canadian ended up having an MK14 (Original? Replica?) but it might be best to go into that in the 'MK14 schematic revisions' thread which now seems to be our 'Any general stuff about the MK14' thread. I note you are a relatively new user and currently subject to new-user moderation but that will wear off eventually after a few more posts. Nice to have another MK14 owner / driver here.

My issue VI finally has keys which makes playing games, on the whole, easier, so I fired it up and loaded up Tim's 2020 / For SOC VDU version of 'Minefield', see attached screen shot of the 'play area' of the screen below, with the XXX (Tank) rumbling towards the next mine (@).

The only change I had to make was to keep the 8154 in the default all-input mode as I am using wire jumpers to set the states of the page selects and the VDU on/off and graphics modes.
Attached Thumbnails
Click image for larger version

Name:	minefield.jpg
Views:	118
Size:	37.5 KB
ID:	208979  
SiriusHardware is online now  
Old 20th Jun 2020, 1:52 am   #97
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

If you fit the invert circuit that tank looks much better - I just checked the original hex dump in the magazine and it does have BIT 6 set so I think maybe the PE VDU supported this function as well - a quick read did not make it obvious but, it is getting late.

On Mark's point I wonder if that arose more because the SC/MP supported Multiprocessor operation out of the box but, as you say would easily allow virtual memory to establish page availability as well on exceptions.
Timbucus is offline  
Old 30th Jun 2020, 9:56 pm   #98
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default 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?
SiriusHardware is online now  
Old 30th Jun 2020, 11:17 pm   #99
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

That has been an interesting diversion for an hour - I struggled to work out what was happening - especially as I had not looked at your code and when I did to remove the auto run realised it did not have code to enable my VDU... just a comment where to put it... so how the hell did it work on auto-execute to display the picture when I ran it first time?

Well luckily the corruption which puts 0880 in the last two bytes means that the Status Register on GO allows Flag 2 to be reset for me. If the last byte of the image is changed to 0x84 (from 0x86) I can manually run it and the only corruption is that one bit not the entire end of that line...

I spent ages looking for a final Reset in send14 as the only way I could see how the VDU got re-enabled! I did take a quick look if I could spot why it happens but, my eyes are now bleary...
Timbucus is offline  
Old 1st Jul 2020, 9:24 am   #100
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Mk14 vdu

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.
SiriusHardware is online now  
Closed Thread

Thread Tools



All times are GMT +1. The time now is 6:27 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 - 2024, vBulletin Solutions, Inc.
Copyright ©2002 - 2023, Paul Stenning.