16th Jun 2020, 9:18 pm | #81 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
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.
|
16th Jun 2020, 10:32 pm | #82 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
|
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. |
16th Jun 2020, 11:09 pm | #83 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
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...
|
16th Jun 2020, 11:14 pm | #84 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
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
|
16th Jun 2020, 11:18 pm | #85 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
|
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. |
16th Jun 2020, 11:22 pm | #86 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
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... |
16th Jun 2020, 11:27 pm | #87 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
|
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.
|
16th Jun 2020, 11:55 pm | #88 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
|
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. |
17th Jun 2020, 2:48 pm | #89 | |
Nonode
Join Date: Oct 2008
Location: Warsaw, Poland and Cambridge, UK
Posts: 2,669
|
Re: Mk14 vdu
Quote:
Chris
__________________
What's going on in the workshop? http://martin-jones.com/ |
|
17th Jun 2020, 7:18 pm | #90 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
Re: Mk14 vdu
Ah yes I have a flight of Dragon's here... very distinctive and a lovely keyboard.
|
17th Jun 2020, 8:48 pm | #91 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
|
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. |
17th Jun 2020, 9:01 pm | #92 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
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" |
17th Jun 2020, 11:34 pm | #93 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
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 |
17th Jun 2020, 11:56 pm | #94 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
|
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. |
19th Jun 2020, 8:07 pm | #95 | ||
Octode
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,264
|
Re: Mk14 vdu
Quote:
Quote:
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. |
||
19th Jun 2020, 11:13 pm | #96 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
|
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. |
20th Jun 2020, 1:52 am | #97 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
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. |
30th Jun 2020, 9:56 pm | #98 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
|
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? |
30th Jun 2020, 11:17 pm | #99 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
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... |
1st Jul 2020, 9:24 am | #100 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
|
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.
|