@rogloh said:
... But I think the NCO Duty mode from the P2 sounded cleaner than sawtooth PWM - although to be fair I'd limited that to 8 bits to be as close to what the RasPi puts out as I could match in the SNECog demo. The NCO duty mode probably adds a few more bits of resolution at a P2 clock of 200MHz.
Assuming the DAC accepts it, PDM is even noise across all amplitudes/ratios. The noise is pushed right up into its highest resolution switching in the MHz.
PWM has its worst noise at the 50% ratio - ie: zero crossing, low amplitudes. Exactly where it will be most audible.
PWM makes sense where switching losses are more important than audible noise. Power supplies and electric motors being the poster boys.
I do wonder how class D audio amps are designed. Do they use the digital data directly? Or they are all still designed to use a analogue line in? I've never looked ... I suppose that's what's going on with the wireless speakers, they take digital audio and directly modulate that without any analogue stages at all. So the real selling point is not the wirelessness at all (Since the power wires are still needed anyway), it's the direct modulation.
Awful photo but here's the LCD working with my hacked up video driver doing parallel output. In the end it is a little fussy about its timing. If I start messing with the back porch or hsync widths it seems to offset the picture on the screen, also different vertical back porches offsets it down. You can vary the front porches though and it is okay with that.
I found the LCD screen does work all the way from 20MHz to 340MHz P2 clock frequencies I tested (at different refresh rates). I do see a little corruption of text on white backgrounds, not sure if it is a signal integrity type of issue or something else...still tweaking, and the clock alignment might not always be centered - things do change if I add some nops to the startup code.
@rogloh said:
Awful photo but here's the LCD working with my hacked up video driver doing parallel output. In the end it is a little fussy about its timing. If I start messing with the back porch or hsync widths it seems to offset the picture on the screen, also different vertical back porches offsets it down. You can vary the front porches though and it is okay with that.
That's what happens when you omit the DE signal.
Unrelatedly, tried my code? (see prev. page) I haven't been able to scope it yet, but it should at least generate a clock and some signals.
@rogloh said:
Awful photo but here's the LCD working with my hacked up video driver doing parallel output. In the end it is a little fussy about its timing. If I start messing with the back porch or hsync widths it seems to offset the picture on the screen, also different vertical back porches offsets it down. You can vary the front porches though and it is okay with that.
That's what happens when you omit the DE signal.
Yeah I will try to add the DE signal back in to see if it changes much there when the back porch widths are modified. I've also modified my driver code for parallel LCD output such that H & V syncs now both come from the bits in the immediate streamer data during blanking so the extra DE signal is going to be very simple to add. As the LCD seems to use negative syncs I do need to invert the sync output pins in the pin configuration mode with a wrpin because you can't easily control the state of the lower 8 control bits during active video output (both are always outputting a 0 there, automatically by the P2 HW).
Unrelatedly, tried my code? (see prev. page) I haven't been able to scope it yet, but it should at least generate a clock and some signals.
Nice. We may have to invert the video output RGB data pins for some weird reason. I'm still looking into it but the colours seen were sort of the complements of what I expected, but I could have a bug somewhere there, so not 100% confident on that yet.
UPDATE: Actually I misread your comment above. No I haven't looked at that yet, still getting the LCD image perfected so I know what the issues are.
@Wuerfel_21 I grabbed your lcd24-test branch build and configured it. Was very close but no cigar. To get something to display I just had to hack the NeoVGA code to invert the 3 control bits DE/HS/VS (DE=1 means data is valid, plus this device only wants negative syncs). But it was still offset on the screen with the default timing - not sure why DE is not fixing that. I tweaked it to use the RasPi timing I found and got a valid-ish bootup screen (apart from the right edge and pixel shimmer which might be clock phase or sync timing related).
After loading a game the video looked better but the sound was rather messed up. Heard a loud buzzing sound and only faint real music/gameplay sounds - maybe audio offsets/math is wrong for NCO mode or that hasn't been looked at yet?
UPDATE: ok I see you have not enabled NCO mode - will try to modify that in your code to see if it helps...
I sort of wonder if usbnew might still be messing with the USB base pins somehow given that the PWM pins are at 32,33 while D+/D- are on 34, 35 and I did also see that random garbage was being read into the USB keyboard buffer in your hidpad_to_vga test app if SNECog audio is playing while this test program is running. It's like there is data pin crossover or leakage somewhere between audio and USB. I wonder if that old USB repo pin is getting enabled or something?
In my own p2videodrv code I've added a clock pin sync up hack to lock the transitions of the clock signal to some fixed phase offset from the RGB pixel data transitions and the corruption problem I saw earlier with white backgrounds is also resolved (which was my own bug). Text is very crisp now and I need a magnifying glass to see the pixels - they are tiny. I think the LCD is stable when fed a stable source. I just would like to be able to modify the timing more without the window floating around when the back porch is varied, I was sort of hoping DE would fix that. At one time I thought it had as I could freely modify the timing parameters, but I can't reproduce it again and am wondering if I was even modifying the correct driver file in the same folder or some other file elsewhere now.
I also recently noticed separately that audio buzz when the USB is on if the PWM GPIO pins 32 & 33 are left floating. I now just drive it with a zero until some valid audio is started and the buzz is reduced. Got to find the source of it. Didn't hear it initially while first trying getting any sound to work.
@Wuerfel_21 I got sound working on your NeoYume - hides most of the buzz now but doesn't fully eliminate it. You can see my major hacks here in the zipped archive of changed files:
I do see occasional screen corruption in game which could be an artefact of heavily reducing the blanking and it doesn't always get the timing right at the startup - so there is probably random clock phase there. Might be able to pad more into hsync front porch. It seems to want the hsync and back porch widths as is though, plus vsync and vbp timing or it will offset the screen.
I've noticed if I download a new version via the PropPlug which involves a P2 reset I also need to power cycle the system then too or I get a failure to read the SD card. That's a bit of a PITA and would be nice if fixable somehow. Perhaps final SD or flash boot may behave differently...?
It's actually a fun little system to play games on. Screen looks so crisp when working right.
@rogloh said:
I do see occasional screen corruption in game which could be an artefact of heavily reducing the blanking and it doesn't always get the timing right at the startup - so there is probably random clock phase there. Might be able to pad more into hsync front porch. It seems to want the hsync and back porch widths as is though, plus vsync and vbp timing or it will offset the screen.
You can not and should not mess with the vertical timing. When changing horizontal timing, you should keep the total number of cycles the same, otherwise the whole timing will be too fast or slow.
You can also try loading the 240p test suite ROM to get some test patterns. (make sure you go to the options and set the full 320 width mode)
I've noticed if I download a new version via the PropPlug which involves a P2 reset I also need to power cycle the system then too or I get a failure to read the SD card. That's a bit of a PITA and would be nice if fixable somehow. Perhaps final SD or flash boot may behave differently...?
There's some SD cards that do this for unknown reasons, try a different one.
@rogloh
Okay, so that that timing modification works at all is a miracle, it's totally bogus. You're changing the total scanline count (NEVER DO THIS) and also everything would be running way too fast, 70Hz roundabout. (The correct speed is 59.599 Hz - notably slightly slower than the NTSC standard 59.98). This is also probably causing glitches, since the 68k code now has almost no VBlank time to work with and the Blitter code was marginally handling worst-case lines to begin with.
Basically, don't ever attempt to change the total number of cycles, you can only move them around. E.g. if it doesn't care about front porches, you can move the extra cycles/lines there and be hopefully unbothered about it.
@Wuerfel_21 said:
Okay, so that that timing modification works at all is a miracle, it's totally bogus.
Yeah I know, major hacks is what I'd mentioned. I'd like us to be able to preserve your timing but unless the DE thing can be resolved I think it will need to be reallocated across front porches for vertical and horizontal to avoid visible offsets on screen. I'll adjust it here and retest to see if that glitchiness goes away. BTW the menu screen at the starts seems more prone to problems in the pixel clock sync than the gameplay.
Um, yeah I hadn't changed your setting for the clock yet - I believe I've set my driver to to an inverted output, but I also adjusted via a waitx to try to center it which may have altered it again.
EDIT : Also you used sync_io and I didn't set that yet. It makes more sense to align to latch the clock in the P2.
Yes that helps by inverting the clock. Pixels in MS game are spot on now. No bad glitching anymore with the timing change I made too.
There is still some visible corruption however in the initial menu on the right. Almost seems like the timing for that screen is different to the game play?
I'll also try scaling back the audio sample values by a bit or two, maybe I'm just overdriving the on board amp...
EDIT: Also the background buzz seems louder when I see that corruption. Perhaps I need to adjust slew rate of the PWM output pins by adding a internal resistor drive level or use the bitDAC.
All video tests looked absolutely spot on (to me at least) if the main menu was stable initially. If not then it was also corrupted down the right side in the tests with flickering garbage near the end of some lines.
Something can get this thing into a bad state from startup and then it's hit or miss after that. But if it starts up cleanly it's nice.
When I get a chance (perhaps tomorrow) I'll try to record the audio output from the 240p audio tests and attach a zipped wave file or something. You'll hear some weird audio tailoff effects at the end of the notes of the FM synth tests and then the residual buzz. Also L+R channels are flipped according to real headphones and the internal speaker output is mono.
@rogloh said:
All video tests looked absolutely spot on (to me at least) if the main menu was stable initially. If not then it was also corrupted down the right side in the tests with flickering garbage near the end of some lines.
Something can get this thing into a bad state from startup and then it's hit or miss after that. But if it starts up cleanly it's nice.
I suppose you can't scope out the signals for when this is happening vs not happening?
Do you think this is the driver or the LCD controller getting into a bad state?
Also, what timing are you setting now? (I think setting any of the horizontal timings to super-low values like you had is highly problematic and might indeed cause some weird timing misalignment where the streamer runs out of commands)
When I get a chance (perhaps tomorrow) I'll try to record the audio output from the 240p audio tests and attach a zipped wave file or something. You'll hear some weird audio tailoff effects at the end of the notes of the FM synth tests and then the residual buzz. Also L+R channels are flipped according to real headphones and the internal speaker output is mono.
I didn't look at the audio part at all yet - it's all a bit tricky with OPNxcog; OPN2cog I think was my first big P2ASM project, so it's kindof a mess and that carries through to the OPNBcog in NeoYume (that, if you ever thought about that, doesn't exist as a standalone lib because it's hard-tied to the NeoYume memory arbiter).
Getting weird trails from low-amplitude-but-not-quite-zero signals from NCO_DUTY mode is just how that is, a similar problem happens on P1 (where this is the default / only acceptable way to produce audio).
One thing I'm thinking is that maybe the low-pass filter doesn't quite return to zero in all cases (i.e. gets stuck at -1 instead of returning to 0) due to rounding and that's what can cause duty mode problems. (unrelatedly, also try setting P_SYNC_IO on this).
For testing you can just bypass it (mov opn_arg1, opn_outl directly etc), but it will sound too harsh (or maybe not - if the filtering applied to the PWM signal is too aggressive disabling the software filter might cancel that out)
Currently the delta applied to the filter values is rounded down (because it's using SCAS, which is essentially MULS+SAR), so it can get stuck just below zero. I think to fix it I need to change it to round away from zero. I think this is possible without adding any instructions...
To fix the left/right issue, just change the config (duh).
Comments
In that case, PDM is probably what the device wants then. The RPi shouldn't have been using PWM at all.
Assuming the DAC accepts it, PDM is even noise across all amplitudes/ratios. The noise is pushed right up into its highest resolution switching in the MHz.
PWM has its worst noise at the 50% ratio - ie: zero crossing, low amplitudes. Exactly where it will be most audible.
PWM makes sense where switching losses are more important than audible noise. Power supplies and electric motors being the poster boys.
I do wonder how class D audio amps are designed. Do they use the digital data directly? Or they are all still designed to use a analogue line in? I've never looked ... I suppose that's what's going on with the wireless speakers, they take digital audio and directly modulate that without any analogue stages at all. So the real selling point is not the wirelessness at all (Since the power wires are still needed anyway), it's the direct modulation.
Awful photo but here's the LCD working with my hacked up video driver doing parallel output. In the end it is a little fussy about its timing. If I start messing with the back porch or hsync widths it seems to offset the picture on the screen, also different vertical back porches offsets it down. You can vary the front porches though and it is okay with that.
I found the LCD screen does work all the way from 20MHz to 340MHz P2 clock frequencies I tested (at different refresh rates). I do see a little corruption of text on white backgrounds, not sure if it is a signal integrity type of issue or something else...still tweaking, and the clock alignment might not always be centered - things do change if I add some nops to the startup code.
That's what happens when you omit the DE signal.
Unrelatedly, tried my code? (see prev. page) I haven't been able to scope it yet, but it should at least generate a clock and some signals.
Yeah I will try to add the DE signal back in to see if it changes much there when the back porch widths are modified. I've also modified my driver code for parallel LCD output such that H & V syncs now both come from the bits in the immediate streamer data during blanking so the extra DE signal is going to be very simple to add. As the LCD seems to use negative syncs I do need to invert the sync output pins in the pin configuration mode with a wrpin because you can't easily control the state of the lower 8 control bits during active video output (both are always outputting a 0 there, automatically by the P2 HW).
Nice. We may have to invert the video output RGB data pins for some weird reason. I'm still looking into it but the colours seen were sort of the complements of what I expected, but I could have a bug somewhere there, so not 100% confident on that yet.
UPDATE: Actually I misread your comment above. No I haven't looked at that yet, still getting the LCD image perfected so I know what the issues are.
@Wuerfel_21 I grabbed your lcd24-test branch build and configured it. Was very close but no cigar. To get something to display I just had to hack the NeoVGA code to invert the 3 control bits DE/HS/VS (DE=1 means data is valid, plus this device only wants negative syncs). But it was still offset on the screen with the default timing - not sure why DE is not fixing that. I tweaked it to use the RasPi timing I found and got a valid-ish bootup screen (apart from the right edge and pixel shimmer which might be clock phase or sync timing related).
After loading a game the video looked better but the sound was rather messed up. Heard a loud buzzing sound and only faint real music/gameplay sounds - maybe audio offsets/math is wrong for NCO mode or that hasn't been looked at yet?
UPDATE: ok I see you have not enabled NCO mode - will try to modify that in your code to see if it helps...
I sort of wonder if usbnew might still be messing with the USB base pins somehow given that the PWM pins are at 32,33 while D+/D- are on 34, 35 and I did also see that random garbage was being read into the USB keyboard buffer in your hidpad_to_vga test app if SNECog audio is playing while this test program is running. It's like there is data pin crossover or leakage somewhere between audio and USB. I wonder if that old USB repo pin is getting enabled or something?
In my own p2videodrv code I've added a clock pin sync up hack to lock the transitions of the clock signal to some fixed phase offset from the RGB pixel data transitions and the corruption problem I saw earlier with white backgrounds is also resolved (which was my own bug). Text is very crisp now and I need a magnifying glass to see the pixels - they are tiny. I think the LCD is stable when fed a stable source. I just would like to be able to modify the timing more without the window floating around when the back porch is varied, I was sort of hoping DE would fix that. At one time I thought it had as I could freely modify the timing parameters, but I can't reproduce it again and am wondering if I was even modifying the correct driver file in the same folder or some other file elsewhere now.
I also recently noticed separately that audio buzz when the USB is on if the PWM GPIO pins 32 & 33 are left floating. I now just drive it with a zero until some valid audio is started and the buzz is reduced. Got to find the source of it. Didn't hear it initially while first trying getting any sound to work.
@Wuerfel_21 I got sound working on your NeoYume
- hides most of the buzz now but doesn't fully eliminate it. You can see my major hacks here in the zipped archive of changed files:
I do see occasional screen corruption in game which could be an artefact of heavily reducing the blanking and it doesn't always get the timing right at the startup - so there is probably random clock phase there. Might be able to pad more into hsync front porch. It seems to want the hsync and back porch widths as is though, plus vsync and vbp timing or it will offset the screen.
I've noticed if I download a new version via the PropPlug which involves a P2 reset I also need to power cycle the system then too or I get a failure to read the SD card. That's a bit of a PITA and would be nice if fixable somehow. Perhaps final SD or flash boot may behave differently...?
It's actually a fun little system to play games on. Screen looks so crisp when working right.
Will check it out later.
You can not and should not mess with the vertical timing. When changing horizontal timing, you should keep the total number of cycles the same, otherwise the whole timing will be too fast or slow.
You can also try loading the 240p test suite ROM to get some test patterns. (make sure you go to the options and set the full 320 width mode)
There's some SD cards that do this for unknown reasons, try a different one.
@rogloh
Okay, so that that timing modification works at all is a miracle, it's totally bogus. You're changing the total scanline count (NEVER DO THIS) and also everything would be running way too fast, 70Hz roundabout. (The correct speed is 59.599 Hz - notably slightly slower than the NTSC standard 59.98). This is also probably causing glitches, since the 68k code now has almost no VBlank time to work with and the Blitter code was marginally handling worst-case lines to begin with.
Basically, don't ever attempt to change the total number of cycles, you can only move them around. E.g. if it doesn't care about front porches, you can move the extra cycles/lines there and be hopefully unbothered about it.
Yeah I know, major hacks is what I'd mentioned. I'd like us to be able to preserve your timing but unless the DE thing can be resolved I think it will need to be reallocated across front porches for vertical and horizontal to avoid visible offsets on screen. I'll adjust it here and retest to see if that glitchiness goes away. BTW the menu screen at the starts seems more prone to problems in the pixel clock sync than the gameplay.
May need to invert the clock pin setup, too? (what edge does it want to latch on?)
Um, yeah I hadn't changed your setting for the clock yet - I believe I've set my driver to to an inverted output, but I also adjusted via a waitx to try to center it which may have altered it again.
EDIT : Also you used sync_io and I didn't set that yet. It makes more sense to align to latch the clock in the P2.
I pushed a cleaner method for H/V/DE pin polarity. This would also support inverting the color pins.
Yes that helps by inverting the clock. Pixels in MS game are spot on now. No bad glitching anymore with the timing change I made too.
There is still some visible corruption however in the initial menu on the right. Almost seems like the timing for that screen is different to the game play?
I'll also try scaling back the audio sample values by a bit or two, maybe I'm just overdriving the on board amp...
EDIT: Also the background buzz seems louder when I see that corruption. Perhaps I need to adjust slew rate of the PWM output pins by adding a internal resistor drive level or use the bitDAC.
yeah idk what's causing that. It should be the same timing throughout.
Please get 240ptest for testing this.
Here, I'll even give you whatever known-good outdated version I use.
Ok so where to put these files in the SD filesystem? Directly under neoyume folder or some named subfolder?
EDIT: ok subfolder is good
Yeah it's just another game for this purpose.
What you want is
All video tests looked absolutely spot on (to me at least) if the main menu was stable initially. If not then it was also corrupted down the right side in the tests with flickering garbage near the end of some lines.
Something can get this thing into a bad state from startup and then it's hit or miss after that. But if it starts up cleanly it's nice.
When I get a chance (perhaps tomorrow) I'll try to record the audio output from the 240p audio tests and attach a zipped wave file or something. You'll hear some weird audio tailoff effects at the end of the notes of the FM synth tests and then the residual buzz. Also L+R channels are flipped according to real headphones and the internal speaker output is mono.
I suppose you can't scope out the signals for when this is happening vs not happening?
Do you think this is the driver or the LCD controller getting into a bad state?
Also, what timing are you setting now? (I think setting any of the horizontal timings to super-low values like you had is highly problematic and might indeed cause some weird timing misalignment where the streamer runs out of commands)
I didn't look at the audio part at all yet - it's all a bit tricky with OPNxcog; OPN2cog I think was my first big P2ASM project, so it's kindof a mess and that carries through to the OPNBcog in NeoYume (that, if you ever thought about that, doesn't exist as a standalone lib because it's hard-tied to the NeoYume memory arbiter).
Getting weird trails from low-amplitude-but-not-quite-zero signals from NCO_DUTY mode is just how that is, a similar problem happens on P1 (where this is the default / only acceptable way to produce audio).
One thing I'm thinking is that maybe the low-pass filter doesn't quite return to zero in all cases (i.e. gets stuck at -1 instead of returning to 0) due to rounding and that's what can cause duty mode problems. (unrelatedly, also try setting P_SYNC_IO on this).
For testing you can just bypass it (
mov opn_arg1, opn_outldirectly etc), but it will sound too harsh (or maybe not - if the filtering applied to the PWM signal is too aggressive disabling the software filter might cancel that out)Currently the delta applied to the filter values is rounded down (because it's using SCAS, which is essentially MULS+SAR), so it can get stuck just below zero. I think to fix it I need to change it to round away from zero. I think this is possible without adding any instructions...
To fix the left/right issue, just change the config (duh).