25th Oct 2020, 11:32 pm | #601 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,364
|
Re: Mk14 vdu
Well this is probably a good news report and should be repeatable for Sirius.
I played 12 levels of Minefield on the SOC VDU with no problems until I got bored and triggered my explosion; If you hold F down to continuous fire (or pulse it a lot) then when it gets the end of the screen it crashes through memory - it was a bug to do with the slight recoil on fire that I left in as it is a good anti-cheat... I was only half joking on the Pot but thanks for the warnings. I tried soldering another 4.7K in parallel and that seemed to have little effect - I could still cause FALLMAN (occasionally) and MINEFIELD (always by the end of Level 1) to crash. CHARSET ran fine. Still saw the odd reverse C Just replaced the effective 2.3K with a 10K - my original fault on CHARSET is back in the same spot and FALLMAN/MINEFIELD crash a lot quicker. However, my clock may say half ten but, my body says it is bed time and I have work again in the morning... EDIT: For clarity this is the pullup on NWDS. |
25th Oct 2020, 11:35 pm | #602 |
Octode
Join Date: Mar 2011
Location: North Yorkshire, UK.
Posts: 1,119
|
Re: Mk14 vdu
just a thought, hope you dont mind me chipping in, shouldnt the 'Ↄ' be a 'O' which are the same except for bits 4 & 5 being low? maybe its not 0x0F being written, but bits 4&5 being pulled low? just thinking, these are nibble-wide RAM chips, and bits 0-3 are correct... ? ? ?
|
26th Oct 2020, 12:03 am | #603 | |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,364
|
Re: Mk14 vdu
Quote:
Putting the C back in restored operation - with the same repeatable char on CHARSET with the 10K NWDS pullup (the old 4.7K must have been close to that with the crack). While I was panicking that I had broken something I was uploading SEGTRIS so I tried that with the VDU on and OFF - its 7 digit display corrupts sometimes when playing with the VDU on consistent with a corrupt memory write. |
|
26th Oct 2020, 12:05 am | #604 | |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,364
|
Re: Mk14 vdu
Quote:
|
|
26th Oct 2020, 12:12 am | #605 |
Octode
Join Date: Mar 2011
Location: North Yorkshire, UK.
Posts: 1,119
|
Re: Mk14 vdu
|
26th Oct 2020, 12:15 am | #606 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,364
|
Re: Mk14 vdu
No problem appreciate the contribution keep em coming - it is a useful observation. I should have mentioned though that the SEGTRIS corruption of the display was also a 'Ↄ' (nice trick Phil_G) in the first two or three 7 segments on the left.
|
26th Oct 2020, 1:00 am | #607 | |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: Mk14 vdu
Quote:
|
|
26th Oct 2020, 1:10 am | #608 | |
Octode
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,297
|
Re: Mk14 vdu
Quote:
The SCMP outputs will be tristated by NENIN high, so rise time on NWDS might be slow, while the address lines may be driven to a different address by the PIC quite quickly. For me this is just guesswork as I don’t have anything set up to try this. |
|
26th Oct 2020, 9:41 am | #609 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
I've been working on a new version of the code which doesn't alter serial port baud rate for graphics i.e. both text and graphics use 4 M pixel/sec. It is hoped that this will eliminate juddering (unless someone's witnessed juddering on text?!!)
Trouble is, this new code has grown in size, and key routines may not fit into the PIC 2k code page they reside in. I won't be able to test this until I get back on my old XP laptop ('development' is limited to text editing on this crummy little laptop I have in hospital for the moment) I live in hope! |
26th Oct 2020, 9:54 am | #610 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,364
|
Re: Mk14 vdu
Appreciate the determination to make it compatible with A parts.
I am hoping Sirius will be able to reproduce the charset memory corruption as we might stand a chance of tracing what is likely the final bug. I had thought to try some gates that block the PIC assertion of NENIN while NWDS is still asserted but then I would need buffers as well and it becomes complex - if as the above implies it retries the write then that would Not work - the buffers would make it just like the SCRUMPI one - which I will do one day... Anyway if while editing the ASM you spot an opportunity to put a guard time - and flag where with a comment for NENIN to allow the write to finish - perhaps a bit like on the older FW which did not have this issue we could experiment empirically locally for you. Marks theory seems very possible to me I am also not clear if the added reads flapping NRDS that are over and above the SOC design to accommodate the other chips was put in? If so that could perhaps be an area to highlight in the code for temp removal as it is a difference in the spec I know I’m a man I hate asking for directions but, it seems needed in the complex neighbourhood |
26th Oct 2020, 9:55 am | #611 | |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,575
|
Re: Mk14 vdu
Quote:
I gather you are using an old XP laptop there, will one of the older archived versions of MPLAB or MPASMWIN not run on that? (Maybe the laptop doesn't have an internet connection). There has never to my knowledge been a problem with judder in character mode, and there has only been a problem with judder in graphics mode -From the first optimised version of firmware onwards -Only with 'A' suffix PIC devices. |
|
26th Oct 2020, 11:23 am | #612 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
Ah...
So you haven't experienced judder using the PIC16F877-20/P ? Well, that sounds like a solution to me! I suspect the judder problem is revealing of chip internal implementation details. In its proper context (serial communications) it usually doesn't matter if there is uncertainty about exactly when each transmission will begin. I sometimes have to remind myself that I have no right to be indignant about such details, when I am using a peripheral for a purpose never intended. I have hacked together a version of the code which uses a fixed pixel clock 4Mpix/sec. It is very unlikely that it will work: there may be typos, etc. and even if the MPLAB tools deem it valid code, I may have overrun a 2k page limit. I'll post it here anyway, just on the very remote chance that it works... |
26th Oct 2020, 11:29 am | #613 | |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
Quote:
|
|
26th Oct 2020, 12:42 pm | #614 |
Octode
Join Date: Mar 2011
Location: North Yorkshire, UK.
Posts: 1,119
|
Re: Mk14 vdu
Just a further thought, sorry I'm chipping in again... in the main video loop there are a lot of adjacent BSF/BCF/BTFSS on port C, could it be the old pic read-modify-write problem?
(at 20mhz the 'read' is only 50ns after the 'write' ie ¼ cycle) Last edited by Phil__G; 26th Oct 2020 at 12:53 pm. |
26th Oct 2020, 1:21 pm | #615 | |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,575
|
Re: Mk14 vdu
Quote:
I won't be able to try the new offering until this evening. |
|
26th Oct 2020, 1:30 pm | #616 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
Hi Phil G
You're thinking of read-modify-write hazards for port C? There are two outputs that might be vulnerable: the TOP output and the video sync output. The former is actually only valid for brief periods during frame blanking. The video sync... well... if trouble were occurring here we might see tears and discontinuities in the picture but none of the symptoms we've experienced so far. BTW, the PIC processor clock is one quarter of the crystal frequency (so the instruction cycle is 250nsec for this application). It would do no harm for me to sweep the code for BSF/BCF instructions in anticipation of such problems though... |
26th Oct 2020, 1:37 pm | #617 | |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
Quote:
I find it interesting that the juddering seems synchronised to the video frame rate. Any theories as to why this might be...? |
|
26th Oct 2020, 1:49 pm | #618 | |
Octode
Join Date: Mar 2011
Location: North Yorkshire, UK.
Posts: 1,119
|
Re: Mk14 vdu
Quote:
I usually use a shadow. But this is from memory, I dont have the sheets with me Last edited by Phil__G; 26th Oct 2020 at 2:02 pm. |
|
26th Oct 2020, 1:50 pm | #619 | |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,575
|
Re: Mk14 vdu
Quote:
I still need to carry out the test process I mentioned a few posts ago to be absolutely sure that the offset is per whole frame (only within the active area of the screen) or per line as you originally expected it would be. I'll add that to my 'to do' list and report back, since the root cause for one case or the other will be quite different. Of course if the code you posted today fixes it, that question will be redundant. |
|
26th Oct 2020, 1:56 pm | #620 | |
Octode
Join Date: Mar 2011
Location: North Yorkshire, UK.
Posts: 1,119
|
Re: Mk14 vdu
Quote:
I usually use a shadow. But this is from memory, I dont have the sheets with me |
|