An Enhanced MK14 (MK14E)

[ChrisOddy]

Just tried running the VDU from its own 4MHz clock and it seems fine. So that's handy and means the CPU can remain on the 4.433 MHz crystal and timing e.g. for the cassette interface will be correct even with a VDU connected (of course the VDU will need to be disabled for the duration of a cassette operation).

[Mark1960]

With the vdu and 8060 not running on the same clock you might have issues with memory corruption. There are certain times in the 8060 memory write cycles where aborting the cycle using NENIN can cause the address to change before NWDS is deactivated. We were able to see the corruption in the display memory when running a tight loop writing to a lower memory address. In a 64k decoded system it might be causing spurious writes to some other memory address so it might not be obvious if there is a problem.

[ChrisOddy]

I must admit I had my doubts about the VDU working asynchronously given that it only drives NENIN and doesn't look at the control lines to see if the bus is actually available. So too dangerous to leave as an option and only really a 'nice to have' so I'll go back to a single crystal.

[Realtime]

I modified one of my RealView modules to run from a separate 10MHz clock and generate VGA video. The Mk14 is running at 4.43 (or is it 4) MHz with no problems. The key is to assert Nenin ahead of when the VDU needs to get access to the bus and allow any ongoing 8060 memory cycle enough time to complete. The maximum time needed depends on the instruction being executed and is stated in one of the SC/MP data books but is not very clear. I’d have to check the VHDL to determine the dead time that I allowed but I think it was around 3us. I’ve been using this for over a month with no memory corruptions.

There is another issue with the MK14 design that seems to get overlooked. Unlike other 8060 processor designs that I’ve seen, the MK 14 does not have pull up resistors on the nRDS and nWDS signals. This means that when the 8060 data and address busses float in between memory cycles (or indeed during the dead time of a Nenin cycle) so do the read and write signals. At that point all signals to RAM are undefined and could in theory cause spurious writes. I realise this doesn’t seem to cause a problem in reality but it’s really bad practice. I added these pull-ups on RealView to ensure RAM could not be falsely enabled.

[SiriusHardware]

I'd have to check but I think the MK14 VDU instructions specifically say to add a pullup on at least one of those lines.

[Mark1960]

Originally Posted by ChrisOddy

I must admit I had my doubts about the VDU working asynchronously given that it only drives NENIN and doesn't look at the control lines to see if the bus is actually available. So too dangerous to leave as an option and only really a 'nice to have' so I'll go back to a single crystal.

The ‘74 fix that we added to orton view would probably also work on the realview if you wanted to keep the option to run on different clocks.

[Mark1960]

Originally Posted by Realtime

I modified one of my RealView modules to run from a separate 10MHz clock and generate VGA video. The Mk14 is running at 4.43 (or is it 4) MHz with no problems. The key is to assert Nenin ahead of when the VDU needs to get access to the bus and allow any ongoing 8060 memory cycle enough time to complete. The maximum time needed depends on the instruction being executed and is stated in one of the SC/MP data books but is not very clear. I’d have to check the VHDL to determine the dead time that I allowed but I think it was around 3us. I’ve been using this for over a month with no memory corruptions.

There is another issue with the MK14 design that seems to get overlooked. Unlike other 8060 processor designs that I’ve seen, the MK 14 does not have pull up resistors on the nRDS and nWDS signals. This means that when the 8060 data and address busses float in between memory cycles (or indeed during the dead time of a Nenin cycle) so do the read and write signals. At that point all signals to RAM are undefined and could in theory cause spurious writes. I realise this doesn’t seem to cause a problem in reality but it’s really bad practice. I added these pull-ups on RealView to ensure RAM could not be falsely enabled.

The time taken to abort a memory cycle is not dependent on the instruction in progress. The memory cycle in progress will be aborted, not the instruction, and repeated when NENIN is released and the 8060 allowed to use the bus again. What does change is the way the address and NWDS behave, depending on when the NENIN is raised. At some points in the cycle raising NENIN will cause the address lines to change before the NWDS is pulled high.

[ChrisOddy]

I've found a scan of the Practical Electronics article which describes the mod to the MK14 VDU to invert individual characters (August 1980).

The method used is very simple, mine was a little more complicated and latches the data bit before inverting the output of the shift register.

The PE method is also using bit 6 rather than 7 (another link !) and is inverting when the bit is '0' which I would consider the wrong way around, surly a '0' should be a 'normal' video character for backwards compatibility ?

[SiriusHardware]

You would think so, but as with many things in the SOC / Sinclair world things are not always as you would expect.

Now you have a dilemma: follow what appears to be canonical practice, do it the way which makes more sense, or offer the choice of both.

