Mk14 vdu

[SiriusHardware]

And sorry, for Karen, I'm not sure if I have made this clear: When the graphics display is shifted offset that is the case for one whole frame, not just on an individual line by line basis.

Either the whole frame is shifted a little bit to the right or the whole frame is not, and this is happening on a roughly 50/50 spilt (every other frame) as far as it is possible to tell. That's with the 'A' variant of the IC only, as far as we know.

[SiriusHardware]

Thanks Phil, I just wondered if Tim happens to have 4MHz parts there. Karen has said in the past that she quite often runs 4MHz parts well beyond their theoretical maximum speed.

Edit: Just spotted your edit re: Comparators on the 877A. Karen's code defines the chip configuration as a hex word rather than in longhand fashion "MCLR_EN, OSC_HS", etc) so I don't know exactly what the config word in the code does, especially with respect to the 877A.

[Timbucus]

No mine are PIC16F877-20I/P so the 20 variant.

[SiriusHardware]

OK, to be honest for the difference in price I think it would be a severe bit of luck-pushing to buy 4MHz parts in the hope that they would make it up to 16MHz. I'll get a couple of the 20s in via work so that I can also do the testing with both types. We could just as easily find some other thing which works as intended on 'A' but not on 'Non-A' types, such is life.

[Timbucus]

Originally Posted by Phil__G

When I bought my 877s for the PIC14 & PICL from RS, I noticed they list 04's and 20's
04 = 379-3143
20 = 467-1640

Heres something:

Sometimes I think there are clues hidden in many places that the machines are truly on the rise - in this reality they will not be 6502 but PIC it seems. (Apologies for non Terminator fans)

[SiriusHardware]

OK, a subject a little nearer to the mainstream... Tim, I've tried CHARSET.ASM

First thing to notice is that the MK14 is now running so fast with OrtonView active that I don't have to disable the VDU when uploading with the Arduino based uploader! - as explained in the past it uploads a bit more slowly than the Pi version which is probably too optimised for speed so when uploading to the MK14 + SOC VDU I don't bother to deactivate the VDU. This is also now the case with OrtonView so the speedup must be considerable. I'll run my 'tone generation benchmark' again at some point to see by what percentage OrtonView slows down the MK14 now.

Anyway... I don't get your stray character at all. I get the same line of garbage characters on the first line of the lower screen half but I don't get that single character appearing in the lower middle of the upper screen half or the lower screen half. I don't know if it was time related for you but I have had it running for about 20 minutes now. Using RAM 0F00- and 0B00-.

Only difference is that I REMmed out everything to do with setting 8154 or flag states before assembly since I do all that with pluggable links.

[Slothie]

Originally Posted by SiriusHardware

Edit: Just spotted your edit re: Comparators on the 877A. Karen's code defines the chip configuration as a hex word rather than in longhand fashion "MCLR_EN, OSC_HS", etc) so I don't know exactly what the config word in the code does, especially with respect to the 877A.

;S Config:
;  CP - DEBUG WRT1 WRT0 CPD LVP BOREN - - PWRTEN WDTEN FOSC1 FOSC0
;  1  1   1    1    0    1   0    0   1 1    0     0     1     0 
; Code protection off
; In-Circuit Debugger disabled, RB6 and RB7 are general purpose I/O pins
; 0000h to 00FFh write-protected; 0100h to 1FFFh may be written to by EECON control
; Data EEPROM code protection off
; RB3 is digital I/O, HV on MCLR must be used for programming
; Brown-out Reset disabled
; Power-up Timer enabled
; Watchdog Timer disabled
; HS oscillator on pins 12/13
;/S
CFG	EQU	H'3D32'

[SiriusHardware]

No mention of comparators in that lot, or did I miss something (What is CPD, code protection disabled?)

[Slothie]

Originally Posted by SiriusHardware

No mention of comparators in that lot, or did I miss something (What is CPD, code protection disabled?)

CPD = "code protection" on the data eeprom (off)
The comparators are controlled by CMCON (9F) which defaults to disabling the comparators. So setting the analog inputs off as Karens code does enables the RA ports as digital pins.

[SiriusHardware]

CMCON is the one I was looking for, but if a reset sets it to safe states that should be OK even if the control bits for the comparators are not specifically set up. I don't imagine it would be working at all if the situation was otherwise.

[SiriusHardware]

And... I've just tried my 'tone generator benchmark' with the OrtonView running the currrent firmware...

With OrtonView disabled... 888Hz (as before, with delay values minimised).
With OrtonView enabled... 851Hz!!!!

Does anyone else smell burning rubber?

[Timbucus]

About 4.2% slowdown then? Maybe I need to find my 8154 eliminator and try again in case that is having an effect

[SiriusHardware]

