Mk14 vdu

[Timbucus]

I am running 692 on mine.

[Slothie]

Originally Posted by Timbucus

I am running 692 on mine.

Oooh missed that one....

[SiriusHardware]

I think that FW352 is the working "original" version and FW523 is the working "optimised" version

Yes, that's right

The initial release version worked quite well but Karen found a bug in the 'inverse' feature which is fixed in FW352. At this point the code worked equally well with both 877 and 877A, although it did slow down the host system to a very significant extent.

FW523 is the first 'optimised' one after Karen had spotted and fixed that Port-A problem, after which all memory locations started to be rendered correctly to the screen, however, from the first optimised version onwards there was a new 'shudder' problem in graphics mode only and with the 877A chip only.

All subsequent versions after FW523 were aimed at either fixing the graphics shudder problem (for 877A chip only) or fixing the occasional memory corruption problem, but were unfortunately unsuccessful, although of course we were grateful to Karen for trying.

I would suggest that FW523 would be the best one to work on if you are thinking of extensively commenting the code because later versions have bits added in which Karen hoped would solve problems - leaving these in will just make it more complicated than it needs to be.

The graphics shudder problem has, we all seem to agree, been solved by specifying that only the plain 877 can be used. Trying to solve it for the 877A was taking up too much of Karen's time and energy.

This leaves the 'occasional memory corruption' problem which we are now hopeful can be 'solved' at least initially by adding 47pF capacitors to the high address lines. It may be possible to fix it 'properly' by making timing adjustments or changing the order of certain events in firmware.

I think that by posting the code -and- the source here Karen implicitly expected that we would take it and run with it as long as she is credited with the firmware and hardware design, of course.

Karen has not posted here herself since the last day of October, although I hope she has been able to follow what we have been trying to do. If Tim / Mark's little hardware bodge works for me as well, then we will be able to say that Karen's VDU works even better - produces a cleaner, nicer image than the SOC VDU and slows down the host system even less than the SOC VDU.

[SiriusHardware]

Well, today I added 47pF capacitors from A8, A9, A10 down to 0V. The system now seems to be able to run for at least four biscuits with OrtonView running and with the MK14 sat at the '0000 00' prompt without the reverse-C appearing.

However, if I just step quickly through the address range starting at 0000, within 20-30 or so clicks of the MEM key I have a reverse-C in the third from right digit. So although this mod has made the fault 'quieter' for me it has not made it go away.

I haven't yet tried running any software like Charset or Minefield but since I still have some corruption of the monitor display I expect that they will still be affected as well, just maybe not as badly or as quickly.

Since I've gone from no capacitance to 47pFs and that has effected some improvement I may now try 100pFs as per Tim's original starting point to see if it gets worse or better.

[Timbucus]

That is a shame - it certainly seems to have worked for me - are you using the 692 firmware - I am...

[SiriusHardware]

No, so I may as well try that first. Back shortly.

[SiriusHardware]

FW692 in addition to 47pFs on A8-A9-A10 seems to have improved things a bit, even after stepping through more than 100 addresses with the MEM key the reverse 'C' did not appear although I still occasionally see a brief flash of interference on the two normally blank digits.

Will dig out the rest of the stuff and try running Charset and Minefield.

[Timbucus]

Yes I can repeat those flashes the fact they do not stay I think means it is not a memory corruption as they go away on the next refresh - maybe it is a bus contention issue?

[SiriusHardware]

I'm running my version of charset which continually writes to 0327 in extra-extra RAM, you may recall that I found that writes to 03xx resulted in stray writes to both 0Fxx and 0Bxx.

Sorry to say that within a minute of starting that version of Charset I have stray characters "O" written to 0F27 and 0B27 so for me this problem is still there. That said, I've been watching it for quite a few minutes and it has not changed to '/', '_' or '?' yet which it usually would have by now, so this also points to the problem being reduced but not eliminated (for me).

I'll try 100pFs but unfortunately that means dragging it back to work again tomorrow.

[Timbucus]

Can you send me that version of CHARSET and I will try as I am getting corruption quite quickly on the 7 segment once my memory expansion is on when I use the monitor.

