RGB to HDMI using a Pi Zero and a small CPLD

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
User avatar
hoglet
Posts: 8901
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by hoglet » Sat Oct 20, 2018 7:34 pm

IanB wrote:
Sat Oct 20, 2018 7:01 pm
I fixed the glitches by reordering some more instructions and re-arranging register use according to dp11's helpful hints above.
I'm now going to retry some of my other deinterlacing ideas using the same re-ordering trick to see if they make any improvement.
It would be good to get that version into git.

I'll push it if you attach a zip.

Dave

dp11
Posts: 979
Joined: Sun Aug 12, 2012 8:47 pm
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by dp11 » Sat Oct 20, 2018 8:05 pm

a few cycles saved I think.

Code: Select all

process_chars_7\@:

        push   {r1, r5,r11}              // need scratch registers
        
        // Working registers in the second half
        //
        //  r0 = scratch register
        //  r1 = scratch
        //  r2 = bytes per line
        //  r3 = field state
        //  r4 = GPLEV0
        //  r5 = 0x77777777
        //  r6 = pixel counter
        //  r7 = red overlay for vsync indicator
        //  r8 = value read from GPLEV0
        //  r9 = extracted pixel
        // r10 = block of 8 pixels, to be written to FB
        // r11 = pointer into frame buffer (start of line)
        // r12 = pointer into frame buffer (moves within line)

 	ldr    r11, =SCREEN_HEIGHT
 	
        tst    r3, #BIT_FIELD_TYPE       // test odd or even field

        ldr    r5, =0x77777777           // extract OSD mask
       
        mul    r11, r11, r2              // offset to second buffer used for comparison not for display
process_chars_loop_7\@:

.if \psync_polarity == 1
        // Wait for 0-1 edge on PSYNC
        WAIT_FOR_PSYNC_1
.else
        // Wait for 1-0 edge on PSYNC
        WAIT_FOR_PSYNC_0
.endif

        // Pixel 0 in GPIO  4.. 2 ->  7.. 4
        // Pixel 1 in GPIO  7.. 5 ->  3.. 0
        // Pixel 2 in GPIO 10.. 8 -> 15..12
        // Pixel 3 in GPIO 13..11 -> 11.. 8

        and    r10, r8, #(7 << PIXEL_BASE)
        and    r9, r8, #(7 << (PIXEL_BASE + 3))
        and    r0, r8, #(7 << (PIXEL_BASE + 6))
        and    r1, r8, #(7 << (PIXEL_BASE + 9))
        mov    r10, r10, lsl #(4 - PIXEL_BASE)
        orr    r10, r10, r9, lsr #(3 + PIXEL_BASE)
        orr    r10, r10, r0, lsl #(6 - PIXEL_BASE)
        orr    r10, r10, r1, lsr #(1 + PIXEL_BASE)
        ldr    r0, [r12,r11]        // preload old pixel value from comparison (2nd) buffer

.if \psync_polarity == 1
        // Wait for 1-0 edge on PSYNC
        WAIT_FOR_PSYNC_0
.else
        // Wait for 0-1 edge on PSYNC
        WAIT_FOR_PSYNC_1
