Flexprop is still not good. While it managed to compile the neoyume, it cannot compile the player with this error:
/home/pik33/Programowanie/P2-retromachine/Propeller/P2P16/player29v.p2asm:55588: error: fit 480 failed: pc is 608
"/home/pik33/Programy/flexprop_splurp/bin/flexspin" -2 -l --tabs=8 -D_BAUD=115200 -O1 --charset=utf8 -I "/home/pik33/Programy/flexprop/include" "/home/pik33/Programowanie/P2-retromachine/Propeller/P2P16/player29v.bas" -DFF_USE_LFN
Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2022 Total Spectrum Software Inc.
Version 5.9.12-beta-v5.9.11-22-g8ffebab4 Compiled on: Jun 7 2022
/home/pik33/Programowanie/P2-retromachine/Propeller/P2P16/player29v.p2asm:55588: error: fit 480 failed: pc is 608
player29v.bas
|-vg001.spin2
|-|-psram.spin2
|-|-|-psram16drv.spin2
|-retrocog.spin2
|-trackerplayer.spin2
|-audio093b-8-sc.spin2
|-sidcog8.spin2
|-psram.spin2
|-spccog.spin2
|-a6502-1.spin2
readdata.spin
_mount.c
fmt.c
strings.bas
dir.bas
errno.c
vfs.c
posixio.c
fatfs_vfs.c
|-fatfs.cc
bufio.c
stat.c
strncpy.c
strncat.c
strncmp.c
basic_dir.c
strncpy.c
memcmp.c
strchr.c
sdmm.cc
time.c
localtim.c
stat.c
malloc.c
opendir.c
ioctl.c
opendir.c
posixio.c
ioctl.c
getenv.c
gettimeofday.c
remove.c
rename.c
ctype.c
malloc.c
strncmp.c
bufio.c
player29v.p2asm
Done.
child process exited abnormally
Finished at Tue Jun 7 14:10:08 2022
while the good old 5.9.10 I have here compiles it as expected.
I tried the fresh neoyume: all the same. The game works, the sound plays, the picture is garbled. What the hell is different between getting audio samples and sprite data? I cannot debug this here and now as I don't want to keep the flexprop which cannot compile the player, and 5.9.10 which I reverted to, cannot compile the neoyume
Maybe I can manage to order several P2-EC32s for the university project so I will have access to more of these board to play and compare. As they are available only in Parallax shop, the expected time is 2-3 months, if any.
I have a working 5.9.12 at home: I only have to not forget to use a pendrive or something to move it here. Meanwhile I tried to set the optimization level to 2 in 5.9.10 and the player. The standard result was a big list of errors, but this time the flexprop simply crashed. The only way to go further is kill -9
I thought I was out of ideas, but here's another one. Given the SD pins and the PSRAM CLK/CE are adjacent to each other on the P2 EDGE what if somehow there is a shorted pin on pik33's board and one signal can interfere with the other? Is there any chance it could corrupt just the sprite data transfer from SD based on the logical sequence of startup operations and COGs that execute code at the same time? Maybe for the other SD reads that do work ok, the PSRAM is actually idle, but the way the sprite code works is different and its operation at that time could corrupt the transfer?
I have to found when and where the data goes corrupted. There are several stages:
(1) the sprite data is loaded from SD to PSRAM
(2) the sprite data is fetched from PSRAM somewhere to the hub
(3) the sprite data is displayed on the screen
There is something wrong somewhere in this chain. It has to be tested to find where something goes bad. Is it a cog failing, or a PSRAM failing, or timings too tight, or something else. The timings should not be a problem as I tried the code with a lower clock and it still displays the same Smile until the clock is too low for the PSRAM delays set, and then there is no display at all. Of course I can change these delays, Maybe in the evening. But if it is failing because of timings, the pattern on the screen would change when the clock is set lower. There is something systematic. Maybe a faulty cog which does something wrong and needs a specific pattern of instructions to fail.
There is 68000 working and sound playing. There is also my player fully working, which also uses PSRAM. If there is a fault somewhere in PSRAM, the symptoms should be bad pixels here and there but not a full garbled screen. What process decide where these pixels are send to? There may be good pixels read from PSRAM, but sent to the wrong place.
@pik33 said:
There is 68000 working and sound playing. There is also my player fully working, which also uses PSRAM. If there is a fault somewhere in PSRAM, the symptoms should be bad pixels here and there but not a full garbled screen. What process decide where these pixels are send to? There may be good pixels read from PSRAM, but sent to the wrong place.
Soooo, high-level overview of rendering works:
LSPC cog scans through VRAM looking for sprites that need to render on the current line and fills the spr_buffer with up to 96 entries (unused slots are filled with sentinels).
Memory arbiter cog goes through spr_buffer and writes sprite data over the placeholders written by LSPC
Blitter cog clears draw_buffer with background color, goes through spr_buffer and draws all sprites onto the buffer. Then it draws the fix layer on top.
VGA cog scans out draw_buffer
draw_buffer is simply a 320x2 truecolor double linebuffer (with 16 longs padding either side so it doesn't need to clip).
spr_buffer is a 4-line ringbuffer structure wherein each sprite slot has a 16 byte entry:
' temporary data associated with sprite rendering (4 lines * 96 sprites))
' format is as such:
' 2 longs buffer area for CROM data
' long CROM pointer (minus 1: end of active list)
' word %PPPP_PPPP_SSSS_xxxH
' P -> palette
' S -> H shrink value
' H -> mirror flag
' word X position + 15
spr_buffer long 0[96*4*4]
I hope that helps in following along with the code.
If the issue is clock related, and what you are seeing occurs just as the clock passes a consistent threshold, then could we increase the clock on working modules until we see the same display corruption?
@VonSzarvas said:
If the issue is clock related, and what you are seeing occurs just as the clock passes a consistent threshold, then could we increase the clock on working modules until we see the same display corruption?
Might work, there should be a bit of upwards range before the framerate goes past the monitor's sync limit.
@Wuerfel_21 said:
Might just also try ye olde hairdryer.
Yep, hairdryer can induce thermal failure. But it's really just intermittent white 16x1 slivers (presumably color 15 of whatever palette?) showing up in the display and then the 68000 violently crashes long before the screen becomes completely garbled.
Here's that again, but on video. Gets significantly more garbled before it crashes (and without spewing garbage into VRAM, too), presumably because of low CPU activity. Weird how the audio just stops entirely. That should not happen under any circumstance. I think the YM2610 cog just straightup crashes (if the Z80 crashed it'd leave hanging notes).
Video stays operational because nothing critical comes from hubRAM for the duration.
PS: I've worked out that cordic ops will also glitch when operating at or near PLL's self-limit. So, both hubRAM R/W accesses and cordic ops will corrupt.
After several hours of fruitless debugging I started to compare this:
with this
frame by frame. What is interesting is this neo-geo logo at the start. It seems to be made with sprites which are vertically and horizontally shrunk and mirrored in the real time.
On my board the sprite data was not vertically shrunk.It was slid down and up instead. Is the video memory corrupt somewhat?
My knowledge about how this console work is still way too low.
It's probably either reading from a bad sprite address in PSRAM, or reading bad sprite data loaded into the PSRAM at the right address, or the PSRAM addressing itself internally in the chip is bad for some reason. Maybe the address portion of the sprite RAM read request is being corrupted on the PSRAM data bus...?
Now what is read from the PSRAM is sent to the outer space. Instead, the sprite data is filled by $123456789abcdef0
The result looks like this. These false sprites are blinking, they make patterns, 2 line/2 line... I expected solid, non-blinking objects. What can be damaged in this P2 to do such things?
(and what I am doing wrong with YT? The film can be only started after clicking at YouTube icon)
I expected something like this: solid gradient blocks. Not this blinky stuff I got. It is not a PSRAM that fails, but I have to find what it is... The clock doesn't matter here, I managed to go under 300 MHz (with a monitor which can do 40 Hz on VGA)
I tried wrlong instead, no change. It seems something breaks earlier than this. I tried to set constants instead of data in blitter cog (mov to these nibbles). There seems to be wrong places on the screen to write to.
And in unchanged program, there is one (moving, 16px) column which displays proper data, but in the 2 lines data/2 lines nothing pattern.
A good wiki Several experiments later: either something writes bad data into VRAM or the blitter cog does something wrong.
... go to blitter cog. It seems to blit data that are not sprites... or something. I set constant palette for all of them, then I set $1234567890... as the pixel data, regardless of what is set there by the game, yet I have lines with a constant color on the screen.
@pik33 said:
... go to blitter cog. It seems to blit data that are not sprites... or something. I set constant palette for all of them, then I set $1234567890... as the pixel data, regardless of what is set there by the game, yet I have lines with a constant color on the screen.
there is no more blinking except several artifacts here and there and I got these gradient filled sprites! As if the blitter blits the same sprite buffer as the memory manager fills at the same time.
Add several nops between if_c jmp and wrfast and the picture starts blinking again.
I have to go to sleep now. I managed to destroy the code so tomorrow I will start again fron rm -rf and git clone.The line counter is at hub $F8 and maybe these low hub locations are not working as expected. To be tested tomorrow.
Comments
Flexprop is still not good. While it managed to compile the neoyume, it cannot compile the player with this error:
/home/pik33/Programowanie/P2-retromachine/Propeller/P2P16/player29v.p2asm:55588: error: fit 480 failed: pc is 608while the good old 5.9.10 I have here compiles it as expected.
I tried the fresh neoyume: all the same. The game works, the sound plays, the picture is garbled. What the hell is different between getting audio samples and sprite data? I cannot debug this here and now as I don't want to keep the flexprop which cannot compile the player, and 5.9.10 which I reverted to, cannot compile the neoyume
Maybe I can manage to order several P2-EC32s for the university project so I will have access to more of these board to play and compare. As they are available only in Parallax shop, the expected time is 2-3 months, if any.
Wow, that's a good one, busted af. @ersmith
I have a working 5.9.12 at home: I only have to not forget to use a pendrive or something to move it here. Meanwhile I tried to set the optimization level to 2 in 5.9.10 and the player. The standard result was a big list of errors, but this time the flexprop simply crashed. The only way to go further is kill -9
I thought I was out of ideas, but here's another one. Given the SD pins and the PSRAM CLK/CE are adjacent to each other on the P2 EDGE what if somehow there is a shorted pin on pik33's board and one signal can interfere with the other? Is there any chance it could corrupt just the sprite data transfer from SD based on the logical sequence of startup operations and COGs that execute code at the same time? Maybe for the other SD reads that do work ok, the PSRAM is actually idle, but the way the sprite code works is different and its operation at that time could corrupt the transfer?
Nope, all the PSRAM writes (except fills) are synchronous. And as said, problem just does not look like static bad data in RAM.
I have to found when and where the data goes corrupted. There are several stages:
(1) the sprite data is loaded from SD to PSRAM
(2) the sprite data is fetched from PSRAM somewhere to the hub
(3) the sprite data is displayed on the screen
There is something wrong somewhere in this chain. It has to be tested to find where something goes bad. Is it a cog failing, or a PSRAM failing, or timings too tight, or something else. The timings should not be a problem as I tried the code with a lower clock and it still displays the same Smile until the clock is too low for the PSRAM delays set, and then there is no display at all. Of course I can change these delays, Maybe in the evening. But if it is failing because of timings, the pattern on the screen would change when the clock is set lower. There is something systematic. Maybe a faulty cog which does something wrong and needs a specific pattern of instructions to fail.
There is 68000 working and sound playing. There is also my player fully working, which also uses PSRAM. If there is a fault somewhere in PSRAM, the symptoms should be bad pixels here and there but not a full garbled screen. What process decide where these pixels are send to? There may be good pixels read from PSRAM, but sent to the wrong place.
Soooo, high-level overview of rendering works:
spr_bufferwith up to 96 entries (unused slots are filled with sentinels).spr_bufferand writes sprite data over the placeholders written by LSPCdraw_bufferwith background color, goes throughspr_bufferand draws all sprites onto the buffer. Then it draws the fix layer on top.draw_bufferdraw_bufferis simply a 320x2 truecolor double linebuffer (with 16 longs padding either side so it doesn't need to clip).spr_bufferis a 4-line ringbuffer structure wherein each sprite slot has a 16 byte entry:I hope that helps in following along with the code.
If the issue is clock related, and what you are seeing occurs just as the clock passes a consistent threshold, then could we increase the clock on working modules until we see the same display corruption?
Might work, there should be a bit of upwards range before the framerate goes past the monitor's sync limit.
Might just also try ye olde hairdryer.
Yep, hairdryer can induce thermal failure. But it's really just intermittent white 16x1 slivers (presumably color 15 of whatever palette?) showing up in the display and then the 68000 violently crashes long before the screen becomes completely garbled.
Here's that again, but on video. Gets significantly more garbled before it crashes (and without spewing garbage into VRAM, too), presumably because of low CPU activity. Weird how the audio just stops entirely. That should not happen under any circumstance. I think the YM2610 cog just straightup crashes (if the Z80 crashed it'd leave hanging notes).
Video stays operational because nothing critical comes from hubRAM for the duration.
PS: I've worked out that cordic ops will also glitch when operating at or near PLL's self-limit. So, both hubRAM R/W accesses and cordic ops will corrupt.
PPS: hubRAM is a smidgen worse.
Since I guess I'll have a blab about the new emulation happenings at Live Forum next week, I'm throwing together some high-quality slides.
big rom hot cheese.
big rom hot cheese, with some pickles.
After several hours of fruitless debugging I started to compare this:
with this
frame by frame. What is interesting is this neo-geo logo at the start. It seems to be made with sprites which are vertically and horizontally shrunk and mirrored in the real time.
On my board the sprite data was not vertically shrunk.It was slid down and up instead. Is the video memory corrupt somewhat?
My knowledge about how this console work is still way too low.
It's probably either reading from a bad sprite address in PSRAM, or reading bad sprite data loaded into the PSRAM at the right address, or the PSRAM addressing itself internally in the chip is bad for some reason. Maybe the address portion of the sprite RAM read request is being corrupted on the PSRAM data bus...?
I did this hack about line 2990:
wrfast ma_bit31,##$7C000' ptrb waitxmt fltl ma_psram_pinfield setq ma_nco_slow xcont ma_psram_readspr_cmd,#0 waitxfi drvl #PSRAM_SELECT wrfast ma_bit31,ptrb wflong ##$12345678 wflong ##$9abcdef0Now what is read from the PSRAM is sent to the outer space. Instead, the sprite data is filled by $123456789abcdef0
The result looks like this. These false sprites are blinking, they make patterns, 2 line/2 line... I expected solid, non-blinking objects. What can be damaged in this P2 to do such things?
(and what I am doing wrong with YT? The film can be only started after clicking at YouTube icon)
Now that is curious. If I do that it I get the expected gradient blocks.
Is it that cog 0's FIFO writes are broken? If instead of WRFAST/WFLONG, you use WRLONG, does anything change?
I expected something like this: solid gradient blocks. Not this blinky stuff I got. It is not a PSRAM that fails, but I have to find what it is... The clock doesn't matter here, I managed to go under 300 MHz (with a monitor which can do 40 Hz on VGA)
As I said, methinks the issue is cog0's FIFO writes
I tried wrlong instead, no change. It seems something breaks earlier than this. I tried to set constants instead of data in blitter cog (mov to these nibbles). There seems to be wrong places on the screen to write to.
And in unchanged program, there is one (moving, 16px) column which displays proper data, but in the 2 lines data/2 lines nothing pattern.
Hmm, so I guess something goes awry with
spr_buffercontents?There's a nice wiki full of good info.
A good wiki
Several experiments later: either something writes bad data into VRAM or the blitter cog does something wrong.
... go to blitter cog. It seems to blit data that are not sprites... or something. I set constant palette for all of them, then I set $1234567890... as the pixel data, regardless of what is set there by the game, yet I have lines with a constant color on the screen.
Can I get a code sample and picture of that?
There seems to be a synchronization problem with line#
I fill the sprite buffer with $123...
The blitter cog gets something other in there
However... if I reduce this:
rdlong ma_mtmp1,ptrb[2] wc if_c jmp #ma_lineloop ' got sentinel shl ma_mtmp1,#1 ' sprite lines are 2 longs add ma_mtmp1,ma_char_base setbyte ma_mtmp1,#$EB,#3 splitb ma_mtmp1 rev ma_mtmp1 movbyts ma_mtmp1, #%%0123 mergeb ma_mtmp1 rep @.irqshield,#1 drvh #PSRAM_SELECT drvl ma_psram_pinfield xinit ma_psram_addr_cmd,ma_mtmp1 wypin #(8+PSRAM_WAIT+4)*2,#PSRAM_CLK setq ma_nco_fast xcont #PSRAM_WAIT*2+PSRAM_DELAY,#0 wrfast ma_bit31,ptrb waitxmt fltl ma_psram_pinfield setq ma_nco_slow xcont ma_psram_readspr_cmd,#0 waitxfi drvl #PSRAM_SELECTto this:
rdlong ma_mtmp1,ptrb[2] wc if_c jmp #ma_lineloop ' got sentinel wrfast ma_bit31,ptrb wrlong ##$12345678 wrlong ##$9abcdef0there is no more blinking except several artifacts here and there and I got these gradient filled sprites! As if the blitter blits the same sprite buffer as the memory manager fills at the same time.
Add several nops between if_c jmp and wrfast and the picture starts blinking again.
I have to go to sleep now. I managed to destroy the code so tomorrow I will start again fron rm -rf and git clone.The line counter is at hub $F8 and maybe these low hub locations are not working as expected. To be tested tomorrow.
Good work! We're getting somewhere. Line sync issue would explain the patterns. Will stare at code for a bit.
Unrelatedly, I just figured out that I have the SHRINK.DAT file included, but I didn't remove the code that regenerates it at runtime. lol.
I got the same gradient result as you Wuerfel_21 when I made pik33's 3 line change.
Replacing this:
with this
mov qqq,ma_curline and qqq,#3 mul qqq,##$600 add ptrb,qqqshould do nothing, but it does something. There is a 16-pixels wide proper graphic column on the screen.... if I also move the line counter from $F8
Did you try four NOPs? Is this same as zero NOPs?
These two options have same egg beater slice difference between RDLONG and WRFAST.
by "move the line counter from $F8", you included changing the address given to
video.start?