Its much better in real life, the pic I took with my phone really doesn't do it justice.
It's more than good enough for the task at hand and far superior to the LCD I used in the 8in1.
Now to try all your other emulators, thanks for all your hard work (and others who contributed) on this, it's an impressive feat.
@Coley said:
Its much better in real life, the pic I took with my phone really doesn't do it justice.
It's more than good enough for the task at hand and far superior to the LCD I used in the 8in1.
Then you need to check why your camera is like that. It does look like color clipping, anyways. Check out the 240p Test Suite ROM (also linked in the README.MD). For this you want to look at the "Color Bar" pattern and make sure all the steps are distinct and balanced. There should be a pretty big jump between C and E columns.
Now to try all your other emulators, thanks for all your hard work (and others who contributed) on this, it's an impressive feat.
If you have one working the others should be easy to get into. They each have some unique quirk though.
For MisoYume, see what the 560x480 mode does. That should almost fill the screen and have the correct aspect ratio (render resolution is odd 512x224 with non-square pixels).
There appear to have been 2 horrible issues again:
MegaYume was broken by a flexspin update (again?). Fixed on my side on git.
MisoYume beta08 does not work when DIGITAL_BASEPIN is set to -1 (also fixed on git)
Found these while trying to bring up new board from @Rayman . This one has fan + overvolt, looks promising so far. Need to also try the 4-bit SD stuff still.
I just looked into the perennial MisoYume timing issues again and I think I was able to fix the CPU/PPU synch a bit.
Both the PPU and the CPU base their timing on the scanline counter from the video driver. The PPU cogs latch all register values once at the very beginning (using a single big SETQ+RDLONG) and pass those through to get a consistent set of values for the entire pipeline. The CPU simply partitions it's work such that each scanline has a cycle budget that gets counted down while executing instruction.
The problem: The real PPU chip has an 88-cycle back porch that is already part of the "new" scanline. So register writes that happen in those cycles are missed by latching at the very beginning of the line. I previously fudged this by setting the HBlank flag in HVBJOY too early, which fixed glitches in some games that write registers late into HBlank, but instead causes glitches in games that write registers early into HBlank (because they start doing it before the DMA engine starts scanline HDMA).
Solution: add another annoying scanline event counter. This event does the sync with the scan counter, instead of the end-of-line event.
This is now on the dev branch. Street Racer works now. Still need to test more and probably rework the event system.
EDIT: Most games seem fine with this new change. But Street Racer actually crashes when you go to options for some reason. I think it already did before, but uhh that's not a fully fixed game yet.
I also just added @evanh 's 4 bit driver to NeoYume. The load times are super quick now!
Tested on @Rayman 's new board. Has 64MB RAM, too, so pretty nice.
Okay, so it turns out the V-Blank flag in HVBJOY was also wrong (for some reason checking against 240 instead of 225).
Though that doesn't really fix Street Racer's options menu, either. It seems to be another stupid edge case where the code wants to wait for the V-Blank flag to be set, but the NMI is active at the same time and the handler is taking long enough for VBlank to be over before it returns. So the loop (see disassembly below) can only exit if the BIT instruction happens to execute exactly inbetween the VBlank flag coming high and the CPU handling the NMI (the existence of that delay action is an annoying edge case in itself, but I had to fix this for the "NMI enabled manually" case already to fix Jaki Crush, so doing it on all NMIs is easy).
For some reason the loop can get stuck in a way where the NMI is always triggered after BEQ, so it still hangs in that case. Need to investigate that still. Phalanx boots now though, which I don't think it ever did before, so the fix is not totally lost.
@evanh said:
Ada,
How's the audio noise like when using P2Platform board?
The usual. Headphones are great but line-in on my PC couples a lot Smile into the signal (this seems to be moreso a PC problem with the USB and audio supplies not being sufficiently isolated).
More worryingly, the fan has started being unhappy and sometimes makes awful grinding noises now.
Also, I fixed another MisoYume bug (still on dev branch): Correct sign-extending for M7X and M7Y registers, fixes minor bug in Street Racer and missing pendulum in Chrono Trigger. (Really affects any game that does non-trivial Mode 7 stuff in non-wraparound modes)
Sounds kinda like it sucked in some debris into the bearing and it's grinding on it now. Can't seem to shake anything out and I don't think these can be non-destructively taken apart.
Unrelatedly, I fixed some NVRAM mapping stuff in MisoYume (dev branch still), so Ys 3 can save properly now (was previously listed as working already because I never tested the save feature... lol).
One more change till I tag another full version. I'm looking into Super Metroid now, annoying to repro the issue since it happens a bit into the game, but luckily there's a partial disassembly on github to look at. So what happens is that it seems to jump to a garbage address, execute a COP instruction there and get stuck in the infinite loop the COP trap vector points at. Lovely.
@Rayman said:
@Wuerfel_21 Think you might get to Galaga one day?
Have that going with Mame now, but would be neat to be powered by P2...
That'd kinda require a dedicated emulator because it uses custom hardware (though you'd probably also get Xevious/Dig Dug/Bosconian that use a similar board).
General problem with vertical screen arcade games is that most screens are infact not vertical, so you either require a rotated screen or you need to rotate it in software (slow and awful).
I think @macca 's MSX emulator might run the MSX version of Galaga, which I know, less than ideal.
My emulators are a bit dire in general because arguably the early 90s are the dark age of 2D shooters where the genre at large got stuck in the bad middle between the simple 70s/80s type arcade design and the more refined late 90s/2000s stuff. Having the hardware power to make colorful detailed backgrounds is one thing, knowing enough restraint to not make it the same brightness as the enemy bullets is another.
Megadrive has some decent shooters though. Try MUSHA. Ironclad on NeoGeo is also pretty cool.
Okay, I figured Super Metroid out. So there's a function at $8483D7 that's involved when loading certain rooms. It uses the old "put argument data inline after the call instruction" trick, which also includes a call table offset. To read this data, it uses an LDA ($06,S),Y instruction (e.g. read 16 bits from SP+$06, add Y to this and then load A from the resulting address). Since it's a load with a 16 bit address, this needs to take the data bank register into account, but I somehow oopsied this, likely by copy-paste error from the plain SP+xx offset address mode, which always reads from bank 0. Thus the mythical single-bit bugfix: https://github.com/IRQsome/MisoYume/commit/cd32ac84aac1296a858080107f0dbe41c6fa2b9b
Intriguingly:
The $8483D7 function is actually called once at the very beginning when starting the game, but somehow that instance doesn't crash out.
This is a bug in a core CPU feature. Somehow this is the most obvious bug fixed by this. I guess this addressing mode is just rarely useful.
Okay, there it is, MisoYume beta 09, attached or on github. In summary:
Fix board configs without HDMI/DVI pins (regression)
Fix CPU/PPU sync (now accounts for back porch)
Fix HVBJOY flag timings (mostly fixes Street Racer)
Fix M7X/M7Y missing sign extend in a spot (fixes pendulum in Chrono Trigger opening, likely others)
Add alternate LoROM+NVRAM maps (half and full banks), fixes saving in Ys 3
Fix (d,s),y addressing mode (see above, fixes Super Metroid, likely others)
At some point during this it seems Secret of Mana started mostly working (audio still broken though). In return Breath of Fire 2 stopped working at some point, so that's fun.
Comments
Its much better in real life, the pic I took with my phone really doesn't do it justice.
It's more than good enough for the task at hand and far superior to the LCD I used in the 8in1.
Now to try all your other emulators, thanks for all your hard work (and others who contributed) on this, it's an impressive feat.
Then you need to check why your camera is like that. It does look like color clipping, anyways. Check out the 240p Test Suite ROM (also linked in the README.MD). For this you want to look at the "Color Bar" pattern and make sure all the steps are distinct and balanced. There should be a pretty big jump between C and E columns.
For MisoYume, see what the 560x480 mode does. That should almost fill the screen and have the correct aspect ratio (render resolution is odd 512x224 with non-square pixels).
There appear to have been 2 horrible issues again:
Found these while trying to bring up new board from @Rayman . This one has fan + overvolt, looks promising so far. Need to also try the 4-bit SD stuff still.
I just looked into the perennial MisoYume timing issues again and I think I was able to fix the CPU/PPU synch a bit.
Both the PPU and the CPU base their timing on the scanline counter from the video driver. The PPU cogs latch all register values once at the very beginning (using a single big SETQ+RDLONG) and pass those through to get a consistent set of values for the entire pipeline. The CPU simply partitions it's work such that each scanline has a cycle budget that gets counted down while executing instruction.
The problem: The real PPU chip has an 88-cycle back porch that is already part of the "new" scanline. So register writes that happen in those cycles are missed by latching at the very beginning of the line. I previously fudged this by setting the HBlank flag in HVBJOY too early, which fixed glitches in some games that write registers late into HBlank, but instead causes glitches in games that write registers early into HBlank (because they start doing it before the DMA engine starts scanline HDMA).
Solution: add another annoying scanline event counter. This event does the sync with the scan counter, instead of the end-of-line event.
This is now on the dev branch. Street Racer works now. Still need to test more and probably rework the event system.
EDIT: Most games seem fine with this new change. But Street Racer actually crashes when you go to options for some reason. I think it already did before, but uhh that's not a fully fixed game yet.
I also just added @evanh 's 4 bit driver to NeoYume. The load times are super quick now!
Tested on @Rayman 's new board. Has 64MB RAM, too, so pretty nice.
Oh, nice, I'd missed that Rayman has included a full 4-bit uSD slot.
Okay, so it turns out the V-Blank flag in HVBJOY was also wrong (for some reason checking against 240 instead of 225).
Though that doesn't really fix Street Racer's options menu, either. It seems to be another stupid edge case where the code wants to wait for the V-Blank flag to be set, but the NMI is active at the same time and the handler is taking long enough for VBlank to be over before it returns. So the loop (see disassembly below) can only exit if the BIT instruction happens to execute exactly inbetween the VBlank flag coming high and the CPU handling the NMI (the existence of that delay action is an annoying edge case in itself, but I had to fix this for the "NMI enabled manually" case already to fix Jaki Crush, so doing it on all NMIs is easy).
For some reason the loop can get stuck in a way where the NMI is always triggered after BEQ, so it still hangs in that case. Need to investigate that still.
Phalanx boots now though, which I don't think it ever did before, so the fix is not totally lost.
Ada,
How's the audio noise like when using P2Platform board?
The usual. Headphones are great but line-in on my PC couples a lot Smile into the signal (this seems to be moreso a PC problem with the USB and audio supplies not being sufficiently isolated).
More worryingly, the fan has started being unhappy and sometimes makes awful grinding noises now.
Also, I fixed another MisoYume bug (still on dev branch): Correct sign-extending for M7X and M7Y registers, fixes minor bug in Street Racer and missing pendulum in Chrono Trigger. (Really affects any game that does non-trivial Mode 7 stuff in non-wraparound modes)
Fan noise ? Haven’t seen that here…
But these are low cost fans…
Sounds kinda like it sucked in some debris into the bearing and it's grinding on it now. Can't seem to shake anything out and I don't think these can be non-destructively taken apart.
Unrelatedly, I fixed some NVRAM mapping stuff in MisoYume (dev branch still), so Ys 3 can save properly now (was previously listed as working already because I never tested the save feature... lol).
One more change till I tag another full version. I'm looking into Super Metroid now, annoying to repro the issue since it happens a bit into the game, but luckily there's a partial disassembly on github to look at. So what happens is that it seems to jump to a garbage address, execute a COP instruction there and get stuck in the infinite loop the COP trap vector points at. Lovely.
@Wuerfel_21 Think you might get to Galaga one day?
Have that going with Mame now, but would be neat to be powered by P2...
That'd kinda require a dedicated emulator because it uses custom hardware (though you'd probably also get Xevious/Dig Dug/Bosconian that use a similar board).
General problem with vertical screen arcade games is that most screens are infact not vertical, so you either require a rotated screen or you need to rotate it in software (slow and awful).
I think @macca 's MSX emulator might run the MSX version of Galaga, which I know, less than ideal.
My emulators are a bit dire in general because arguably the early 90s are the dark age of 2D shooters where the genre at large got stuck in the bad middle between the simple 70s/80s type arcade design and the more refined late 90s/2000s stuff. Having the hardware power to make colorful detailed backgrounds is one thing, knowing enough restraint to not make it the same brightness as the enemy bullets is another.
Megadrive has some decent shooters though. Try MUSHA. Ironclad on NeoGeo is also pretty cool.
Okay, I figured Super Metroid out. So there's a function at $8483D7 that's involved when loading certain rooms. It uses the old "put argument data inline after the call instruction" trick, which also includes a call table offset. To read this data, it uses an
LDA ($06,S),Yinstruction (e.g. read 16 bits from SP+$06, add Y to this and then load A from the resulting address). Since it's a load with a 16 bit address, this needs to take the data bank register into account, but I somehow oopsied this, likely by copy-paste error from the plain SP+xx offset address mode, which always reads from bank 0. Thus the mythical single-bit bugfix: https://github.com/IRQsome/MisoYume/commit/cd32ac84aac1296a858080107f0dbe41c6fa2b9bIntriguingly:
Okay, there it is, MisoYume beta 09, attached or on github. In summary:
At some point during this it seems Secret of Mana started mostly working (audio still broken though). In return Breath of Fire 2 stopped working at some point, so that's fun.