.endif

        // Pixel 4 in GPIO  4.. 2 -> 23..20
        // Pixel 5 in GPIO  7.. 5 -> 19..16
        // Pixel 6 in GPIO 10.. 8 -> 31..28
        // Pixel 7 in GPIO 13..11 -> 27..24

        and    r9, r8, #(7 << PIXEL_BASE)
        and    r1, r8, #(7 << (PIXEL_BASE + 3))
        orr    r10, r10, r9, lsl #(20 - PIXEL_BASE)
        orr    r10, r10, r1, lsl #(13 - PIXEL_BASE)
        and    r9, r8, #(7 << (PIXEL_BASE + 6))
        and    r1, r8, #(7 << (PIXEL_BASE + 9))
        orr    r10, r10, r9, lsl #(22 - PIXEL_BASE)
        orr    r10, r10, r1, lsl #(15 - PIXEL_BASE)

                                    // The Motion Adaptive Deinterlacing algorithm below was created
                                    // by Ian Bradbury (IanB on stardot). Many thanks Ian.
                                    //
                                    // constants set above:
                                    // r1 = offset to adjacent line in other field either above or below
                                    // r5 = bitmask 0x77777777 to extract OSD bits
                                    // r11 = offset to comparison buffer

        mov    r9, r0               // make a copy of old pixel value in r9
        bic    r0, r5               // clear old video bits, retaining OSD bits
        orr    r10, r0              // merge new video bits
        ldr  r0, [r12,-r2]         // read other field pixel value (offset above or below in r1)
        add  r8, r11, r2          // adjust pointer to next line in comparison buffer
        ldr     r1, [r12,r8]         // read next line of comparison buffer
        str    r10, [r12,r11]       // save in comparison buffer



                                    // test for calibration or deinterlace disabled
                                    // if either branch to skip_deinterlace\@ as deinterlace code messes up the calibration
      
        tst    r3, #(BIT_CALIBRATE | BIT_NO_DEINT)
        bne    skip_deinterlace\@

        cmp    r10, r9              // is new value same as old value?

        andne  r9, r10, r5          // r9 is now free, use it for the new pixel value (without an OSD)

        bicne  r0, r5               // clear old video bits, retaining OSD bits
        orrne  r0, r9               // merge new video bits
        strne  r0, [r12,-r2]         // overwrite other field pixel value (offset above or below in r1)
 
        tstne  r3, #BIT_DEINT_MODE  // Only do the next bit if pixels different, and deinterlace=Motion Adative 2

        bicne  r1, r5               // clear old video bits, retaining OSD bits
        orrne  r1, r9               // merge new video bits
        strne  r1, [r12,r8]         // overwrite next line of comparison buffer (delays end of deinterlacing)

skip_deinterlace\@:

        // Orr in the VSync indicator
        orr    r10, r7

        str    r10, [r12], #4       // write new pixel value to video buffer
        subs   r6, r6, #1
        bne    process_chars_loop_7\@

        pop    {r1, r5, r11}        // restore scratch registers

exit_process_chars\@:
The ARM cycle counters can be used to count pipeline stall. I don't think there are any stalls left in the above .

User avatar
IanB
Posts: 462
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB » Sat Oct 20, 2018 9:08 pm

hoglet wrote:
Sat Oct 20, 2018 7:34 pm
It would be good to get that version into git.
I'll push it if you attach a zip.
Here you go:
rgb_to_fb.zip
(5.6 KiB) Downloaded 11 times
It seems to me that in this case the best optimisation is made by putting the reads as early as possible and putting as much unrelated code between them and the point they are needed.

BTW is the screen RAM cached or not?

User avatar
IanB
Posts: 462
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB » Sat Oct 20, 2018 10:10 pm

dp11 wrote:
Sat Oct 20, 2018 8:05 pm
a few cycles saved I think.
Thanks, that's given me some other optimisations to try but I don't think it's going to work as-is because it looks like you've substituted -R2 for R1 when the value of R1 is either R2 or -R2 depending on the field.
Anyway I'm rewriting it now trying to squeeze in yet another LDR for an alternative approach to the 50hz deinterlace.
dp11 wrote:
Fri Oct 19, 2018 10:15 pm
Make sure the result of LDRs are used for at least for at least two cycles ( longer if not in the cache or the result is the used in the next LDR)
How many cycles for an LDR when there is a cache miss?

dp11
Posts: 979
Joined: Sun Aug 12, 2012 8:47 pm
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by dp11 » Sat Oct 20, 2018 10:24 pm

opps missed r1 flips between + / -

cache misses can be very hard to calculate, but budget 20 to 40 cycles

can you on the previous line perform an LDR but not use the result, so when you actually do the LDR the data is in the cache?
Last edited by dp11 on Sat Oct 20, 2018 10:38 pm, edited 2 times in total.

User avatar
hoglet
Posts: 8901
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by hoglet » Sun Oct 21, 2018 2:45 pm

IanB wrote:
Sat Oct 20, 2018 9:08 pm
BTW is the screen RAM cached or not?
The address my system ends up using for the frame buffer is: 0x1F974000.

Looking at the current MMU setup (in cache.h/cache.c) I that ends up being marked as un-cached.

The other relevant parameter is:

Code: Select all

