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.
Rayman's made a good choice with the SD vs EEPROM on the Prop2 Platform board. He's removed the SD booting ability with implementing full 4-bit SD wiring on separate pins.
I say this because serial port programming of the EEPROM can be optionally enabled by removing the pull-down on P59. This enables a 100 ms serial boot window (Wired permanently in Prop2Platform).
SD booting has no such window. There you must repeatedly toggle between adding the P59 pull-up for each programming cycle and then removing it again for reboot testing - Assuming any tools had supported doing so, but that's chicken and egg territory.
EDIT: Improved readability ... And correct to P59 pull-up.
I always just load to RAM, anyways. Not sure why many people always load the flash. Constantly reflashing the flash isn't very healthy. Maybe it just sticks around from working with processors that run code directly from flash (and thus don't have a load RAM option)
The built-in SD booter is kindof crummy, anyways - There's no feedback when it fails, so totally not fit for end users. Better to load up flash with a bootloader program.
Totally agree, development is best done via serial to RAM directly.
But making the step of rewriting the boot "firmware" as easy as possible is where I'm coming from. The firmware needs testing too.
I'd written off SD achieving that ability itself on the basis of this step being broken. ie: It relied solely on removing the SD card for each iteration. And since that above circuit wouldn't be acceptable really anyway, SD still isn't viable boot solution.
I have a Basic flashed to EC32 as a permanent solution. It boots everything from SD using a command, returns to Basic after reset. While developing, load RAM only. If something is more complex to compile, as these low/high ****yume emulators code, compile, copy the binary to /bin folder on SD card to load when needed.
@Rayman said:
Wishing there was a free cog for second usb port or driver that can run two usb at same time, but seems that does not exist yet…
A while back I mused over having a specially designed USB COG that could sort of behave a little like a poor man's USB hub by selectively sending out to both ports and listening in from two different physical port pins (one device per physical port). Whether that level of muxing could work in practice with USB timeouts etc I'm not entirely sure but if so it might let you just use one COG for two devices without a true USB hub present. The fact that devices get polled by the host implies to me that you could track which USB device (if any) is attached to which actual HW port pin and selectively output to that device's pins for issuing periodic polling requests and then read back the expected reply from that same port, then repeat for the other device on the other port. This may work for say a keyboard on one port and a mouse on another, or a game controller on each port. The dual USB port Prop breakout board would become especially handy HW for this too. Of course there are going to be issues with a driver's now extended state management and USB port speed control, device attach/detach, and it'd hardly be USB compliant, but gut instinct sort of hints to me that something like that could probably be cobbled together to work, perhaps with some additional constraints.
A simpler way of course is to use a cheap/readily available USB hub on a single physical port.
@pik33 said:
I have a Basic flashed to EC32 as a permanent solution. It boots everything from SD using a command, returns to Basic after reset. While developing, load RAM only. If something is more complex to compile, as these low/high ****yume emulators code, compile, copy the binary to /bin folder on SD card to load when needed.
I presume the Basic firmware can also auto-run a SD card? So then no need to ever have the Prop2 ROM doing it.
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.
Rayman's made a good choice with the SD vs EEPROM on the Prop2 Platform board. He's removed the SD booting ability with implementing full 4-bit SD wiring on separate pins.
I say this because serial port programming of the EEPROM can be optionally enabled by removing the pull-down on P59. This enables a 100 ms serial boot window (Wired permanently in Prop2Platform).
SD booting has no such window. There you must repeatedly toggle between adding the P59 pull-up for each programming cycle and then removing it again for reboot testing - Assuming any tools had supported doing so, but that's chicken and egg territory.
EDIT: Improved readability ... And correct to P59 pull-up.
Huh, this has me thinking now. It isn't hard to also dynamically switch the P59 pull-up using DTR control. But it's not PropPlug compatible.
I always just load to RAM, anyways. Not sure why many people always load the flash. Constantly reflashing the flash isn't very healthy. Maybe it just sticks around from working with processors that run code directly from flash (and thus don't have a load RAM option)
The built-in SD booter is kindof crummy, anyways - There's no feedback when it fails, so totally not fit for end users. Better to load up flash with a bootloader program.
Totally agree, development is best done via serial to RAM directly.
But making the step of rewriting the boot "firmware" as easy as possible is where I'm coming from. The firmware needs testing too.
I'd written off SD achieving that ability itself on the basis of this step being broken. ie: It relied solely on removing the SD card for each iteration. And since that above circuit wouldn't be acceptable really anyway, SD still isn't viable boot solution.
I have a Basic flashed to EC32 as a permanent solution. It boots everything from SD using a command, returns to Basic after reset. While developing, load RAM only. If something is more complex to compile, as these low/high ****yume emulators code, compile, copy the binary to /bin folder on SD card to load when needed.
Thinking about enclosure for new platform board and hdmi output… to make p2 game console…
Thinking about incorporating a cheap 4 port hub inside the box…
Think some games can support 2 player… can any here support 4? Maybe in future?
Wishing there was a free cog for second usb port or driver that can run two usb at same time, but seems that does not exist yet…
Traditional Atari type joystick and Amiga mouse don't require any cogs. You can have lots of both of those.
A while back I mused over having a specially designed USB COG that could sort of behave a little like a poor man's USB hub by selectively sending out to both ports and listening in from two different physical port pins (one device per physical port). Whether that level of muxing could work in practice with USB timeouts etc I'm not entirely sure but if so it might let you just use one COG for two devices without a true USB hub present. The fact that devices get polled by the host implies to me that you could track which USB device (if any) is attached to which actual HW port pin and selectively output to that device's pins for issuing periodic polling requests and then read back the expected reply from that same port, then repeat for the other device on the other port. This may work for say a keyboard on one port and a mouse on another, or a game controller on each port. The dual USB port Prop breakout board would become especially handy HW for this too. Of course there are going to be issues with a driver's now extended state management and USB port speed control, device attach/detach, and it'd hardly be USB compliant, but gut instinct sort of hints to me that something like that could probably be cobbled together to work, perhaps with some additional constraints.
A simpler way of course is to use a cheap/readily available USB hub on a single physical port.
I presume the Basic firmware can also auto-run a SD card? So then no need to ever have the Prop2 ROM doing it.
MegaYume supports 4 player in some games, such as Gauntlet IV.