Now you've raised this question I will have to look again at how RealView treats this issue because I can't remember having to set one of the high bits to make the VDU render characters as 'normal' white on black. I didn't play with it as much as I could have at first because Realtime identified some further issues with the original small batch, but he has since updated it for me and I need to clear the decks and make some time to take it out for a proper spin.

My SOC VDU is an original one, I wasn't aware of that character inversion mod back in the day and I wouldn't consider making any further mods to it now, therefore this issue has never come up for me before.

[SiriusHardware]

Of course you could take the easy way out and simply not have that feature. It wasn't part of the original SOC VDU feature set, and OrtonView, because it aimed to be an exact hardware emulator of the original VDU, doesn't support it either.

[ChrisOddy]

I want to check if I have the timing correct around the discrete character generator on my VDU ?

Would somebody that has a VDU with a real DM8678 character generator be able to check for me please ?

I have attached an image of part of a split graphics/character screen showing the transition between the two (b14 is tied to b17).

Graphics are groups of 8 pixels, characters run at twice the rate so two characters take up the same space as 8 graphics pixels. Characters though are only 5 pixels wide so there is a three pixel gap between characters.

Hopefully you can see in the photo that characters are starting one pixel later than graphics, so is that correct ?

[SiriusHardware]

I am away from base as I usually am at the weekend, but if nobody gets back to you sooner I will try to check that for you early next week.

[ChrisOddy]

That would be great thanks

[SiriusHardware]

Mr. Oddy. I've just set up my Issue VI and original SOC VDU for a quick test.

I had 'graph/char' connected to TOP PAGE and SWAP PAGE connected and not connected to TOP PAGE in order to display graphics on the top half and characters on the bottom half, and then characters on the top half and graphics on the bottom half.

With graphics upper, characters lower, there is a one pixel gap between the lowest pixels of the graphics area and the uppermost pixels of the first character line just as per your example image in #91.

With graphics lower, characters upper, there is NO gap between the lowest pixels of the last character line and the uppermost pixels in the graphics area. The lowest character line pixels butt up against the highest graphics line pixels.

One artefact of the original VDU you may not want to reproduce is the 'jail bar' effect which inserts a thin vertical gap between graphics mode bytes on the screen, as illustrated here in the attached image. On a real SOC VDU or clone, this effect is 'designed in'.

[Mark1960]

Hi Sirius, Chris was asking if the left edge of text is lined up with the left edge of graphics, or if there is a one pixel gap to the left of text.

[SiriusHardware]

Oh, B****. I wasn't paying attention was I? I'll set it all up again tonight and have another look at it.

[ChrisOddy]

Sorry Sirius maybe I didn't make it clear in my post but as Mark says its the lining up of the characters and graphics left to right that I'm trying to match. At the moment I can move the 'start' of a character to either the 1st or 2nd graphics pixel.

I wasn't aware of the jail bar problem so will look at that, looks like a timing issue with the graphics shift register, should be fixable. I've sorted inverted video as well as adding inverted characters.

Chris

[SiriusHardware]

You made it perfectly clear, I just didn't read your post properly (unlike Mark).

Just looked again, characters begin at one pixel further in compared to neigbouring graphics 'bricks' exactly as per your picture in #91. Definitely 1 pixel, not 2. I've never even noticed that offset before.

[ChrisOddy]

Thanks for doing that Sirius, I've now corrected my circuit so it works the same.

I can now see why the 'jail bars' are there - the clock for IC16 appears approx 50nS before Load so for that ~50nS an extra 0 gets clocked in at the start of a block of 8 graphic pixels and produces a thin black line.

I've also figured out why they probably used an 74L86. A mix of CMOS and TTL gating has been used after the main clock chain (IC6) and I think the 74L86 delay is used to balance some of the CMOS delays into the TTL gates ?

I need to pinch one of the 86's for somewhere else (character invert) so plan to replace the two IC1 74L86 'buffers' with 4050 buffers which are about the same delay (@5V) as a 74L86.
Then I will fit one or two 4050's in the clock line to IC16 to see if that fixes the 'jail bars'.
Chris

[ortek_service]

Originally Posted by ChrisOddy

Thanks for doing that Sirius, I've now corrected my circuit so it works the same.

>>
Chris

I presume it won't be too easy to have a link etc. to give the option of fixing this original 'bug / feature'. Especially if this to be an 'improved' version ?
As you'd told me you'd had to use different IC's to overcome it (And presumably not the same pinout / connections, to be able to easily just fit one or the other, depending on how original you wanted the display to look?)

I can't see anything really relying upon the screen pixel shift, and presumably wasn't something that was ever corrected in software (especially if many didn't really notice it, in the days of modulators and small TV's?)