# Don't allow ARM to use Level 2 Cache - this actually speeds up cache misses
disable_l2cache=1
Currently we don't allow the ARM to make use of the Level 2 cache.

For reference, the BCM2835 used on the Pi Zero has the following caches:
- 16KB L1 Instruction Cache
- 16KB L1 Data Cache
- 128KB L2 Cache (Unified)

The frame buffer in Mode 7 has a "pitch" of 256 bytes per line (and 540 lines), which comes to 135KB, so is larger than the L2 cache.

I'm not sure it's going to help much making it cache-able (if that's even possible), as what matters is the worst case memory latency, not the average memory latency.

In terms of other optimisations, I did wonder if you could do the motion detection based on just the previous value read from the frame buffer. The comparison array could then be replaced with a bit map (one bit per word of frame buffer), and would just be used for the "slow" deinlerlacing mode. That would reduce it's size to just over 4KB, so it could be located in L1 cached memory.

Dave
Last edited by hoglet on Sun Oct 21, 2018 2:47 pm, edited 2 times in total.

User avatar
IanB
Posts: 462
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB » Sun Oct 21, 2018 4:59 pm

hoglet wrote:
Sun Oct 21, 2018 2:45 pm
In terms of other optimisations, I did wonder if you could do the motion detection based on just the previous value read from the frame buffer.
Deinterlacing keeps changing the screen in motion areas so you can't use it for comparison as well as those changes are seen as continuous motion and it gets into a loop.

I've got the new algorithm working and it gets rid of some aretefacts like the weave lines at the top of the space ship in mode 7 scramble and the tear line at the top of the fast blocks in M7TEST

There are still occasional timing glitches but I have disabled reading the old screen values when the OSD is off so you shouldn't see those glitches in normal operation, only when the OSD is on.

There are now four settings with 1 to 4 fields of delay on the deinterlace so I have updated the menu as well.

Here are the files for you to test:
newdeinterlace.zip
(19.83 KiB) Downloaded 8 times
New mode 1 is the same as old mode 1 but the others are all new and behave slightly differently to the old mode 2
I would say that new mode 3 is roughly equivalent to old mode 2

One thing I forgot to change is to revert to writing the menu to the video screen only as those bits are now used for motion flags.
Fixing this may improve the menu on/off transition if there is motion.
Last edited by IanB on Sun Oct 21, 2018 4:59 pm, edited 1 time in total.

User avatar
hoglet
Posts: 8901
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by hoglet » Sun Oct 21, 2018 5:46 pm

This gets better and better! :D

I think I can see the improvement with the 3 and 4 field variants, but it's quite subtle.

The only bug I've spotted is that the OSD is now very flickery/flashy during auto-calibration, regardless of what de-interlace mode is set (including deinterlace off). That suggests that BIT_CALIBRATE is no longer being used properly to bypass the de-interlacing code.

Oh, and one more little thing. If you could set your editor to use spaces rather than tabs that would be much appreciated. :D

Dave
Last edited by hoglet on Sun Oct 21, 2018 5:48 pm, edited 4 times in total.

User avatar
IanB
Posts: 462
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB » Sun Oct 21, 2018 5:55 pm

hoglet wrote:
Sun Oct 21, 2018 5:46 pm
I think I can see the improvement with the 3 and 4 field variants, but it's quite subtle.
3 & 4 don't look much different with Scramble and M7TEST bit I do notice a difference with the mode 7 mouse cursor in Quest paint.
If the cursor is moved quckly you sometimes get weaving in mode 2 but it is greatly reduced in modes 3 & 4.
I'm not sure what's actually going on in the screen update that causes this so it's difficult to write a test for that.

How do you find the "fizzing" duration with the different modes?
hoglet wrote:
Sun Oct 21, 2018 5:46 pm
The only bug I've spotted is that the OSD is now very flickery/flashy during auto-calibration, regardless of what de-interlace mode is set (including deinterlace off). That suggests that BIT_CALIBRATE is no longer being used properly to bypass the de-interlacing code.
I haven't used calibration recently since I set my values in config and they've been very stable. I'll look at that now.

I think I've sorted out the remaining glitches by moving the preloads around a bit more
Last edited by IanB on Sun Oct 21, 2018 6:32 pm, edited 1 time in total.

User avatar
IanB
Posts: 462
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB » Sun Oct 21, 2018 7:17 pm

hoglet wrote:
Sun Oct 21, 2018 5:46 pm
The only bug I've spotted is that the OSD is now very flickery/flashy during auto-calibration
Should be fixed now, also this includes the glitch fix mentione above (hopefully no tabs!)
rgb_to_fb.zip
(5.98 KiB) Downloaded 12 times
The only thing to fix is the OSD update to write to the video buffer only as currently every time you make a change to the OSD you get spurious deinterlacing

Edit: I just realised there are 8 OSD bits per word so I'll have to find a use for the other 4 :D
Last edited by IanB on Sun Oct 21, 2018 7:22 pm, edited 1 time in total.

User avatar
hoglet
Posts: 8901
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by hoglet » Sun Oct 21, 2018 7:55 pm

IanB wrote:
Sun Oct 21, 2018 7:17 pm
Should be fixed now, also this includes the glitch fix mentione above (hopefully no tabs!)
rgb_to_fb.zip
That's great, and it's now pushed to the dev branch.
IanB wrote:
Sun Oct 21, 2018 7:17 pm
The only thing to fix is the OSD update to write to the video buffer only as currently every time you make a change to the OSD you get spurious deinterlacing
Done as well.

I've also just found and fixed a gitch with the OSD when scanlines are enabled (mode 0..6) that crept in somewhere in the last several commits.
IanB wrote:
Sun Oct 21, 2018 7:17 pm
Edit: I just realised there are 8 OSD bits per word so I'll have to find a use for the other 4 :D
That's because there are eight 4-bit pixels per word. All of the OSD bits are used for OSD (aren't they?)