Another thing which you can try (...but I currently can't try the inverse of) is to see whether you still get that stray character appearing when using an 877A. Yes, you'll get the graphics shudder back over on graphics mode, but see if it makes your character mode problem go away.

[Timbucus]

I did get the same thing but, my perception was that is was slower and less frequent so perhaps the event which caused it was less likely? It has to be another corruption of the address lines as the only activity is the one changing character in the rotation in B00 yet the same character appears in both F00 and B00 at the same place.

This says to me there is a deterministic perhaps mathematical relationship related to a timing event we can find and that it is not a random thing. It will be harder to find it in Minefied when it goes bonkers as my key pressing is changing the events

[SiriusHardware]

Unfortunately I really can't reproduce your problem with CHARSET at the moment, will have another look at MINEFIELD when I get back in later.

Assuming that character location should contain '0x20' (space), what do you see if you reset the machine while the stray character is on the screen and then use SCIOS to look at the relevant location in each screen RAM area? Does it still contain 0x20 or do you see a value corresponding to the code of the stray character which was being displayed?

And, as a double check, does CHARSET still work normally with the SOC VDU clone? Definitely no stray character when you're using that?

[SiriusHardware]

You mentioned the possibility of trying your 8154 eliminator, try that because as I understand it you are currently using the 8154 to output the PS1-PS4 select codes. (Well, three out of four).

What if there is a 'blip' happening on the 8154 outputs which is making the VDU 'look away' to another area of RAM for the duration of just one character (the same one) on each half screen? You can rule that out by disconnecting PS1-PS4 from the 8154 port pins and hard-linking them as I happen to do, and see if that clears your CHARSET problem. (Obviously TOP PAGE will need to go to PS3 as usual, but hard-link the other three).

[SiriusHardware]

Come to think of it, Karen only reads the page base addresses once per frame (or does she?) so a one-character duration change of state of PS1-PS4 probably wouldn't be noticed by OrtonView. But try it anyway?

[Slothie]

Originally Posted by SiriusHardware

Come to think of it, Karen only reads the page base addresses once per frame (or does she?) so a one-character duration change of state of PS1-PS4 probably wouldn't be noticed by OrtonView. But try it anyway?

Yes, the config signals are read in both TOP states at the beginning of the frame. Since the VDU doesn't have the NWDS signal the only way I can imagine the VDU could actually change memory would be to corrupt the data bus somehow while the SC/MP is writing. Since the VDU never drives the data bus this seems unlikely. The wierd characters must either be some arcane bug in the PIC software or the SC/MP corrupting the data bus while the VDU is accessing the bus. Its all very odd.

[Timbucus]

Just checked that as well again as I was tired when I last did it and I can confirm that the SOC VDU never does it with my setup.

Running the OrtonView with the latest FW523 on an A chip for the testing. To be sure I also put back FW352 on my non A chip and ran CHARSET again in case I had not noticed it but, no it seems to run fine albeit slower. I also varied the delay up and down to see if that had an impact on the rate at which the character changed and I cannot really say I perceived it as doing so.

I have also removed the PI (nice to have live plug unplug) in case that was having an impact. It is always the correct character at BC5 and FC5 - when it was a / it was 2F and when it was O it was 8F (which has Bit 7 set though which does not show, not sure how as I set Bit 6 which is what controls Inverse on my SOC... so it seems Bit 7 is being affected).

So it is always those addresses on both A and Non A variants with FW523 that get the character apparently written.

Note that the ST 27(P1) is the only write in the loop so the only thing that can cause the effect so I moved it to 39 which is 12 bytes further on so should be at BD1 but it didn't it was at BC7/FC7 but this time had Bit 6 set correctly to be an Inverse O. Not very scientific but, I moved where the character was placed around a bit and it always seemed to be the area around the C0/B0 offset sometimes 5 sometimes 7 where the random character appears but, always in both memory banks. By a fluke the actual number display shows which memory address they are in as they are either under the 5 or the 7.

Maybe this speaks to a failure of the RAM chips to have settled on memory select so they are both selected at the same time and accept the write?

I have also noticed that after a while of use with the monitor poking about the 7 segment next to the byte value display shows a reverse C fairly consistently which could be another memory corruption showing up?

[Timbucus]

Originally Posted by SiriusHardware

You mentioned the possibility of trying your 8154 eliminator, try that because as I understand it you are currently using the 8154 to output the PS1-PS4 select codes. (Well, three out of four).

What if there is a 'blip' happening on the 8154 outputs which is making the VDU 'look away' to another area of RAM for the duration of just one character (the same one) on each half screen? You can rule that out by disconnecting PS1-PS4 from the 8154 port pins and hard-linking them as I happen to do, and see if that clears your CHARSET problem. (Obviously TOP PAGE will need to go to PS3 as usual, but hard-link the other three).

Indeed I am thinking of wiring some selector switches/jumper points on the VDU board to allow this independence from the 8154 as a next test. I could not find my eliminator - probably filed incorrectly (means tossed in a parts bin or tin I did not look in).