[Slothie]

Well I've looked at the difference between FW523 and FW692 and there are 8 sections that are changed; however the code is replicated 4 times for each buffer (A,B,C.D) so there are actually only 2 changes.

ian@FX503VD:~/MPLABXProjects/OrtonView.X$ git diff fw523 mk14vdu.asm
diff --git a/mk14vdu.asm b/mk14vdu.asm
index 27b9ffd..e2e21df 100644
--- a/mk14vdu.asm
+++ b/mk14vdu.asm
@@ -1131,12 +1131,12 @@ DTXTA   CLRF    INDF
        BSF     RCSTA,SPEN                      ; CALL DTXTA = 209~
        MOVF    TBGND,W
        MOVWF   TXREG
-       DELAY   2
-       BCF     PORTA,NENIN
+       DELAY   3^M
        MOVWF   TXREG
        DELAY   7
        MOVWF   TXREG
-       DELAY   2
+       DELAY   1^M
+       BCF     PORTA,NENIN^M
        MOVF    PCLATH,W
        MOVWF   PCHSAV
        MOVF    FNTPGE,W
:
: [snipped]
:
@@ -1714,8 +1714,8 @@ L401      BCF     PORTC,NSYNC
 ; Expects index 0..7 in FNTPGE
 DGRFA  BSF     INDF,0                          ; CALL DGRFA = 210~
        CALL    OFFBUS
-       DELAY   1
        BSF     RCSTA,SPEN
+       DELAY   1^M
        MOVF    TBGND,W
        MOVWF   TXREG
        MOVF    PCLATH,W
:
: [snipped]
:

In the first section, the PIC has just disconnected from the bus (the 2 statements before the diif output) and the point it drops NENIN is moved to after it starts outputting the blank space before the text on the line, so there is a longer interval the bus is floating before NENIN is sent to 0 and the SC/MP can access the bus.

In the second section, the (small) delay after coming off the bus in preparation for outputting a graphics line is moved to after enabling the serial port and before starting to transmit the blank area before the graphics (Giving more time for the serial port to initialise?)

Given that FW692 has less of a problem with corruption of memory (it would appear) then I would suggest the 2nd change is not involved but the 1st one is what caused the apparent change in behaiviour. Is it possible that it is the time that the VDU spends getting off the bus that is the problem, not getting on the bus? The fact that it hasn't completely cured the problem might just mean that a similar change might be needed when the 4 buffers are being pre-charged as Karen puts it.

Thoughts?

[Timbucus]

First thought - Slothie is now the official high priest of the Orton sect as he can read the book.

[SiriusHardware]

On the separate subject of how to do VDU memory page and control mode switching I was wondering if we could do this with a single programmed memory device like a PROM or EPROM or logic array like a GAL.

Inputs to the A0-A3 pins from four 8154 I/O pins configured as output:-
One other address pin takes input from VDU TOP PAGE which only goes to there and not directly to any of the VDU pins. Outputs from D0-D3 on the memory device go to VDU PS1-PS4.

Example, you want to use 0Fxx (upper screen), and 0Bxx (lower screen), and this is going to be 'Mode 1'. For this mode PS1 needs to be 1, PS2 needs to be 1, PS3 needs to be whatever the state of TOP PAGE is and PS4 needs to be 1.

If TOP PAGE is connected to A4 of the memory device, then location 0x0001 of the device would be programmed with xxxx1011 and location 0x0011 of the device would be programmed with xxxx1111 so that the state of TOP PAGE would be passed through onto PS3.

Now let's define Mode 2: Use 02xx (upper screen) and 03xx (lower screen). In location 0x0002 of the memory device you program xxxx0000 and in location 0x0012 you program xxxx0001, so that now PS2-PS4 are held low and toggling the state of memory device A4 with TOP PAGE toggles the state of the output to PS1.

The upper four bits of each programmed byte could obviously be used to control the other VDU control inputs, especially SWAP PAGES so that in the second mode above, 02xx is displayed above 03xx and of course GRAPH / CHAR and INVERSE and VDU_ON if you just wanted to do the whole VDU control setup with a simple 4 bit 'mode' code from the 8154 - maybe move TOP PAGE to A5 and have a 5-bit MODE code so you don't run out of modes too quickly.