Dave
Last edited by hoglet on Sun Oct 21, 2018 8:11 pm, edited 1 time in total.

User avatar
IanB
Posts: 462
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB » Sun Oct 21, 2018 8:09 pm

hoglet wrote:
Sun Oct 21, 2018 7:55 pm
That's because there are eight 4-bit pixels per word. All of the OSD bits are used for OSD (aren't they?)
Yes I meant in the comparison buffer, the OSD bits are used as motion flags but I had in mind there were only 4 when I wrote the code but as there are 8, the other four could be used as well for something like increasing to 8 fields but that probably wouldn't be very useful.

I just thought of a simple project to test dp11's new 1Mhz bus board:
Connect the debug serial ports of RGBtoHDMI and the 1Mhz bus board and you can program the palette over the 1 Mhz bus.
I think I still have the VDU19 driver for the palette I designed and that ran on the 1Mhz bus:
viewtopic.php?f=3&t=14169&p=187976#p187976
Last edited by IanB on Sun Oct 21, 2018 8:13 pm, edited 1 time in total.

User avatar
hoglet
Posts: 8901
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by hoglet » Tue Oct 23, 2018 8:57 am

IanB wrote:
Sun Oct 21, 2018 8:09 pm
I just thought of a simple project to test dp11's new 1Mhz bus board:
Connect the debug serial ports of RGBtoHDMI and the 1Mhz bus board and you can program the palette over the 1 Mhz bus.
I think I still have the VDU19 driver for the palette I designed and that ran on the 1Mhz bus:
viewtopic.php?f=3&t=14169&p=187976#p187976
The other idea that was floated by Tricky for palette programming was modulating the sync pulse width.

Back to the deinterlacing - are you envisaging any further changes in the next few days? If not, I'd like to merge back to master and upload a new release build for the wider community to try.

I was also going to include your M7TEST program in the companion disc, together with scramble and the other mode 7 game (whose name escapes me at the moment). It that OK with you?

Dave
Last edited by hoglet on Tue Oct 23, 2018 8:59 am, edited 1 time in total.

User avatar
IanB
Posts: 462
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB » Tue Oct 23, 2018 2:50 pm

