Mk14 vdu

[Karen O]

In this case the quarter cycle clocks are 62.5nsec but you're right Phil G.

I've made a minor change which might stop juddering in A version. If not, ignore and destroy all evidence of attachment. The secretary will disavow any knowledge of your actions.

[Phil__G]

Originally Posted by Karen O

In this case the quarter cycle clocks are 62.5nsec but you're right Phil G.

Period=1/Frequency
1/20,000,000hz = 50ns per clock cycle Karen. 200ns per '4 clock pulse' instruction cycle.
Only 50ns for a previous write to settle before it is read by the next instruction - doesnt take much capacitance to hold the pin voltage down for 50ns
Sorry to push it! could this '250ns' whoopsie affect video timing calculations?

[SiriusHardware]

Fun Fact: The VDU project runs on 16MHz, not 20MHz?

[Phil__G]

Originally Posted by SiriusHardware

Fun Fact: The VDU project runs on 16MHz, not 20MHz?

Ow cripes I'm really sorry everyone. I'm going to keep out of this now, honestly trying to help but making stupid assumptions
Is there a way to delete them once the edit window has passed?
Sorry all. (scurries away, tail between legs...)

AND somehow (?) I entered a duplicate post on the previous page...

[Mark1960]

It might be possible to test the theory of a shortened write cycle by adding an AND gate on the NENIN of the SC/MP. Inputs to the AND from NWDS and NENIN from the PIC.

This would allow a write cycle to complete before the SC/MP is kicked off the bus, but would depend on a delay between setting NENIN high from the PIC and the PIC starting to access RAM, that would need to be greater than the Pulse width on NWDS. 500 ns at 4MHz.

[SiriusHardware]

Originally Posted by Phil__G

Is there a way to delete them once the edit window has passed?

Unfortunately not, they are there FOREVER as I have also found to my considerable regret from time to time.

You just have to remember we are dealing with the High Priestess of PIC here - I'm mostly too scared to make suggestions, because I know I'll be wrong.

[Karen O]

Come on back, Phil G.

The point you were making would be valid whether the VDU was clocked from 16MHz OR 20MHz.

I don't think anyone here means to rebuke so let's all stay friendly.

[SiriusHardware]

Just ordered a couple of 877 (non A) from RS so I can parallel Tim's beta testing with both types. Thanks to Phil__G for finding the link to the RS part number so I didn't have to.

[Timbucus]

Excellent - do you think you will be able to test the 10K NWDS pull-up as well to see if the corruption appears / gets worse for you?

It’s occasional nature and relationship to NWDS getting back high gives credence to the time to complete theory and would also account perhaps for it appearing in both banks on charset as that must be a parallel write to partially changing address and data bus.

[SiriusHardware]

I can give that a go if you like but you might remember that when I fired up the very first firmware it didn't work because I had (...Durr) forgotten to include a pullup at all on NWDS. From that we can already say that there is a threshold resistance above which things will start to go wrong. Since I actually put a pullup on NWDS it has always been 4K7, SOC's recommended value.

Since you then put a definite 4K7 on yours, yours has also been OK in respect of the 'charset stray character' problem so we could conclude that as long as the NWDS pullup is the value it is supposed to be, it works. But if you're just curious to know whether a non-canon 10K pullup causes similar effects for me then I'll try that.

[Timbucus]

Originally Posted by SiriusHardware

I can give that a go if you like but you might remember that when I fired up the very first firmware it didn't work because I had (...Durr) forgotten to include a pullup at all on NWDS. From that we can already say that there is a threshold resistance above which things will start to go wrong. Since I actually put a pullup on NWDS it has always been 4K7, SOC's recommended value.

Since you then put a definite 4K7 on yours, yours has also been OK in respect of the 'charset stray character' problem so we could conclude that as long as the NWDS pullup is the value it is supposed to be, it works. But if you're just curious to know whether a non-canon 10K pullup causes similar effects for me then I'll try that.

Indeed you are correct but, it seems that the corrupt writes on the Graphics modes were also more common at 10K so should allow finding them easier - i.e. you should get the same failures as me. There will be enough of a Pullup to get over the main failure mode - if I have understood it correctly which is to prevent spurious writes by the RAM and worryingly by the 8154 when the CPU is in TriState which never happens on a basic MK14. Having NWDS low while a bus is in transition seems pretty fatal to me. This just smells like the fault I am getting. Hopefully even at 4.7K you can get MINEFIELD to crash - you certainly see the reverse C which is where I am at with 4.7K

Edit: The more writes a program does the greater the risk that NWDS is still low or climbing when the PIC transitions the address bus most likely but, from the corrupt bit 7 even the data bus.
Edit: For those not familiar MINEFIELD is a character mode program that crashes - it does a lot of writes...

[SiriusHardware]

First of all, regarding Karen's firmware modified with a view to both graphics and characters running at the same baudrate (FW posted in #612)... unfortunately this will not assemble for me. After the usual many warnings there are a large number of errors which break down into two types, examples of each below:-

The first looks to me as though the assembly process has overrun the available code memory. The second looks like a missing label definition.