If VDU_ON is one of the control inputs being controlled in this way then it makes sense for 'Mode 0' to be 'VDU off', since the default output states of the 8154 pins is 0.

Of course this is equally a job for a GAL but I have no experience with programming those, the principle would be the same though.

The main question is whether TOP PAGE would be propagated through the memory device quickly enough to be read by the VDU, especially the SOC VDU which responds to TOP PAGE in real time.

[SiriusHardware]

Unfortunately my thought is that in order for me to understand the code well enough to suggest changes I literally have to start at the beginning and work my way through every line of the code so that as I go, I learn what the various labels and constants are / what they mean.

I started to do this on one of the earlier versions but then Karen came out with quite a few subsequent versions and I decided I would only start again once we had a definitive version. I didn't get far the first time but I can tell you for example that the variable TBGND contains the data for the background colour for the upper (Top) screen. I only know that because I worked through the earlier parts of the code where that was set up, I can't just jump into the middle of the code and work it out the way Slothie apparently can.

In terms of ability to understand other peoples' code I am well behind Slothie and behind Tim, who I know made a living at one time writing fluent Z80 code. In software terms I am that kid who always gets picked last for the sports team, so you really can't rely on me at this point.

If you (Ian) think you can make the changes you have suggested please do try, we are happy to test drive anything you come up with.

[Timbucus]

Sounds good. Then we lead onto selecting other graphics modes like split screen characters and graphics... for that toppage needs to strap to that line as well.

For the moment on my Orton View I have a slide switch that changes the 330 Ohm resistor from driving PS3 (Base RAM) to driving PS1 (Exp RAM) - I will just make sure that all my software does not set the relevant bit to an Output - while testing I realized I had wired them back up backwards - luckily I had the scope on and saw the battle on the line...

[SiriusHardware]

Originally Posted by Timbucus

Then we lead onto selecting other graphics modes like split screen characters and graphics... for that toppage needs to strap to that line as well.

Yes, for those cases a change on TOPPAGE in on A4 would need to select a programmed byte where the GRAPH / CHAR control bit changes as well as the PS1 or PS3 control bit. It would be quite a humdrum job to define it all, maybe generation of the device contents could be automated via a program written in Python or 'C' or something.

[SiriusHardware]

For Tim:

This is my modified version of your Charset - it floods 0F12-0FFD and 0B00-0BFF with '@' which is a character never written by the corruption so it is easier to see when one has been replaced / overwritten.

It writes continually to 03xx in extra-extra RAM but assumes that you have the VDU set to render from 0Fxx and 0Bxx as I have found that it does stray writes to both 0fxx and 0bxx. You don't therefore see the 'char=' and the rolling character as they are being written to off-screen RAM.

I have commented out the lines which set up the 8154 ports and flags but you can easily reinstate them.

[Timbucus]

Well apart from the first line and two chars F12 I assume and the last character FFF which is J - it sits there rock steady - I did have to un-comment the 8154 enabling code.

[SiriusHardware]

Hmm, for me, within seconds, two characters at 0F1B and 0B1B change to 'O' and then usually stay that way. Pre-47pF, they would have kept on changing every now and again between 'O', '/', '_' and occasionally '?', all characters whose codes end in 'F'.

As mentioned I will try raising to 100pF tomorrow.

(Note offset is 0x1B, not 0x27 as stated earlier - I keep forgetting that the offset is defined in decimal in the source)

[Timbucus]

Originally Posted by SiriusHardware

Hmm, for me, within seconds, two characters at 0F1B and 0B1B change to 'O' and then usually stay that way. Pre-47pF, they would have kept on changing every now and again between 'O', '/', '_' and occasionally '?', all characters whose codes end in 'F'.

As mentioned I will try raising to 100pF tomorrow.

Left it since the first post - just looked at the screen and I have an Underline in 0B1B - nothing at 0F1B

Not sure when it happened as I was reading tagged posts on facebook.