hoglet wrote:
Tue Oct 23, 2018 8:57 am
The other idea that was floated by Tricky for palette programming was modulating the sync pulse width.
If you can get that working that would be really neat but the 1Mhz bus idea was more a way of quickly exercising the 1Mhz bus to Pi interface and having something useful at the end of it. I found the source for the support ROM so it wouldn't need much if any beeb development to get it working.
hoglet wrote:
Tue Oct 23, 2018 8:57 am
Back to the deinterlacing - are you envisaging any further changes in the next few days? If not, I'd like to merge back to master and upload a new release build for the wider community to try.
I have tried a couple of things like extending to 8 fields (lots of fizzing) and merging in the old technique of deliberately corrupting the following frame's comparison buffer but apart from one very minor case I haven't seen any real benefit so far.

I have done some analysis on what's going on with these techniques and identified the case that it won't handle which is rapidly switching between a solid block and a space once per field which remains displayed as a white block with black weave lines.

This is because the algorithm is comparing odd with odd and even with even so in the above example if the white block is written to the odd field and the space is written to the even field repeatedly it sees the odd field as always having white and the even field as always having black so doesn't detect any motion (this also caused the weave artifact in M7TEST in mode 1). By remembering motion in previous odd and even field comparisons, this can be worked around which is why modes 2 - 4 remember the previous 1 - 3 field comparisons respectively and that effectively fixes the artifacts in most cases at the expense of increased 'fizzing' although it doesn't work with the above worst case example.

The ony way to detect the above example would be to compare odd with even and even with odd but as they are different due to the character rounding that would require a significant increase in processing time which we don't have.
I think the above handles most cases, I would say mode 1 gets about 50% deinterlaced, mode 2 about 90% and 3 and 4 mop up most other cases so I would suggest mode 2 as probably the best one to go with as a default.

Incidentally the old mode 2 with it's corruption of the following field's comparison buffer actually did some very strange things which meant that worst case the top line pair of a charater fizzed for 1 field, the second line pair for 2 fields, the 3rd for 3 fields and so on until the last line which would fizz for up to 9 fields. It wouldn't progress beyond the last line because detection stopped when it came across a matching line pair which included the black lines between each row of text. That was a worst case example but I think on average it caused fizzing for around 4 fields so the new mode 2 is much better than the old one in that respect.
hoglet wrote:
Tue Oct 23, 2018 8:57 am
I was also going to include your M7TEST program in the companion disc, together with scramble and the other mode 7 game (whose name escapes me at the moment). It that OK with you?
Sure, no problem. There are several other mode 7 games I recall including Acorn Arcade which was a collection of Mode 7 games by Acornsoft that included space invaders and snake. I haven't found my copies yet but it's worth checking them first if you can find them. I also recall another game with scrolling mode 7 graphics, I think it was a computer version of a board game (monopoly maybe?) but I haven't looked for that one yet.

We also need to come up with a mode 7 test pattern page, something like the old clock cracker page on teletext to be used with mode 7 calibration.
I found that when I ran mode 7 calibration with a screen full of text it looked fine but then when I moved the mode 7 block cursor in Quest Paint to the right of some text chars in the mode 7 menu (letter S I recall) I got twinking pixels which went away with a recalibration.
I think the test page would need inverted video, and solid blocks interspersed between letters to catch all cases.
Perhaps we could use the clock cracker page as a starting point as it already had all possible teletext features active.
Last edited by IanB on Tue Oct 23, 2018 2:58 pm, edited 1 time in total.

User avatar
hoglet
Posts: 8901
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by hoglet » Tue Oct 23, 2018 3:17 pm

IanB wrote:
Tue Oct 23, 2018 2:50 pm
We also need to come up with a mode 7 test pattern page, something like the old clock cracker page on teletext to be used with mode 7 calibration.
I found that when I ran mode 7 calibration with a screen full of text it looked fine but then when I moved the mode 7 block cursor in Quest Paint to the right of some text chars in the mode 7 menu (letter S I recall) I got twinking pixels which went away with a recalibration.
I think the test page would need inverted video, and solid blocks interspersed between letters to catch all cases.
Perhaps we could use the clock cracker page as a starting point as it already had all possible teletext features active.
Was this on a Master?

Could you possibly run the auto calibration in the two cases (a screen full of text, then later in Quest Paint) and note down the error counts and final calibration in each case?

(If you have a serial cable there are logged there as well).

It would be very interesting to see what changes between calibrations.

