@Rayman Yea you can change the frequency like that, but the video will go faster. i guess most monitors should sync up to 70Hz, so that should be fine. Your monitor should say something like "OUT OF RANGE" if it isn't taking the video signal.
With those dummy cogs running, it's way more stressful than NeoYume. Try it on one of those older boards. They just can't handle it at all. Also, the memory test is exacting. A single bit error anywhere will trip it, whereas the actual emulator can often shake it off.
New finding: Running MXX board off a 12V wall brick results in VBUS = 4.99V. A lot better.
Probably more interesting would be how this affects the RAM VIO rail.
Still need to measure a bunch of different boards and power methods.
Might be a noiser power supply brick somehow coupling through to the VIO rails of the P2 or other PSRAM signals. You could scope it to see different amounts of noise on the voltage rails with different supplies, although it's not that that accurate and hard to find transients unless it's grossly different from other supplies or you have a good high bandwidth scope.
@rogloh said:
Might be a noiser power supply brick somehow coupling through to the VIO rails of the P2 or other PSRAM signals. You could scope it to see different amounts of noise on the voltage rails with different supplies, although it's not that that accurate and hard to find transients unless it's grossly different from other supplies or you have a good high bandwidth scope.
I think this is the core giving out though, notice how there's ERRs and OKs outside of the intended grid. I've also had hard crashes and other screen corruptions happen.
@Wuerfel_21 said:
FYI, building NeoYume on latest flexspin is busted, if you get something cool like
neoyume_upper.p2asm:2126: error: ## is not legal with loc
neoyume_upper.p2asm:2164: error: ## is not legal with loc
downgrade to a 6.x.x version
I think that error message is legit: loc pb, #any_addr is legal, but why would you ever want loc pb, ##any_addr (which would insert a superflous ALTS)?
EDIT: ah, I see, it's the compiler generating that. That is wrong, yes, I'll try to get it fixed soon.
Now I can get to what I actually wanted to do, which is finally fix the analog video code in the new video driver.
As mentioned earlier it's missing serrated sync and interlacing still, so it's only mainlined in NeoYume. Except I just noticed that when I connect it to my actual TV, it really flips out and doesn't show a stable image at all (EDIT: after another try it does, but the video is too far down the tube). Very interesting.
EDIT 2: okay I think I isolated two issues: VSYNC is too long (should only be 3 lines, but the old driver counted its serration pulses towards sync, so I had 9 sync lines), causing video too far down the screen. Also something is wrong with PAL mode that causes the picture to shake violently. (EDIT 3: Apparently that's my TV's reaction to the "PA" in PAL getting out of sync. Quick fix!)
Finally, interlaced sync for the new video driver. Currently code is clunky. Need to shuffle around a bit so native res YPbPr also uses this (and test it!).
EDIT: Also the RetroScaler seems to not like the signal much - need to check what the old code did different
Yeah getting the sync combo's perfected can be tricky. I still need to finish adding interlaced to my own driver's VGA mode, which is only partly done as I needed to free some space for it by more overlay use. The other interlaced analog modes should already work. Are you planning interlaced for HDMI? I think that needs extra pixel doubling (so pixel quadrupling in 320x240 modes).
No, for HDMI I'm just bobbing the image to "convert" interlace to progressive, same as 480p VGA. (The VDP emulation scanline-renders natively interlaced video when in high-res mode!)
Generally I don't think there's much point to 480i over HDMI... And the next standard resolution is 1920x1080i, which is too much.
Yeah for "proper" HDMI from the P2 we are probably kinda stuck to doing progressive 640 and 720 wide screens IMO with software pixel doubling halving that resolution on screen. DVI is a bit more forgiving and allows a bit more leeway.
I have infact somehow fixed the interlace timing, by doing something that I swear didn't work before but now does. Cool. Interesting how the CRT TV does not care that much (even though it's a late-era one that ends up going through a full ADC->memory->DAC thing). I always wondered if you could do a "720i" signal where there are 3 fields per frame instead of 2 and have it work on standard TVs. Maybe something to try one of those days.
Ok, I think I finally fixed EVERYTHING. Interlaced sync, NTSC/PAL, composite/svideo/ypbpr, correct scanline counting, etc.
The only missing piece is how serrated sync should look like on RGBHV/VGA (for composite sync it's obviously just the same as the NTSC sync pattern). I guess it ought to maintain the property that CSync = HSync XOR VSync. Doesn't help that I have nothing that takes 15kHz RGBHV (except the VisionRGB card). Didn't @Rayman have an arcade monitor laying around?
EDIT: actually, fixing the line counter for megayume broke it for neoyume. cool. I think it never worked properly to begin with, so maybe time to fix it properly? EDIT 2: YES YES YES
I want to get my P2 back up and running now that I'm redesigning the P2 Arc8de cabinets, what hardware do I need to get these emulators up and running, is P2 Edge Module with 32MB sufficient?
One of the things I want to try this with is a 9.7 inch iPad screen with HDMI control board that I'm thinking of using in the new cab.
@Coley Yes, EC32MB is good. Very stable, non-fussy board. Just make sure you give it enough juice and don't let it overheat. The NeoGeo emulator is limited in game compatibility by the smaller RAM size (see https://github.com/irqsome/neoyume?tab=readme-ov-file#game-compatibility ), but otherwise it's great.
Other notes:
Always read the README.MD and other .MD files
At some point I re-wrote the video code (mainly to add HDMI audio, but this also added more flexible resolution support). This is currently only mainlined in NeoYume (though that should change soon), for the other projects you may need to check the video-nextgen branch (where available) to get the dev version with the new video code.
Make sure your LCD can actually re-scale the image in a non-awful way; the HDMI output is fixed to 480p. With the newer video code, you can choose the active width to match the display aspect ratio (old code is fixed to 800x480...)
I only ever test USB controls. If you want to connect buttons directly to pins, the option for it is there, but you may need to complain if it doesn't work.
There are a few other projects that need to be brought up to speed, such as the P2 Spin Hexagon port. I also have a few unfinished ports of P1 classics to P2 laying around.
There currently isn't an IRQsome-approved "bootloader/IPL" type program to allow selection of multiple programs installed at once. @pik33 had one, but I never tested it.
However I don't know if the code from the repository actually works as I didn't do anything with it for a long time. The main reason for it is the Basic interpreter that I have flashed. Its "brun" command loads and runs P2 binaries from SD card files so I have the loader ready and can do
cd /neoyume
brun neoyume.bin
The command code in the interpreter looks like this:
sub do_brun
dim t1 as expr_result
dim pos,r,psramptr as integer
dim filename, fullfilename as string
t1=pop()
if t1.result_type=result_string2 then t1.result.sresult=convertstring(t1.result.uresult): t1.result_type=result_string
if t1.result_type=result_string then
filename=t1.result.sresult
if left$(filename,1)="/" then
fullfilename=filename
else
fullfilename="/sd/bin/"+filename
endif
open fullfilename for input as #9
r=geterr() : if r then print "System error ";r;": ";strerror$(r) :close #9 : return
let pos=1: let r=0 : let psramptr=0
do
get #9,pos,block(0),1024,r : pos+=r
psram.write(varptr(block(0)),psramptr,1024)
psramptr+=r ' move the buffer to the RAM and update RAM position. Todo: this can be done all at once
loop until r<>1024 orelse psramptr>=$7C000 ' do until eof or memory full
cpustop(audiocog) ' stop all driver cogs except PSRAM
cpustop(videocog)
cpustop(usbcog)
cpustop(housekeeper_cog)
let loadingcog=cpu(@loadcog,@pslock) ' start loading cog
cpustop(cpuid()) ' stop itself
endif
end sub
It gets parameters from the interpreter's stack and then copies the file to the PSRAM. After this, it stops all cogs except PSRAM driver and inits the loader.
The loader code:
'' ------------------------------- the loader cog for BRUN
asm shared
org
loadcog cogid t11 ' get a cogid
mul t11, #12 ' compute the offset to PSRAM mailbox
add mailbox, t11 ' add offset to find this COG's mailbox
mov psramaddr,#0
p101 mov buf1,psramaddr ' psramaddr=hubaddr
mov buf2,##16384 ' loading size
mov cmd,psramaddr ' set the address for reading
setnib cmd, #%1011, #7 ' attach the command - read burst
setq #2 ' write 3 longs to the mailbox
wrlong cmd, mailbox ' read the PSRAM
p102 rdlong cmd, mailbox ' poll mailbox for result
tjs cmd, #p102 ' retry until valid
add psramaddr,##16384
cmp psramaddr,##$7C000 wcz
if_lt jmp #p101 ' loop until full hub loaded
cogstop #7 ' stop psram driver
cogid t11 ' get id
coginit #0,#0 ' start the new program
cogstop t11 ' stop the loader
t11 long 0
mailbox long $7FF00
psramaddr long 0
pslockval long 0
cmd long 0
buf1 long 0
buf2 long 16384
end asm
is simple. It loads the binary from the PSRAM to the memory. However, the PSRAM driver had to be patched to do this, so its mailbox always starts at $7FF00. This makes conflicts with the BRK debug, but it's almost useless in FlexBasic. However I added a #define DEBUG in the current version of the patched drive (and have yet to do the same in the interpreter code)
@pik33 Thanks for posting it. I think you could do the loader part in inline ASM. That wouldn't really be a benefit, just a thought.
I just added a README to the misoyume github and am re-doing some compatibility testing.
Interesting finding: In Breath of Fire 2, there's a sort of cloud/fog effect that uses pseudo-hires mode and color math. It looked odd to me and bsnes-plus (possibly old branch) and Mesen2 render it differently. But guess what, someone has a playthrough captured from real hardware on YT and it matches what MisoYume does. I guess that means I really have understood the pixel pipeline.
Comments
Changed this line in NeoVGA and appear to have changed clock freq to 350 MHz:
Monitor says 61.4 Hz refresh
Gone a bit with no errors. Think this means that MisoYume should work.
Hmm. Won't do 355 MHz. Not 100% sure if it's the monitor or the P2 giving up...
@Rayman Yea you can change the frequency like that, but the video will go faster. i guess most monitors should sync up to 70Hz, so that should be fine. Your monitor should say something like "OUT OF RANGE" if it isn't taking the video signal.
With those dummy cogs running, it's way more stressful than NeoYume. Try it on one of those older boards. They just can't handle it at all. Also, the memory test is exacting. A single bit error anywhere will trip it, whereas the actual emulator can often shake it off.
Tested again today and did eventually fail (no fan).
Board was pretty warm though.
Think fan would fix it...
Tried with Vdd = 1.9 V. Works at 338 MHz, but not 350 MHz...
MisoYume runs for a few seconds at Vdd=1.9, but then crashes...
New finding: Running MXX board off a 12V wall brick results in VBUS = 4.99V. A lot better.
Probably more interesting would be how this affects the RAM VIO rail.
Still need to measure a bunch of different boards and power methods.
Despite the better VBUS voltage, the overall stability seems to be reduced running from the 12V supply. Very strange failure modes.
To illustrate:
Like what?
Might be a noiser power supply brick somehow coupling through to the VIO rails of the P2 or other PSRAM signals. You could scope it to see different amounts of noise on the voltage rails with different supplies, although it's not that that accurate and hard to find transients unless it's grossly different from other supplies or you have a good high bandwidth scope.
This makes me like the idea USB-C power more and more...
Is the 12V used for anything there? If needed, guess need a USB-C PD chip for that...
I think this is the core giving out though, notice how there's ERRs and OKs outside of the intended grid. I've also had hard crashes and other screen corruptions happen.
To belabour the point:
Back to USB input and suddenly it works again
Or maybe not
I feel like I may have cooked the board too much.
This is the point where I would wire up the oscilloscope to get some sanity back.
FYI, building NeoYume on latest flexspin is busted, if you get something cool like
downgrade to a 6.x.x version
.. and it turns out MegaYume was also broken (due to default FCache size changing), but I fixed that one on my end.
I think that error message is legit:
loc pb, #any_addris legal, but why would you ever wantloc pb, ##any_addr(which would insert a superflous ALTS)?EDIT: ah, I see, it's the compiler generating that. That is wrong, yes, I'll try to get it fixed soon.
@ersmith thanks for fixing it so quickly.
Now I can get to what I actually wanted to do, which is finally fix the analog video code in the new video driver.
As mentioned earlier it's missing serrated sync and interlacing still, so it's only mainlined in NeoYume. Except I just noticed that when I connect it to my actual TV, it really flips out and doesn't show a stable image at all (EDIT: after another try it does, but the video is too far down the tube). Very interesting.
EDIT 2: okay I think I isolated two issues: VSYNC is too long (should only be 3 lines, but the old driver counted its serration pulses towards sync, so I had 9 sync lines), causing video too far down the screen. Also something is wrong with PAL mode that causes the picture to shake violently. (EDIT 3: Apparently that's my TV's reaction to the "PA" in PAL getting out of sync. Quick fix!)
Finally, interlaced sync for the new video driver. Currently code is clunky. Need to shuffle around a bit so native res YPbPr also uses this (and test it!).
EDIT: Also the RetroScaler seems to not like the signal much - need to check what the old code did different
Yeah getting the sync combo's perfected can be tricky. I still need to finish adding interlaced to my own driver's VGA mode, which is only partly done as I needed to free some space for it by more overlay use. The other interlaced analog modes should already work. Are you planning interlaced for HDMI? I think that needs extra pixel doubling (so pixel quadrupling in 320x240 modes).
No, for HDMI I'm just bobbing the image to "convert" interlace to progressive, same as 480p VGA. (The VDP emulation scanline-renders natively interlaced video when in high-res mode!)
Generally I don't think there's much point to 480i over HDMI... And the next standard resolution is 1920x1080i, which is too much.
Yeah for "proper" HDMI from the P2 we are probably kinda stuck to doing progressive 640 and 720 wide screens IMO with software pixel doubling halving that resolution on screen. DVI is a bit more forgiving and allows a bit more leeway.
You can do actually-wide 854x480 just fine, too.
I have infact somehow fixed the interlace timing, by doing something that I swear didn't work before but now does. Cool. Interesting how the CRT TV does not care that much (even though it's a late-era one that ends up going through a full ADC->memory->DAC thing). I always wondered if you could do a "720i" signal where there are 3 fields per frame instead of 2 and have it work on standard TVs. Maybe something to try one of those days.
Ok, I think I finally fixed EVERYTHING. Interlaced sync, NTSC/PAL, composite/svideo/ypbpr, correct scanline counting, etc.
The only missing piece is how serrated sync should look like on RGBHV/VGA (for composite sync it's obviously just the same as the NTSC sync pattern). I guess it ought to maintain the property that CSync = HSync XOR VSync. Doesn't help that I have nothing that takes 15kHz RGBHV (except the VisionRGB card). Didn't @Rayman have an arcade monitor laying around?
EDIT: actually, fixing the line counter for megayume broke it for neoyume. cool. I think it never worked properly to begin with, so maybe time to fix it properly? EDIT 2: YES YES YES
Hey @Wuerfel_21
I want to get my P2 back up and running now that I'm redesigning the P2 Arc8de cabinets, what hardware do I need to get these emulators up and running, is P2 Edge Module with 32MB sufficient?
One of the things I want to try this with is a 9.7 inch iPad screen with HDMI control board that I'm thinking of using in the new cab.
Regards,
Coley
@Coley Yes, EC32MB is good. Very stable, non-fussy board. Just make sure you give it enough juice and don't let it overheat. The NeoGeo emulator is limited in game compatibility by the smaller RAM size (see https://github.com/irqsome/neoyume?tab=readme-ov-file#game-compatibility ), but otherwise it's great.
Other notes:
video-nextgenbranch (where available) to get the dev version with the new video code.All the repositories are here:
There are a few other projects that need to be brought up to speed, such as the P2 Spin Hexagon port. I also have a few unfinished ports of P1 classics to P2 laying around.
https://gitlab.com/pik33/P2-retromachine/-/tree/main/Propeller/microdos
https://forums.parallax.com/discussion/174645/microdos-a-simple-loader-for-psram-based-system-now-with-usb-keyboard/p1
However I don't know if the code from the repository actually works as I didn't do anything with it for a long time. The main reason for it is the Basic interpreter that I have flashed. Its "brun" command loads and runs P2 binaries from SD card files so I have the loader ready and can do
The command code in the interpreter looks like this:
sub do_brun dim t1 as expr_result dim pos,r,psramptr as integer dim filename, fullfilename as string t1=pop() if t1.result_type=result_string2 then t1.result.sresult=convertstring(t1.result.uresult): t1.result_type=result_string if t1.result_type=result_string then filename=t1.result.sresult if left$(filename,1)="/" then fullfilename=filename else fullfilename="/sd/bin/"+filename endif open fullfilename for input as #9 r=geterr() : if r then print "System error ";r;": ";strerror$(r) :close #9 : return let pos=1: let r=0 : let psramptr=0 do get #9,pos,block(0),1024,r : pos+=r psram.write(varptr(block(0)),psramptr,1024) psramptr+=r ' move the buffer to the RAM and update RAM position. Todo: this can be done all at once loop until r<>1024 orelse psramptr>=$7C000 ' do until eof or memory full cpustop(audiocog) ' stop all driver cogs except PSRAM cpustop(videocog) cpustop(usbcog) cpustop(housekeeper_cog) let loadingcog=cpu(@loadcog,@pslock) ' start loading cog cpustop(cpuid()) ' stop itself endif end subIt gets parameters from the interpreter's stack and then copies the file to the PSRAM. After this, it stops all cogs except PSRAM driver and inits the loader.
The loader code:
'' ------------------------------- the loader cog for BRUN asm shared org loadcog cogid t11 ' get a cogid mul t11, #12 ' compute the offset to PSRAM mailbox add mailbox, t11 ' add offset to find this COG's mailbox mov psramaddr,#0 p101 mov buf1,psramaddr ' psramaddr=hubaddr mov buf2,##16384 ' loading size mov cmd,psramaddr ' set the address for reading setnib cmd, #%1011, #7 ' attach the command - read burst setq #2 ' write 3 longs to the mailbox wrlong cmd, mailbox ' read the PSRAM p102 rdlong cmd, mailbox ' poll mailbox for result tjs cmd, #p102 ' retry until valid add psramaddr,##16384 cmp psramaddr,##$7C000 wcz if_lt jmp #p101 ' loop until full hub loaded cogstop #7 ' stop psram driver cogid t11 ' get id coginit #0,#0 ' start the new program cogstop t11 ' stop the loader t11 long 0 mailbox long $7FF00 psramaddr long 0 pslockval long 0 cmd long 0 buf1 long 0 buf2 long 16384 end asmis simple. It loads the binary from the PSRAM to the memory. However, the PSRAM driver had to be patched to do this, so its mailbox always starts at $7FF00. This makes conflicts with the BRK debug, but it's almost useless in FlexBasic. However I added a #define DEBUG in the current version of the patched drive (and have yet to do the same in the interpreter code)
@pik33 Thanks for posting it. I think you could do the loader part in inline ASM. That wouldn't really be a benefit, just a thought.
I just added a README to the misoyume github and am re-doing some compatibility testing.
Interesting finding: In Breath of Fire 2, there's a sort of cloud/fog effect that uses pseudo-hires mode and color math. It looked odd to me and bsnes-plus (possibly old branch) and Mesen2 render it differently. But guess what, someone has a playthrough captured from real hardware on YT and it matches what MisoYume does. I guess that means I really have understood the pixel pipeline.
I also just released MegaYume V1.4-RC1
Changes since the 1.3 tag are similar to NeoYume 1.4:
Current versions of NeoYume and MegaYume have also been posted to OBEX (now as ZIP files)!
That's one item off the TODO list...
That now means the HDMI Audio enablement progress is as follows