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 17th Oct 2020, 7:15 pm   #441
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
Default Re: Mk14 vdu

Quote:
I have managed to assemble an OrtonView
Your images don't zoom very well after being savaged by the forum engine during uploading - regarding the two small capacitors associated with the crystal, I see a clear track cut between the pins of one but not such a clear cut between the pins of the other? Maybe just difficult to see on the image.

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.
SiriusHardware is offline  
Old 17th Oct 2020, 7:26 pm   #442
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
Default Re: Mk14 vdu

Quote:
Originally Posted by Slothie View Post
Am I correct in interpreting images #1 & 2 that its ~15uS between NENIN being pushed high and any attempt to read the data bus? I assume from image #1 that must be consistent across all frame lines.
Yes, it is about 15uS between VDU taking NENIN HIGH and then VDU taking NRDS low and scanning through the 16 addresses, reading from each one before releasing NRDS and NENIN.

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.
SiriusHardware is offline  
Old 17th Oct 2020, 7:30 pm   #443
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: Mk14 vdu

Quote:
Originally Posted by Timbucus View Post
Well the bits arrived Friday and with a 1am session last night and several hours late this afternoon I have managed to assemble an OrtonView

Attachment 218164Attachment 218165

Despite removing a whisker bridge dragging down one side of the Chip VSS and swapping two accidental fitted 27pf Caps for 22pf I still cannot get any oscillation. At least the MK14 runs with it attached so that is a start.

Tried another PIC as well in case I was unlucky - this is using the firmware from post #352 to start with.

Getting hungry now so I am going to knock it on the head and then triple check everything. I can find no shorts on the board. Lucky Sirius built his first or we would be wondering where the issue was.

The only other minor change I have had to make is RC5 pin 24 on the video out is 2.4K not 2.7K as my 2.7K packet had a roll of 470ohm resistors in it - ironic really as I ordered a roll of a 100 of them because I didn't have any for this build - when actually I didn't have any 2.7K... isn't electronics a fun hobby.
I shouldnt think the resistor is all that critical.
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.....
Slothie is offline  
Old 17th Oct 2020, 7:35 pm   #444
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
Default 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.
SiriusHardware is offline  
Old 17th Oct 2020, 7:36 pm   #445
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: Mk14 vdu

Quote:
Originally Posted by Timbucus View Post
Well the bits arrived Friday and with a 1am session last night and several hours late this afternoon I have managed to assemble an OrtonView
Nice to see my cunning plan is working
Slothie is offline  
Old 17th Oct 2020, 7:37 pm   #446
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
Default Re: Mk14 vdu

Yes, that seems to be becoming its name, although I thought Karen might like the ultimate privilege of naming it.
SiriusHardware is offline  
Old 18th Oct 2020, 10:35 am   #447
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: Mk14 vdu

Quote:
Using what as the SC/MP bus activity marker though... SC/MP NRDS?
NADS perhaps. NADS happens early for any bus cycle type.
Karen O is offline  
Old 18th Oct 2020, 10:45 am   #448
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
Default 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.
SiriusHardware is offline  
Old 18th Oct 2020, 1:34 pm   #449
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
Quote:
I have managed to assemble an OrtonView
Your images don't zoom very well after being savaged by the forum engine during uploading - regarding the two small capacitors associated with the crystal, I see a clear track cut between the pins of one but not such a clear cut between the pins of the other? Maybe just difficult to see on the image.

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.
I was looking for NENIN activity initially with the probe X10 setting on that I didn't notice (as it was a new probe from the packet) so spent ages looking for a voltage problem... In any case the CLKOUT was just static when looked at as well.

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...

Click image for larger version

Name:	IMG_4078.jpg
Views:	54
Size:	70.8 KB
ID:	218217Click image for larger version

Name:	IMG_4081.jpg
Views:	56
Size:	32.9 KB
ID:	218218

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...

Click image for larger version

