13th Oct 2020, 8:11 pm | #381 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
Re: Mk14 vdu
Oh - I like a mystery I need to build mine ASAP now... ordered the parts last night but, no sign of the ones I already had - maybe they were out of stock at the supplier . I had better order another one just in case from someone else...
|
13th Oct 2020, 8:46 pm | #382 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
I am very aware that my design falls a long way short on the 6% processor slowing specification. Ideally, every bus read would have its own NENIN assert/ drive buses/ read data/ release buses/ de-assert NENIN. There just aren't the PIC cycles to do this.
But there is an opportunity I can explore and I'll give some time to this when I feel up to it. I can't promise 6% slowing but I think I can do better than the current processor loading. I don't know if any interactive games were written for Mk14/VDU combination, but it would be a shame if these couldn't be adapted for my VDU due to the snails pace SC/MP. |
13th Oct 2020, 8:49 pm | #383 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
|
Re: Mk14 vdu
Hi Karen,
A little bit more info:- Image 1 - one frame of NENIN activity (PIC VDU) Image 2 - one frame of NENIN activity (SOC VDU) Image 3 - zoomed detail of SOC VDU NENIN activity The second image looked horrible at first sight but then I realised that if it looked like that it must be low (inactive) for at least as long as it is high, and so it proved when I zoomed in (image 3). Given the way the 'soft' VDU works it is hardly surprising if it has to spend more time on the bus than the original hardware VDU does. It is fantastic that it works as well as it does. |
13th Oct 2020, 8:57 pm | #384 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
|
Re: Mk14 vdu
To answer your other question, Tim has acquired a collection of software to run on the VDU, including one or two items which could be considered 'Video Games'. When I get a chance I'll try the 'Falling Man' animated demo on your PIC-VDU, if Tim doesn't beat me to it.
The problem is that historically, not many MK14 owners had a VDU (did you?) and those who did mostly only had the memory expanded to the 'full' 640 bytes, myself included, so it wasn't a great system to try to write games on given that the VDU ate up 512 bytes of that RAM leaving just 128 bytes to write a video game in. Several things which have come together now make it more likely that someone might write a new demo or game for the MK14. -Ian's replica PCB is the easiest ever to connect a VDU to, and it has the 'memory hole' at 0200-07FF which MK14s before issue V historically did not, at least not without modification. -Static RAM for making a memory expansion with is dirt cheap now, very expensive back in the day. -We have better / easier tools for developing code to run on the MK14 now, including your brilliant PIC14. -Anyone who doesn't have a SOC VDU can now build yours for a fraction of what it would cost to buy a genuine one or build a replica. Last edited by SiriusHardware; 13th Oct 2020 at 9:10 pm. |
13th Oct 2020, 9:07 pm | #385 | |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: Mk14 vdu
Quote:
|
|
14th Oct 2020, 12:05 am | #386 | ||
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
Re: Mk14 vdu
You have made amazing progress in such a short time - the fact that it just worked is a real achievement and makes a great addon for people to develop on for the MK14. Fine tuning will be great whatever cycles can be gained when you feel another surge of energy.
If I use this as the basis for the SCRUMPI 2.5 VDU circuit as I plan then that has its own RAM and some buffers on the BUS so would have less impact. Of course there isn't even the massive software base of; one animated demo (falling man), and three interactive games for that system like on the MK14 Did I even post Horse Race and Minefield yet here (which can both have their delay loop shortened!!!)? The other is not available publicly yet (pong https://www.youtube.com/watch?v=2hLAX2UUdpk watch this space when I get mine built they will be running ASAP. Quote:
|
||
14th Oct 2020, 12:37 am | #387 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
|
Re: Mk14 vdu
You did post Minefield, which I actually had running. Would it lend itself to a full screen version, I wonder? Can the three characters which form the tank be different? I was thinking that rather than XXX, something like [Q] might look a bit more like an overhead view of a tank, the 'Q' being the gun turret of course.
I think you also put Horse Race in a bundle but at the time I did not have a complete system to try it on - I should try it now that I have. |
14th Oct 2020, 2:05 am | #388 | |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
Quote:
I have observed that four inner-most subroutines feed the serial port with the background colour, both before and after the active text/graphics. There are some DELAY macro calls in these times, which could be pressed into service to turn on and off the bus. That would reclaim a decent amount of time for the processor. |
|
14th Oct 2020, 8:48 am | #389 | |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
|
Re: Mk14 vdu
Quote:
I suppose if you look at that bit of test code, generated frequency drops from 450Hz (without VDU) to 415Hz (With SOC VDU) that is a better indication of the slowdown introduced by the original VDU. Fun thought: I could try running 'Digital Clock' and seeing how much time it loses in ten minutes when each VDU is active. Does anyone have a version of that program re-timed for a 4.00MHz clock? |
|
14th Oct 2020, 8:57 am | #390 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
|
Re: Mk14 vdu
I make 415Hz about 92% of 450, so 8% difference? Not too far off the anecdotal 6%, I suppose.
|
14th Oct 2020, 9:23 am | #391 |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: Mk14 vdu
I was wondering that myself. Sirius's observed 8% doesn't allow much time for fetching from memory... there are 32*8 = 512 visible lines of which 50% of the time the memory is being accessed and the remaining 113 lines of which 0% of the time memory is being accessed, so the percentage should be 256/625 or a 40% slowdown if the processor is halted while NENIN is being pulled up.... I'm missing something here.
Unless the SC/MP is able to run in the background while NENIN is '1' only being held up when it needs memory access, but would that account for a factor of 5 if Sirius's program only accesses the memory for instruction fetches and the processor is able to limp on in the background, so to speak? If so Karen's proposal should provide an equivalent speed-up that might require Tim to keep his delay loops! |
14th Oct 2020, 3:53 pm | #392 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
I've tried to minimise time spent with NENIN asserted in the hope that the SC/MP runs faster. I've checked the code carefully but I would appreciate someone testing it on real hardware.
|
14th Oct 2020, 4:19 pm | #393 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
|
Re: Mk14 vdu
Happy to give it a test drive as soon as I get home, thanks Karen.
|
14th Oct 2020, 6:22 pm | #394 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
|
Re: Mk14 vdu
I have what I am calling V1.02 firmware in the PIC VDU now - On the one hand the display on the MK14 looks much more normal, but unfortunately operation of the VDU side of things is now 'broken'. The overall display is still steady but all of the characters (when in character mode) are flickering / changing rapidly all the time. If I change to graphics mode I notice that there seems to be a steady state pattern of pixels and a rapidly changing one being shown on alternate frames, as though there are two frame buffers and only one of them is having its contents randomly changed.
I take it that when tested with an EPROM as data source it still works, so it must be about the timing of NENIN which I assume is not involved with the EPROM in any way? Maybe if you connect NENIN to your test EPROM's _CE pin via an inverter (or just invert the polarity of NENIN in the firmware for the purposes of this test and connect it directly to EPROM _CE) you may be able to see the effect I am seeing, or something similar. If I revert back to firmware V1.01 it goes back to the way it was working before - as intended, but making the MK14 run quite slowly. |
14th Oct 2020, 9:20 pm | #395 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
That's disappointing
I used a rather crude test method: I put the 'scope in x-y mode, fed in NENIN and NRDS, then checked that negative excursions of NRDS are confined to when NENIN is high. Clearly, my margins are not wide enough somewhere... |
14th Oct 2020, 9:36 pm | #396 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
|
Re: Mk14 vdu
That's a nice 'guerilla' method of looking at the coincidence of the two.
It's a shame we didn't get one of Slothie's replicas to you a while back when we were musing over that possibility, I just know that if you had all of the actual hardware in front of you you would have this sorted in five minutes flat. It's going in the right direction, the fact that the 7-segment display on the MK14 reverted to more or less normal must mean that the MK14 got a considerable bite of the time cherry back after your mods to NENIN. There are, though, a few faint flickers of interference on the 7-segment display perhaps suggesting that both the PIC VDU and the SC/MP are overlapping, even if only slightly, when accessing the memory. |
15th Oct 2020, 8:15 am | #397 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
One serious obstacle is the lack of definitive timing information on NENIN. I find the SC/MP datasheet somewhat scant in this area, the implication being 'here's a feature, but you'll have to work it out for yourself'.
|
15th Oct 2020, 8:18 am | #398 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
SH, did you notice any pattern to the display corruption? The first line of text in each half, i.e. lines 1 and 16, are fetched separately from the rest. Are they stable or addled?
|
15th Oct 2020, 9:00 am | #399 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
|
Re: Mk14 vdu
I will run it up tonight and try to be more specific about the nature of the problem. This is what I mean when I say I wish you had a system to try yours on.
Given your inside knowledge of what the firmware does and when, You would instinctively understand what the problem is just from looking at it. |
15th Oct 2020, 11:10 am | #400 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
Thanks SH, and thanks for your faith in my diagnostic abilities. Unfortunately I don't share that faith I will do a more quantitive analysis of the current situation specifically:
1. How long after PIC bus release to NENIN high. 2. How long after NENIN low before the PIC starts to drive the bus. I will also look again at the SC/MP datasheet to see if any timing constraints surrounding NENIN can be established. Why do I feel like I'm talking about a long dead Russian dictator? Last edited by Karen O; 15th Oct 2020 at 11:12 am. Reason: Got sense of NENIN wrong |