Error[118] D:\TEMPFILES\MK14\PIC_VDU\VERSIONS\V1_07\MK14VDU\M K14VDU.ASM 2167 : Overwriting previous address contents (0FFC)
Error[118] D:\TEMPFILES\MK14\PIC_VDU\VERSIONS\V1_07\MK14VDU\M K14VDU.ASM 2167 : Overwriting previous address contents (0FFC)
Error[118] D:\TEMPFILES\MK14\PIC_VDU\VERSIONS\V1_07\MK14VDU\M K14VDU.ASM 2168 : Overwriting previous address contents (0FFD)
Error[118] D:\TEMPFILES\MK14\PIC_VDU\VERSIONS\V1_07\MK14VDU\M K14VDU.ASM 2168 : Overwriting previous address contents (0FFD)

Error[113] D:\TEMPFILES\MK14\PIC_VDU\VERSIONS\V1_07\MK14VDU\M K14VDU.ASM 2208 : Symbol not previously defined (PCL)
Error[113] D:\TEMPFILES\MK14\PIC_VDU\VERSIONS\V1_07\MK14VDU\M K14VDU.ASM 2226 : Symbol not previously defined (PCL)
Error[113] D:\TEMPFILES\MK14\PIC_VDU\VERSIONS\V1_07\MK14VDU\M K14VDU.ASM 2244 : Symbol not previously defined (PCL)
Error[113] D:\TEMPFILES\MK14\PIC_VDU\VERSIONS\V1_07\MK14VDU\M K14VDU.ASM 2262 : Symbol not previously defined (PCL)

I don't know whether Tim can confirm these problems. I'll move on to the most recently posted firmware from #621.

[SiriusHardware]

The firmware from #621 does assemble for me so I'll now try that to see if it has fixed the 'A suffix shudder'.

[Timbucus]

Originally Posted by SiriusHardware

First of all, regarding Karen's firmware modified with a view to both graphics and characters running at the same baudrate (FW posted in #612)... unfortunately this will not assemble for me. After the usual many warnings there are a large number of errors which break down into two types, examples of each below:-

The first looks to me as though the assembly process has overrun the available code memory. The second looks like a missing label definition.

I don't know whether Tim can confirm these problems. I'll move on to the most recently posted firmware from #621.

Yes I get similar errors on PCL not defined but,I do not get the Overwriting Address errors just loads of warnings of Crossing Page Boundary

[Timbucus]

Originally Posted by SiriusHardware

The firmware from #621 does assemble for me so I'll now try that to see if it has fixed the 'A suffix shudder'.

It did not for me unfortunately.

[SiriusHardware]

And sorry to say that with firmware from #621, graphics mode only and 'A' suffix PIC, the shudder is still there. Thanks for trying anyway, Karen. The only thing I can point to as a clue is to say again that this problem (graphics screen shudder, 'A' suffix PIC only), first appeared in the first optimised version.

In the two released versions prior to that, graphics mode rendering was rock steady even with an 'A' suffix PIC, so something in the modifications which were made after those 'broke' graphics mode for 'A' suffix devices from that point on.

[Timbucus]

Originally Posted by SiriusHardware

And sorry to say that with firmware from #621, graphics mode only and 'A' suffix PIC, the shudder is still there. Thanks for trying anyway, Karen.

Indeed - as you say once you have your non A and can confirm the same as me - I think we say it does not work on an A part...

Then if we can cure the occasional memory write errors it will be perfect.

Karen - if there is an easy way to cause a fixed delay when the PIC asserts NENIN then we should be OK as the 352 original FW did not have any memory corruption events as my youtube video showed - the (theorized) memory write problem only began with the optimized firmware which as I understand it gave more time with NENIN low for the CPU to work.

[Timbucus]

If anyone is interested the changes that caused the graphics judder on A parts and started the memory write errors occurred between #352 and the optimized version. This is the difference between #352 and the latest #621 (assuming we consider the #612 version a development branch).

[SiriusHardware]

I've just had 'Minefield' running on both OrtonView and SOC VDU - infuriating game, especially when you miss one of the very last mines and get sent all the way back to the beginning again.

On OrVw I don't have to play it for long before strange things start happening, random bits of tank all over the screen or similar. I can only assume this is due to the game code getting gradually corrupted.

On SOC VDU the game kept running for as long as I had patience to keep playing it for - in both cases with the usual NWDS pullup value of 4K7, I didn't need to bend that value in order to see Minefield failing quite soon when running on OrVw. Luckily, every time the code got smashed up it was a simple matter just to reload it.

[Timbucus]

Originally Posted by SiriusHardware

I've just had 'Minefield' running on both OrtonView and SOC VDU - infuriating game, especially when you miss one of the very last mines and get sent all the way back to the beginning again.

On OrVw I don't have to play it for long before strange things start happening, random bits of tank all over the screen or similar. I can only assume this is due to the game code getting gradually corrupted.

On SOC VDU the game kept running for as long as I had patience to keep playing it for - in both cases with the usual NWDS pullup value of 4K7, I didn't need to bend that value in order to see Minefield failing quite soon when running on OrVw. Luckily, every time the code got smashed up it was a simple matter just to reload it.

That is great news - the exact same effect I have - it is quite a good game actually!

Edit - the F fire trick is useful when you get reset as it will pulse the tank forward a little faster so you get to the previous place with your new tank quicker.