Name:	IMG_4084.jpg
Views:	54
Size:	75.2 KB
ID:	218219

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...
Timbucus is offline  
Old 18th Oct 2020, 4:56 pm   #450
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default 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.

Click image for larger version

Name:	VDUconnections.png
Views:	42
Size:	199.5 KB
ID:	218246

Click image for larger version

Name:	VDUflag6pc.png
Views:	32
Size:	90.0 KB
ID:	218247

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
With PS3 disconnected I now get the top half of the memory as I would expect. Note that I think the intention of the extra 10K on the circuit on PS4 was to protect it when connected to Top Page but, the only really useful one and mentioned in the manual is PS3 actually to use it with base memory configuration so maybe best to move that - if we do a PCB version some config switches will be handy. I may retrofit to my Vero one.

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.

Click image for larger version

Name:	IMG_4093.jpg
Views:	40
Size:	66.3 KB
ID:	218248 Click image for larger version

Name:	IMG_4095.jpg
Views:	39
Size:	64.6 KB
ID:	218249

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...
Timbucus is offline  
Old 18th Oct 2020, 5:33 pm   #451
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: Mk14 vdu

Quote:
Originally Posted by Timbucus View Post
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.
If you continue reading the thread you'll see that due to timing constraints, at the beginning of the frame the config pins are read, the top pin is changed, and the config is read again. Then the memory addresses attributes etc for the top and bottom halves of the display are calculated and pre-fetched. This is because there isnt time to fetch and calculate this information half way down the screen without leaving a blank scan line between the halves.
Slothie is offline  
Old 18th Oct 2020, 9:29 pm   #452
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Mk14 vdu

Quote:
Originally Posted by Slothie View Post
Quote:
Originally Posted by Timbucus View Post
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.
If you continue reading the thread you'll see that due to timing constraints, at the beginning of the frame the config pins are read, the top pin is changed, and the config is read again. Then the memory addresses attributes etc for the top and bottom halves of the display are calculated and pre-fetched. This is because there isnt time to fetch and calculate this information half way down the screen without leaving a blank scan line between the halves.
Ah I had clocked there were issues but, did not realise it applied to the signal for when it is in the lower half of the screen which is needed to make a full screen display with a base machine.

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.
Timbucus is offline  
Old 18th Oct 2020, 10:07 pm   #453
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default 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.
Slothie is offline  
Old 18th Oct 2020, 10:12 pm   #454
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default 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.
Timbucus is offline  
Old 18th Oct 2020, 10:18 pm   #455
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default 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.
Slothie is offline  
Old 18th Oct 2020, 10:18 pm   #456
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
Default 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.
SiriusHardware is offline  
Old 18th Oct 2020, 11:17 pm   #457
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
Default 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).
Attached Thumbnails
Click image for larger version

Name:	SOC_VDU_NENIN_and_NADS.jpg
Views:	42
Size:	88.9 KB
ID:	218305   Click image for larger version

Name:	SOC_VDU_NENIN_falling_and_NADS.jpg
Views:	41
Size:	89.9 KB
ID:	218306  
SiriusHardware is offline  
Old 19th Oct 2020, 12:11 am   #458
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
Default 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.
Attached Thumbnails
Click image for larger version

Name:	Image_OrtonView_0F00-0FFF_and_0B00-0BFF_not_swapped.jpg
Views:	35
Size:	46.5 KB
ID:	218315   Click image for larger version

Name:	Image_OrtonView_0F00-0FFF_and_0B00-0BFF_swapped.jpg
Views:	23
Size:	60.0 KB
ID:	218316  

Last edited by SiriusHardware; 19th Oct 2020 at 12:40 am.
SiriusHardware is offline  
Old 19th Oct 2020, 1:24 am   #459
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
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.
Thank you so much for looking into this, I have been looking at it all night.

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.
Timbucus is offline  
Old 19th Oct 2020, 1:42 am   #460
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,485
Default 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.
SiriusHardware is offline  
Closed Thread

Thread Tools



All times are GMT +1. The time now is 1:49 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.