17th Oct 2020, 7:15 pm | #441 | |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: Mk14 vdu
Quote:
Assuming that's OK, duff crystal? Try any other crystal in the right ball park area (12MHz, etc) just to see if that creates activity on NENIN, NRDS, and A0-A7 and video-out all of which should be very active with just 5V power on the board and VDU_ON held low. I can't see (detail again lost) if your chip is an 877 or an 877A (mine is 877A). Also my 'build' has the full 'proper' reset circuit on pin 1 _MCLR because it was already there anyway, but Karen's prototype obviously worked with just the simple resistor pullup on _MCLR. If you were putting your scope on the crystal itself to see if it is oscillating remember that doing that will ironically sometimes stop the oscillator especially if the probe is on X1 rather than X10. Looking for activity on NENIN, etc is a better way to determine whether the clock is running. Last edited by SiriusHardware; 17th Oct 2020 at 7:27 pm. |
|
17th Oct 2020, 7:26 pm | #442 | |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: Mk14 vdu
Quote:
The 15uS delay might just be a by-product of how the SOC VDU goes about doing what it does, or it might be necessary for correct operation of the VDU but that would seem to go against what was observed earlier, that NENOUT seems to go high no later than ~130nS after NENIN does, seeming to suggest that the VDU is clear to have a look at the buses from that point on. |
|
17th Oct 2020, 7:30 pm | #443 | |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: Mk14 vdu
Quote:
If you're probing the clock, use pin 14 (OSC2) as that is the buffered output - probing pin 13 (OSC1) will stop the oscillator. Make sure the cap is near ro the chip and the strip is broken completely after so the veroboard isn't being a extra capactor! I know I'm stating the obvious but lets just say I found that out the hard way..... |
|
17th Oct 2020, 7:35 pm | #444 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: Mk14 vdu
I made the 3K0 resistor for the video output using a 2K7+330R - it seems to have forgiven me for the extra 30R. I did think that as Karen had specified 3K0 and not a much more easily found 2K7 or 3K3, the ratio of the value of that resistor to the others must be desirable, if not essential.
None of which would stop the project working altogether. |
17th Oct 2020, 7:36 pm | #445 |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: Mk14 vdu
|
17th Oct 2020, 7:37 pm | #446 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: Mk14 vdu
Yes, that seems to be becoming its name, although I thought Karen might like the ultimate privilege of naming it.
|
18th Oct 2020, 10:35 am | #447 | |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
Quote:
|
|
18th Oct 2020, 10:45 am | #448 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: Mk14 vdu
I'm just about to go out for the day, but I will scope NENIN vs. NADS when I get back at teatime. Let me know if there's anything else you want looked at while I have it up on the ramps.
|
18th Oct 2020, 1:34 pm | #449 | ||
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
Re: Mk14 vdu
Quote:
After our discussion on the A variation I should have spotted all mine are not the A variant - the 887's I bought we were originally going to use of course would have been fine - I just didn't think. Will be a few days but, I have some on order... which it seems may have been a bit premature... I was going to see if I could juggle the xtal /swap it to get it closer to the chip (Slothie's idea). I obviously built it direct from circuit starting at PIN 1 not to miss anything so it was 5 holes out by the time I got to those pins. It is however cut just beyond the shorted to ground commons on the CAPS. While looking I also examined the cut as Sirius suggested it was not clear in the photo. There was a clear cut but, there was some flux in there, I also ran a scalpel along every inter track area as well and I also cut the copper immediately after the chip pin to remove those three extra floating holes on each clock leg (bearing in mind Slothie's idea) as I only cut the center line to allow connections underneath. All of these could have contributed capacitance. So I thought nothing to lose and used a clip to short Video OFF and hooked up a bench 5V to the bare board... I have some video of the patterns as it is quite pretty... Sure enough on the scope I now had NENIN pulsing low on a regular pattern and CLKOUT had a nice steady clock... I hadn't noticed the original video stage sketch was a 3K and the final circuit a 2.7K so I dug out an extra 270 in series to go higher rather than relying on lower but, so far the 2.4K seems fine and I have no line at the left as you do on this TV at least although that may not be related. So I connected it up still shorting VDU ON/OFF with a clip - the MK14 has the pulsing display that Sirius mentions and I have the random graphics I get with the full replica VDU... Using this manual ON/OFF method I have got this far now... Which is just repeating one half of the image so I need to get the page swaps running as I only have base ram of course in this configuration. Thanks for all the support and suggestions from everyone - I will now work on making sure the board is wired the same as my full replica and test TOP PAGE switching the bank. But my initial thought is that Video ON/OFF is inverted on this board so my scripts are turning it OFF and it is of course OFF by default on power on which is different to the full replica VDU. Which means it was possibly the clock circuit but was definitely rushing to hook it up instead of following a simpler test step with a jumper wire... and it is probably not the A type Chips... but, stock never goes to waste... |
||
18th Oct 2020, 4:56 pm | #450 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
Re: Mk14 vdu
So a bit more followup and findings:
It was my mistake with the ON/OFF - earlier posts in this thread mention not connecting the ON/OFF to the INS8154 directly but, to use a Flag (I said 2 but it is actually 1 as that is what the manual recommends...): Interestingly this is the source of the 6% quote as well - I really need to re-read docs more often. So my final wiring is: Code:
Set Clear Name VDU Desc 810 800 PA0 b13 Video on/off (the manual recommends FLAG1 so could be that instead - I have) 811 801 PA1 b11 PS3 (BEST Not connected for Base memory Use - wired to b17 Top Page) 812 802 PA2 b10 PS2 813 803 PA3 b8 Reverse Pages - as b15 is INTR - it should be re-routed here i.e. connected to b8 814 804 PA4 b9 PS1 815 805 PA5 b12 PS4 816 806 PA6 b14 Graphics/Text - when 0 is text 817 807 PA7 b16 Invert video Anyway the Top Page does not work unfortunately in either #352 or #392 firmware - I have the same effect as Sirius with #392 of improved Segments but, flickering data beyond the first line or so. Here is why, the replica SOC VDU shows Top Page Low for a long duration - the manual says High on the top page but, it it seems it is better described as held high except for the duration of the bottom page. The PIC14 OrtonView just pulses it briefly - hopefully this is a simple fix in the firmware. With the older firmware I can get the falling man running and it looks lovely... I will fix the video one day as I wanted it in landscape... https://youtu.be/WtM1NE_v-ck So still to test: INVERT REVERSE PAGES ...and help find out what is causing the flickering... |
18th Oct 2020, 5:33 pm | #451 | |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: Mk14 vdu
Quote:
|
|
18th Oct 2020, 9:29 pm | #452 | ||
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
Re: Mk14 vdu
Quote:
In my experiments I think I have fried my First PIC chip or at least one PIN on it the RC1 (pin 16) for graphics no longer responds. I wonder if that pin is ever an Output and it was up against the 8154 - probably more likely while modifying the board to allow a switch between PS3 on the 8154 and TOPPAGE so I can continue to try and get that working or at least use code to select the displayed memory page as some of my programs use different pages either B00 or F00. INVERT screen works fine but, I cannot really test REVERSE as I can only display the same page top and bottom - not sure why - Sirius have you displayed a full page? Maybe I have missed something. |
||
18th Oct 2020, 10:07 pm | #453 |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: Mk14 vdu
Sirius has shown the 2 images on the original firmware https://www.vintage-radio.net/forum/...&postcount=371 but I'm not sure about the optimised code.
|
18th Oct 2020, 10:12 pm | #454 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
Re: Mk14 vdu
Ah yes indeed. I think he is using expanded memory though as not sure how with the non contiguous B00 and F00 RAM in a base machine you can do that without using the TOPPAGE memory output to flip PS3 (A10). But, I must have another issue as I should at least see random data for the following section of screen I would think.
|
18th Oct 2020, 10:18 pm | #455 |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: Mk14 vdu
If the TOP pin doesnt work or you havent got it connected to on or P1..P4 then you will only see the same half page twice.
|
18th Oct 2020, 10:18 pm | #456 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: Mk14 vdu
I can't remember Reverse Pages not working on OrtonView but I will specifically check. I certainly have had full screen (512 byte) images showing. (#371, as Slothie pointed out). One thing which occurs to me is that if you somehow connected TOP PAGE to REVERSE PAGES then, certainly on the SOC VDU, it would result in the same 256-byte block being shown twice even if TOP PAGE was toggling the state of one of the PS1...PS4 lines.
I'm just about to set up to get the snapshot of NENIN + NADS from the MK14 + SOC VDU for Karen, will check the operation of REVERSE PAGES on OrtonView as well. The original VDU, being hardware, responds to the change of state of TOP PAGE half way down the screen in real time. It wasn't possible for Karen's code to respond in the same fashion mid-screen so right at the beginning of the frame, she samples PS1-PS4 and the VDU control inputs with TOP PAGE asserted and without TOP PAGE asserted. This allows her to know, in advance:- - The base memory addresses of the two 256-byte blocks from which the screen will be rendered - The mode in which to render the contents of both the upper and lower screens (Graphics or Characters?) - Whether the upper and lower screens should be swapped - Whether neither, just the upper, just the lower or both halves of the screen should be shown in inverse video. So don't be too concerned about the TOP PAGE signal from OrtonView looking substantially different to the TOP PAGE signal from the SOC VDU. |
18th Oct 2020, 11:17 pm | #457 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: Mk14 vdu
So first of all the info regarding NADS which Karen asked for:-
Not surprisingly the timing of NADS pulses can occur at any time before and up to and even including the actual moment when NENIN is asserted by the VDU because the VDU has no idea what the SC/MP is doing, so there is no minimum interval between any given occurrence of NADS and the assertion of NENIN. Image #1 captures first a 'normal' NENIN window where a NADS pulse has occurred and completed just before the NENIN pulse began. In this case NADS stayed high throughout the NENIN pulse as would be expected. Secondly, the image also captures the rarer case where NENIN was asserted when NADS already happened to be asserted. In this case something odd happens, NADS looks as though it goes tristate for the duration of the NENIN pulse. In either case there is a fixed delay of around 1.0-1.5 uS following the falling edge of NENIN, after which activity on NADS resumes. (image #2). |
19th Oct 2020, 12:11 am | #458 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: Mk14 vdu
For Tim: The attached images are off screen shots from OrtonView with the 'Inside' image loaded into 0F00-0FFF (upper half of screen) and 0B00-0BFF (lower half of screen). I'm (as always) struck by how beautifully clean and clear the video output from Karen's project is.
This was done with the program posted way back in #82 of this thread which loads the image, but temporarily parks the first three lines of the image in I/O RAM while the OS is busy using 0F00-0F11. It includes a little bit of executable code which, when all of the parts of the image have been loaded, blits the first part of the image into 0F00-onwards to complete the image. Finally, it puts the CPU into a loop to prevent the OS from resuming and corrupting the first two lines of the image. A reminder that the code does NOT include whatever it takes to set the control line states or the VDU-ON state. I just use Arduino-style pluggable jump leads to reconfigure mine. For the first of the two attached images the TOP PAGE / PS1-PS4 settings were: PS1 = 1 PS2 = 1 PS3 = TOP PAGE PS4 = 1 REVERSE PAGES = 1 With the above settings the contents of 0F00-0FFF are displayed on the top half of the screen and the contents of 0B00-0BFF are displayed on the lower half of the screen. For the second of the attached images, same as above, except REVERSE PAGES = 0. So on mine at least, REVERSE PAGES is working. Last edited by SiriusHardware; 19th Oct 2020 at 12:40 am. |
19th Oct 2020, 1:24 am | #459 | |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
|
Re: Mk14 vdu
Quote:
You would not believe what the fault was - after quite a bit of searching I finally disconnected my little switch I had added as part of making it the same as my replica VDU (switches PS3 between TOPPAGE and B11 (for 8154 control of the address) and it did not help but, I noticed TOPPAGE was grounded when direct connected to PS3 - PS3 it seems never went high. I suspected the pullup resistor and snipped it out - the strange bit is disconnected from the MK14 it tested fine at 10K but whenever connected it was testing low and dropping the 5V when powered - and this is just with a bit of wire waving in the air and a double check that there were no shorts to adjacent tracks or beyond the two cuts (duh)... ... anyway to cut a long story short opposite Pin 10 (RE2) on the vero is Pin 31 (GND) - there must have been a hairline bit of copper on the cut under the PIC that with all the manipulation to modify the board was acting as a nearly short to Ground... So I was not going nuts (I knew had seen both pages running at one point when I first tested) and was why my 8154 (removed for a while as I got a bit paranoid) manipulation could not now set PS3 high whatever I did... So the funny TOPPAGE signal was a red herring - it would have looked like that when it was working before my mods and was after cleaning the hairline short. ... and then it all went pear again as I soldered my switch back in and nothing again - this time the scope showed barely a 1V signal on TOPPAGE.... ...even when just flying as a loose lead not connected after unsoldering the switch again. I could not find anything obvious so put back in the other #392 equipped PIC with the fried Graphics select PIN - voila full 5v signal again and I can see two text pages. Again cutting the story short; I burned another PIC and it all works fine - looks like I damaged that 2nd PIC as well somehow. So had a game of TANKS and HORSESRACE to calm down - they run fine. I will keep the other two PICS for heavy testing as they offer some functionality at least and can probably have new firmware added to mess about with. |
|
19th Oct 2020, 1:42 am | #460 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
|
Re: Mk14 vdu
Well done finding that fault - are you saying that you had TANKS and HORSERACE running on OrtonView, then, perhaps with the loop delays reduced? If so that would be great news.
I have also remembered that the 'image' program posted in #82 still needs further modification to work on a setup where the VDU is controlled at least partly by the flag outputs. Any data manually typed into address 0FFF using the monitor is copied to the flag outputs, so the moment the uploader types in the last byte of the first half of the image, the flag outputs change to mirror the state of the bits in that byte, whatever they happen to be, and that depends entirely upon the image which is being uploaded. It so happens that in the 'inside' image the bits in that byte set the flags in the right state to turn your VDU on, but that is just pure luck. The 'image' program therefore needs one extra tweak so that it does not load the byte destined for address 0FFF into that address initially, instead it needs to put that temporarily into I/O RAM until all of the image has been loaded in, then the executable code which blits the first three lines back into place also needs to copy that one byte from wherever it has been temporarily stored into 0FFF. |