In the Master's I've tried, there is quite a plateau (normally spanning three different sample offsets) where zero errors are seen, and the algorithm should be picking the middle of this, giving some safety margin.

It sounds like this is not working quite going to plan in your case.

Dave

User avatar
IanB
Posts: 462
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB » Tue Oct 23, 2018 4:10 pm

hoglet wrote:
Tue Oct 23, 2018 3:17 pm
Was this on a Master?
Could you possibly run the auto calibration in the two cases (a screen full of text, then later in Quest Paint) and note down the error counts and final calibration in each case?
Yes, It's a Master.
Running on a screen full of text :
2,2,2,2,2,2
42457
22462
0
354
64243
14048
42805
34929

With the Quest Paint menu with cursor out of the way I get:
2,2,2,2,2,2
6280
4732
0
18
6268
2123
5440
5064

With the Quest Paint menu with the hardware cursor (configured for full height no flashing) over a character (e.g."S") inverting it I get:

4,3,2,3,3,3
9267
5277
79
20
8101
2545
6857
7093

Sometime the calibration is 3,3,2,3,3,3 or 3,4,2,3,3,3
Thinking about it, the hardware cursor is generated by the 6845 so may have marginally different timing to the rest of the characters and that may be the issue in which case a test page would just need some text with the full height hardware cursor over one letter.

EDIT: Also I noticed that the mode 7 buffer is 3 bytes wider than Mode 7 but the mode 7 data is written to the left of the buffer with the unused 3 bytes at the end, was that intentional as I thought you were allowing some buffer either side.
Last edited by IanB on Tue Oct 23, 2018 4:19 pm, edited 1 time in total.

User avatar
hoglet
Posts: 8901
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by hoglet » Tue Oct 23, 2018 4:54 pm

IanB wrote:
Tue Oct 23, 2018 4:10 pm
Yes, It's a Master.
Running on a screen full of text :
2,2,2,2,2,2
42457
22462
0
354
64243
14048
42805
34929
That's already interesting - on my Master I typically get three results with 0 scores. That's suggesting your mode 7 clock is more asymmetric than mine.
IanB wrote:
Tue Oct 23, 2018 4:10 pm
With the Quest Paint menu with the hardware cursor (configured for full height no flashing) over a character (e.g."S") inverting it I get:
4,3,2,3,3,3
9267
5277
79
20
8101
2545
6857
7093
Sometime the calibration is 3,3,2,3,3,3 or 3,4,2,3,3,3
Thinking about it, the hardware cursor is generated by the 6845 so may have marginally different timing to the rest of the characters and that may be the issue in which case a test page would just need some text with the full height hardware cursor over one letter.
What sort of cursor is being used here? i.e. the size, and is it flashing?

There is some code in the auto calibration to ignore lines that *might* contain a cursor, to avoid a flashing cursor looking like errors. This will only work with a standard sized cursor.
IanB wrote:
Tue Oct 23, 2018 4:10 pm
EDIT: Also I noticed that the mode 7 buffer is 3 bytes wider than Mode 7 but the mode 7 data is written to the left of the buffer with the unused 3 bytes at the end, was that intentional as I thought you were allowing some buffer either side.
I have been trying to keep the extra left/right margins roughly equal in Mode 7, but clearly they aren't currently.

I think the mistake I made was setting them using the STH Menu Program. Because it doesn't put anything visible in column zero.

They are actually set in the CPLD, so I'll adjust them there to get them spot on.

Dave

User avatar
IanB
Posts: 462
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB » Tue Oct 23, 2018 5:06 pm

hoglet wrote:
Tue Oct 23, 2018 4:54 pm
What sort of cursor is being used here? i.e. the size, and is it flashing?
Full height no flashing.

User avatar
hoglet
Posts: 8901
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by hoglet » Tue Oct 23, 2018 5:39 pm

Maybe I should try to get Quest Paint running on my Master so I can see what's going on here.

