Adding instructions to the sound thing should not be causing video corruption wtf.
Need to check that later, currently phoneposting on a tram amd i'll get sick if i stare at the phone.
Ok, I will check later. The audio did make video worse (maybe power noise effect again on video, but this time the whole scanline glitches, more like software timing error).
Can you post what timing values you have right now? Will check them at home.
(Wow I'm queasy even now. The tram lines here are really violent, they take hills and 90° turns at full speed like they're nothing and I'm prone to handheld-screen-in-moving-vehicle-related motion sickness)
Not sure which timing you wanted exactly, but ok
For PSRAM:
' For PSRAM (either type)
PSRAM_CLK = 56
PSRAM_SELECT = 57
PSRAM_BASE = 40
PSRAM_BANKS = 4 ' Only used to stop further banks from interfering
PSRAM_WAIT = 5
PSRAM_DELAY = 16
PSRAM_SYNC_CLOCK = false
PSRAM_SYNC_DATA = true
' Uncomment for slower memory clock
#define USE_PSRAM_SLOW
For video timing it's:
timing_lcd24_640x480
long VIDEO_CLKFREQ ' CLKFREQ
long 2 ' active line multiplier
long 10 ' V front porch
long 32 ' V sync
long 2 ' V back porch
long 64 ' extra pillar
long 640 ' blank line
long 14 ' H front porch
long 8 ' H sync
long 20 ' H back porch
long $08000000 ' Sync NCO
long $08000000 ' Pixel NCO
long 0 ' Alt-res NCO
long 16 + (16>>1)<<16 ' pixel clock pulses
long 1
For audio sample timing it's this:
DSP_SAMPLE_RATE = 32_000
DAC_SCALE = $FF00
DAC_CENTER = $8000 'DAC_SCALE/2
DAC_SCAS = $4000 'DAC_SCALE/4
dsp_dosample
' Output last sample to DAC, then compute next one
mov pa,dsp_daccenter
scas dsp_lsample,dsp_dacscas
setword pa,0-0, #1
mov pb,dsp_daccenter
scas dsp_rsample,dsp_dacscas
setword pb,0-0, #1
bitnot pa, #31
bitnot pb, #31
wypin pa,dsp_lpin
wypin pb,dsp_rpin
' setword pa,dsp_lsample,#0
' setword pa,dsp_rsample,#1
' cmps dsp_dpin,#0 wc
nop
' if_nc wxpin pa,dsp_dpin
addct1 audio_timestamp, ##_CLKFREQ/DSP_SAMPLE_RATE
dsp_run_ptch jmp #\dsp_run
.no_spcload
}
' setup pins (MEGA TODO FOR TIMING)
' Use PWM mode despite non-multiple-of-256 period
' It's just better.
wrpin ##P_NCO_DUTY|P_OE,dsp_lpin
wrpin ##P_NCO_DUTY|P_OE,dsp_rpin
wxpin #20,dsp_lpin
wxpin #20,dsp_rpin
wypin ##$8000_0000,dsp_lpin
wypin ##$8000_0000,dsp_rpin
drvl dsp_lpin
drvl dsp_rpin
' Setup event on left pin ready
mov pa,#%001_000000
add pa,dsp_lpin
setse1 pa
getct audio_timestamp
addct1 audio_timestamp, ##_CLKFREQ/DSP_SAMPLE_RATE
jmp #\sp_nextop '' GO!
Video glitches now seem fixed once I did this change below with an added waitx #15 to phase adjust the clock edge (so it may not be audio related, although it seemed to make a difference before):
' setup CLK pin (abuse breezeway entry)
debug(ubin_long(dira,dirb,outa,outb))
setcfrq nco_sync
getbyte pb,extravpins,#0
drvl pb
wypin bit31,pb
waitx #15 '****--- experimental waitx to sync clock
xinit ##$fffc,blank_color ' enter dummy command to ensure it stays in sync
waitx #511
jmp #video_entry
Thought you might think that but no, that was already done below. For a 16 clock pixel period waitx #15 is effectively like a "waitx -1" (which is not possible). So in this case the pixel clock is better one P2 clock earlier for the data to be read reliably. What is strange is that it's such a narrow window of good phases. For only ~20MHz clocking I'd expect far wider eye for good clocking. Maybe there's a lot of signal bouncing going on before things stabilize for all the parallel RGB data bits to be clocked - need to probe colour pins.
I realized I should try to dig up my old P2 tablet (800x480 res) and try to run this LCD test code too with necessary tweaks. It also uses a parallel 24 bit LCD interface but I'm not sure which P2 pins I ended up putting the sync's on though - might have been why I generated PWM outputs for Hsync/DE signals. That system has a 4 bit PSRAM so might be able to run something too. It does also have a VGA output and a USB host port.
Try a game with HiRes modes (Trials of Mana uses Mode 5 heavily - check if the text is readable. Make sure you have the newer ~6MB collection ROM or the japenese original - the older ~4MB english patch versions don't actually have hires fonts)
Just tested that and the hi-res text line is clear and readable and looks good. 👍 MisoYume seems pretty good, tried a bunch of things and some games fail to start up but I think that is to be expected. In general I think this is pretty decent on and sounds great too, especially on headphones. I went back to setting #5 for the WXPIN param and video is still okay with that other waitx change I made earlier.
Tried MegaYume, for some strange reason there are a lot of blank lines at the top of the menu pushing it down (maybe by design) and they are also seen in games. This seems weird as I only have 2 back porch lines in the timing so it should be able to start earlier on the screen. Here's some pics of that.
timing_lcd24_640x480
long VIDEO_CLKFREQ ' CLKFREQ
long 2 ' active line multiplier
long 10 ' V front porch
long 32 ' V sync
long 2 ' V back porch
long 0 ' extra pillar
long 640 ' blank line
long 16 ' H front porch
long 8 ' H sync
long 20 ' H back porch
long $0888888A ' Sync NCO
long $0888888A>>1 ' Pixel NCO
long 0 ' Alt-res NCO
long 15 + (15>>1)<<16 ' pixel clock pulses
long 1
I also needed to do a waitx #14 to get a decent image with the clock pin also inverted. Based on this and the other emulators I think we probably need a custom phase delay parameter in config.spin that people could tweak to do this waitx #phase_delay whenever it's set to non-negative values for example - like your other pin settings etc.
' setup CLK pin (abuse breezeway entry)
debug(ubin_long(dira,dirb,outa,outb))
setcfrq nco_sync
getbyte pb,extravpins,#0
drvl pb
wypin bit31,pb
waitx #14 '##### ----- needed this to get stable video output
xinit ##$fffc,blank_color ' enter dummy command to ensure it stays in sync
waitx #511
jmp #video_entry
Comments
Adding instructions to the sound thing should not be causing video corruption wtf.
Need to check that later, currently phoneposting on a tram amd i'll get sick if i stare at the phone.
Ok, I will check later. The audio did make video worse (maybe power noise effect again on video, but this time the whole scanline glitches, more like software timing error).
Can you post what timing values you have right now? Will check them at home.
(Wow I'm queasy even now. The tram lines here are really violent, they take hills and 90° turns at full speed like they're nothing and I'm prone to handheld-screen-in-moving-vehicle-related motion sickness)
Not sure which timing you wanted exactly, but ok
For PSRAM:
For video timing it's:
For audio sample timing it's this:
DSP_SAMPLE_RATE = 32_000 DAC_SCALE = $FF00 DAC_CENTER = $8000 'DAC_SCALE/2 DAC_SCAS = $4000 'DAC_SCALE/4 dsp_dosample ' Output last sample to DAC, then compute next one mov pa,dsp_daccenter scas dsp_lsample,dsp_dacscas setword pa,0-0, #1 mov pb,dsp_daccenter scas dsp_rsample,dsp_dacscas setword pb,0-0, #1 bitnot pa, #31 bitnot pb, #31 wypin pa,dsp_lpin wypin pb,dsp_rpin ' setword pa,dsp_lsample,#0 ' setword pa,dsp_rsample,#1 ' cmps dsp_dpin,#0 wc nop ' if_nc wxpin pa,dsp_dpin addct1 audio_timestamp, ##_CLKFREQ/DSP_SAMPLE_RATE dsp_run_ptch jmp #\dsp_run .no_spcload } ' setup pins (MEGA TODO FOR TIMING) ' Use PWM mode despite non-multiple-of-256 period ' It's just better. wrpin ##P_NCO_DUTY|P_OE,dsp_lpin wrpin ##P_NCO_DUTY|P_OE,dsp_rpin wxpin #20,dsp_lpin wxpin #20,dsp_rpin wypin ##$8000_0000,dsp_lpin wypin ##$8000_0000,dsp_rpin drvl dsp_lpin drvl dsp_rpin ' Setup event on left pin ready mov pa,#%001_000000 add pa,dsp_lpin setse1 pa getct audio_timestamp addct1 audio_timestamp, ##_CLKFREQ/DSP_SAMPLE_RATE jmp #\sp_nextop '' GO!Video glitches now seem fixed once I did this change below with an added waitx #15 to phase adjust the clock edge (so it may not be audio related, although it seemed to make a difference before):
' setup CLK pin (abuse breezeway entry) debug(ubin_long(dira,dirb,outa,outb)) setcfrq nco_sync getbyte pb,extravpins,#0 drvl pb wypin bit31,pb waitx #15 '****--- experimental waitx to sync clock xinit ##$fffc,blank_color ' enter dummy command to ensure it stays in sync waitx #511 jmp #video_entryWait, isn't that the same as inverting the clock polarity?
Thought you might think that but no, that was already done below. For a 16 clock pixel period waitx #15 is effectively like a "waitx -1" (which is not possible). So in this case the pixel clock is better one P2 clock earlier for the data to be read reliably. What is strange is that it's such a narrow window of good phases. For only ~20MHz clocking I'd expect far wider eye for good clocking. Maybe there's a lot of signal bouncing going on before things stabilize for all the parallel RGB data bits to be clocked - need to probe colour pins.
' Pre-setup clock pin getbyte pb,extravpins,#0 wrpin ##P_OE|P_PULSE|P_INVERT_OUTPUT|P_SYNC_IO,pb debug(uhex_long(hsync_breeze),udec(pb)) wxpin hsync_breeze,pbI realized I should try to dig up my old P2 tablet (800x480 res) and try to run this LCD test code too with necessary tweaks. It also uses a parallel 24 bit LCD interface but I'm not sure which P2 pins I ended up putting the sync's on though - might have been why I generated PWM outputs for Hsync/DE signals. That system has a 4 bit PSRAM so might be able to run something too. It does also have a VGA output and a USB host port.
Just tested that and the hi-res text line is clear and readable and looks good. 👍 MisoYume seems pretty good, tried a bunch of things and some games fail to start up but I think that is to be expected. In general I think this is pretty decent on and sounds great too, especially on headphones. I went back to setting #5 for the WXPIN param and video is still okay with that other waitx change I made earlier.
Tried MegaYume, for some strange reason there are a lot of blank lines at the top of the menu pushing it down (maybe by design) and they are also seen in games. This seems weird as I only have 2 back porch lines in the timing so it should be able to start earlier on the screen. Here's some pics of that.
I also needed to do a waitx #14 to get a decent image with the clock pin also inverted. Based on this and the other emulators I think we probably need a custom phase delay parameter in config.spin that people could tweak to do this waitx #phase_delay whenever it's set to non-negative values for example - like your other pin settings etc.