(I'm slightly confused at the use of Mode 7 by Quest Paint - which I thought just used Mode 1)

This was one of your programs wasn't it Ian? Any objections to it being liberated?

(Or alternatively, if you fancy a short trip over to Bristol at some point)

Dave
Last edited by hoglet on Tue Oct 23, 2018 5:53 pm, edited 2 times in total.

User avatar
tricky
Posts: 3997
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by tricky » Tue Oct 23, 2018 6:16 pm

Have you tried the BitShifters MODE 7 demos?
https://bitshifters.github.io/ TELETEXTR and TELETEXT BAD APPLE.
I've also attached my old mode 7 vertical scrolling demo, not really interlace affected, but one more data point.
Attachments
mode7.zip
(2.01 KiB) Downloaded 11 times

User avatar
IanB
Posts: 462
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB » Tue Oct 23, 2018 7:27 pm

hoglet wrote:
Tue Oct 23, 2018 5:39 pm
Maybe I should try to get Quest Paint running on my Master so I can see what's going on here.
This was one of your programs wasn't it Ian? Any objections to it being liberated?
That might be difficult, It's in a 32K PALROM (i.e a 32 K EPROM and a bank switch PAL on a small PCB)
Also the bank switching isn't just 2 x 16K but a fixed lower 8K and each 8K section of the EPROM can be switched into the top half (including the bottom 8K - some code from the bottom 8K will only run when switched into the top 8K) so it isn't easy to get it running in sideways RAM and even I never ran it from sideways RAM as I had a RAM based development version of the PALROM board before I started so it was designed from the ground up to make use of this bank switching scheme.

Wapping editor is even worse in that respect as it's in a 64K EPROM with 8 x 8K banks

I didn't design the original PAL boards, but I was intending one day to design a pcb and re-implement the PALs for anyone that wants a copy.
hoglet wrote:
Tue Oct 23, 2018 5:39 pm
(I'm slightly confused at the use of Mode 7 by Quest Paint - which I thought just used Mode 1)
It actually uses Mode 0,1 and 7
The graphics are mode 1 but the top menu is interrupt driven mode 0 when it's on screen:
mode0-1.jpg
The I/O menu is Mode 7 so you could use * commands and get full disc catalogs on screen:
mode7.jpg
As it had a mouse driven mode 7 cursor I found it very useful for testing deinterlacing artefacts as the cursor could be moved around at varying speeds and over the menu characters to see the effects.
hoglet wrote:
Tue Oct 23, 2018 5:39 pm
(Or alternatively, if you fancy a short trip over to Bristol at some point)
That might be the easiest thing to do.

User avatar
hoglet
Posts: 8901
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by hoglet » Tue Oct 23, 2018 7:34 pm

IanB wrote:
Tue Oct 23, 2018 7:27 pm
That might be difficult, It's in a 32K PALROM (i.e a 32 K EPROM and a bank switch PAL on a small PCB)
...
I didn't design the original PAL boards, but I was intending one day to design a pcb and re-implement the PALs for anyone that wants a copy.
Yes, I've been reading the Watford document you posted a while ago. I agree that it's not possible to do this in software.

So I was thinking of trying to replicate the cartridge (unless someone else has already done this, or you want to do this yourself).

Did support for these ever get added to MAME?

Dave
Last edited by hoglet on Tue Oct 23, 2018 7:36 pm, edited 1 time in total.

User avatar
hoglet
Posts: 8901
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by hoglet » Tue Oct 23, 2018 8:03 pm

hoglet wrote:
Tue Oct 23, 2018 7:34 pm
So I was thinking of trying to replicate the cartridge (unless someone else has already done this, or you want to do this yourself).
I think it might even be possible to bodge this by piggy-backing a GAL16V8 on top of a 27C256.

The PAL would need:
- A14..A13 (output)
- A13..A5 (input)
- OE (input)
- CE (input)

Ian, do you know what PAL is actually used in your cartridge?

Dave

User avatar
IanB
Posts: 462
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB » Tue Oct 23, 2018 8:22 pm

hoglet wrote:
Tue Oct 23, 2018 7:34 pm
So I was thinking of trying to replicate the cartridge (unless someone else has already done this, or you want to do this yourself).
I was thinking of doing something more along the lines of the original board:

Quest.jpg

I hadn't really thought of doing a Master 128 style cartrige pcb (if that's what you meant) but that actually makes sense as the the original boards won't fit in a standard cartridge and are quite unwieldy when stuck in a tall Care style cartridge.

If you want to do that then go ahead. I suggest adding support for PLDs on both EPROM slots as there are at least 4 PALROMs:

Quest Paint (32K)
Conquest (Quest paint support ROM) (32k)
TED (Teletext editor) (32k)
Wapping Editor (64k)

BTW the original PAL was a PAL16L8

There are other PALROMs as well but I think they all used simple 2x16K bank switching
hoglet wrote:
Tue Oct 23, 2018 7:34 pm
Did support for these ever get added to MAME?
Pernod intended to add support but I don't know if he's got around to it yet.
Last edited by IanB on Thu Oct 25, 2018 12:06 am, edited 1 time in total.

User avatar
IanB
Posts: 462
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB » Tue Oct 23, 2018 8:36 pm

hoglet wrote:
Tue Oct 23, 2018 8:03 pm
I think it might even be possible to bodge this by piggy-backing a GAL16V8 on top of a 27C256.
That would probably work. Do you want me to trace the pinout of the existing board?

User avatar
hoglet
Posts: 8901
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by hoglet » Tue Oct 23, 2018 8:42 pm

IanB wrote:
Tue Oct 23, 2018 8:36 pm
That would probably work. Do you want me to trace the pinout of the existing board?
It would be interesting to see this, if you have the time.

But even with out this information, the docs you posted made it clear how it needs to work.

Dave

User avatar
IanB
Posts: 462
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB » Tue Oct 23, 2018 10:17 pm

hoglet wrote:
Tue Oct 23, 2018 8:42 pm
It would be interesting to see this, if you have the time.
This file contains EPROM images, pinouts and a repost of the Watford switching zones info:
PALPROMs.zip
(1.19 MiB) Downloaded 14 times
I haven't done a pinout for Wapping Editor yet.

I have one board with a socket for the PLD so if you use the same pinout I can verify that your design works if you get problems.

User avatar
hoglet
Posts: 8901
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by hoglet » Wed Oct 24, 2018 5:50 pm

IanB wrote:
Tue Oct 23, 2018 10:17 pm
This file contains EPROM images, pinouts and a repost of the Watford switching zones info:

PALPROMs.zip

I haven't done a pinout for Wapping Editor yet.

I have one board with a socket for the PLD so if you use the same pinout I can verify that your design works if you get problems.
Many thanks for all this Ian.

I've started a new thread for the PALPROM re-design so it doesn't get buried with RGBtoHDMI stuff here:
viewtopic.php?f=3&t=15924

Dave
Last edited by hoglet on Wed Oct 24, 2018 5:51 pm, edited 2 times in total.

User avatar
IanB
Posts: 462
Joined: Sun Sep 04, 2011 7:28 pm
Location: South Wales
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by IanB » Wed Oct 24, 2018 6:15 pm

hoglet wrote:
Wed Oct 24, 2018 5:50 pm
Many thanks for all this Ian.
I've started a new thread for the PALPROM re-design so it doesn't get buried with RGBtoHDMI stuff here:
viewtopic.php?f=3&t=15924
Nice one! I thought you'd been too quiet today!

I've been busy too, after running the TELETEXTR demo linked above by Tricky I came up with another change to the algorithm which fixed virtually all the artefacts in that demo and probably any mode 7 game using the 2x3 block graphics:
rgb_to_fb-oddeven.zip
(6.2 KiB) Downloaded 9 times
This does some limited odd with even and even with odd field comparisons. They only work with the 2x3 pixel blocks and not with normal characters but it makes a significant improvement so that the above demo is now virtually weave free.
I sometimes see random weave effects but they are not repeatable so most likely caused by the two vsyncs not locked and they seem to disapper when I set the pll to 624.
Last edited by IanB on Wed Oct 24, 2018 6:40 pm, edited 1 time in total.

User avatar
hoglet
Posts: 8901
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: RGB to HDMI using a Pi Zero and a small CPLD

Post by hoglet » Wed Oct 24, 2018 6:29 pm

I'll give this a go tomorrow.

I did look at the TELETEXTR and TELETEXT BAD APPLE demos today. They definitely show the value of deinterlacing!

Dave

BTW, Did you notice my question in the other thread about the Quest Paint manual?

Post Reply