@Rayman said:
@Wuerfel_21 ok, got it. My son wants us to make a handheld game console…
He thinks he can take it to school if home made
That's the spirit!
Guess you have a 3.5” screen?
Think anything with that controller will work, or have to make sure in landscape mode somehow?
All screens with ILI9342 are landscape 320x240, that's what it's for. The other ILI9xxx chips are for portrait scan, stay away.
Mine is 2.3", quite tiny. They don't really get much bigger. Also the quality on the ones I have is not very good, low contrast, bad inversion. Though my driver tweaks some registers that really improve it from the default. If your panel is different that might cause a problem.
Do make sure that all the pins are actually exposed. Especially with a breakout board, these don't always expose all pins needed for RGB mode.
Also worth looking into: HX8238-D
These seem to support the same sort of interface. There are data pins for 24 bit but the datasheet only claims 262K colors / 64 DAC levels? Could probably just not wire the LSBs than and use the same 6 bit code. Would need a different SPI init sequence.
@Rayman said:
Is there a menu system that works with ili to switch between emulators?
Nope. Need to make one still. Though you can probably make a quick one yourself. Flexspin has _execve to boot into other programs. (warning: function sucks and only works if there's enough free stack space to load the new program. Luckily --compress is a thing)
Also note that MisoYume currently has no LCD support (should be easy to fix, might do it tomorrow). Tempest 2000 has it, though IDK if it works in the new driver branch, use the plain p2port one (or I guess I'll check that one out, too). Spin Hexagon does not support it at all (rogloh video driver).
When I last looked for small LCDs I found that 240x320 portrait mode ILI9341 chipset/screens were a lot more prevalent vs the 320x240 true landscape ones ILI9342. The landscape ones seem less popular and a bit harder to locate, at least via the cheap sites like ali, banggood etc, although a quick search for ILI9342 just now did quickly find some supposed landscape raw panels...
You'd need to dig further to find some fitted on actual carrier PCBs exposing the desired parallel pins if you need a simpler way to attach to a P2 for prototyping etc and didn't want to design a custom board and solder down some FFC/FPC connectors.
Almost more important than screen, you need controls. The regular sort of soldered tact switches are pretty bad for this, they have too little travel, they don't like being held down and will often break contact if you wiggle them. Real controllers use silicone button pads over PCB contacts (or silicone pads without the carbon bit over metal domes soldered to the PCB), but I can't find a source for generic ones, though there's plenty of replacement parts for old consoles. Also mind that the direction pad is not just 4 buttons. It needs a pivot in the center that prevents pressing down all directions at once. If you don't have that it's borderline unusable.
@Rayman said:
I’ll get this to start. But thinking could also twist vga driver to deliver 24 pin color to 640x480 display. If can make a dot clock…
Yeah, making the dotclock happen is easy. The 6 bit RGB mode already needs a dotclock synced to the streamer, serializing the RGB is just a layer on top of that (but that only works at low resolution since it's software based, similar to lowres HDMI)
Maybe also get the 640x480 one I linked from the same store for experimentation.
You should connect it to P4..P31 somewhat like this:
P4: DOTCLK
P5: DE
P6: HSYNC
P7: VSYNC
P8..P15: Blue data
P16..P23: Green data
P24..P31: Red data
P0..P3 can be audio or whatever. With DE+HSYNC+VSYNC no serial is needed (and these 640x480 panels don't seem to have any juicy settings).
Also new: MisoYume beta10, now with LCD support for the first time. The SNES resolution is output resolution is 512x224, so I had to add 2:1 downscaling to the video driver to bring it to 256x224. Games that actually use hi-res modes don't take too well to this, but most only use the low-res modes to begin with, so the scaling is a no-op.
Also attached release ZIP for new MegaYume, as per above
video-nextgen branch for Tempest 2000 also has working LCD6/ILI9342 support again now.
This one actually does a bit of driver-side dithering to smooth over the low 18bpp color resolution (has very noticeable gradient banding otherwise)
Any chance the examples there could run on your emulator @Wuerfel_21 ?
Should be, NeoYume is fairly solid. It does run the NeoGeo version of 240p test suite well enough. Though as mentioned in the README, it can only load ROMsets that have been added into the game database neoyume_gamedb.spin2, so no plug-and-play like the other emulators.
@Wuerfel_21 Installed SGDK and it looks very good. Documented very well and kept up to date. There's a "Hello World" example that locks very straightforward.
There are detailed instructions on how to set up Code::Blocks as IDE for this.
But, the output is a ".bin" file. Think the actual games have a ".md" file extension, right? Do we need to somehow turn a ".bin" into a ".md" for it to work with MegaYume?
@Rayman said:
But, the output is a ".bin" file. Think the actual games have a ".md" file extension, right? Do we need to somehow turn a ".bin" into a ".md" for it to work with MegaYume?
You need that in general, my emulators are not designed as development tools, there's 0 guarantee that code working on MegaYume will work on real HW or other emulators.
Comments
Wait are u saying only 6 bits per pixel?
Or 6x3=18 bits per pixel?
If really just 6 bits, how does that look?
It must be 18 bpp i think
it's 18 bits per pixel, but spread over 3 clocks, so only 6 pins are used.
To illustrate: (note that the enable pin isn't actually needed, can set display start timing over SPI instead)
@Wuerfel_21 ok, got it. My son wants us to make a handheld game console…
He thinks he can take it to school if home made
Guess you have a 3.5” screen?
Think anything with that controller will work, or have to make sure in landscape mode somehow?
That's the spirit!
All screens with ILI9342 are landscape 320x240, that's what it's for. The other ILI9xxx chips are for portrait scan, stay away.
Mine is 2.3", quite tiny. They don't really get much bigger. Also the quality on the ones I have is not very good, low contrast, bad inversion. Though my driver tweaks some registers that really improve it from the default. If your panel is different that might cause a problem.
Do make sure that all the pins are actually exposed. Especially with a breakout board, these don't always expose all pins needed for RGB mode.
Seeing some 3.5” on eBay…
Also worth looking into: HX8238-D
These seem to support the same sort of interface. There are data pins for 24 bit but the datasheet only claims 262K colors / 64 DAC levels? Could probably just not wire the LSBs than and use the same 6 bit code. Would need a different SPI init sequence.
Is there a menu system that works with ili to switch between emulators?
I don't?
Nope. Need to make one still. Though you can probably make a quick one yourself. Flexspin has
_execveto boot into other programs. (warning: function sucks and only works if there's enough free stack space to load the new program. Luckily --compress is a thing)Also note that MisoYume currently has no LCD support (should be easy to fix, might do it tomorrow). Tempest 2000 has it, though IDK if it works in the new driver branch, use the plain p2port one (or I guess I'll check that one out, too). Spin Hexagon does not support it at all (rogloh video driver).
When I last looked for small LCDs I found that 240x320 portrait mode ILI9341 chipset/screens were a lot more prevalent vs the 320x240 true landscape ones ILI9342. The landscape ones seem less popular and a bit harder to locate, at least via the cheap sites like ali, banggood etc, although a quick search for ILI9342 just now did quickly find some supposed landscape raw panels...
https://www.aliexpress.com/item/1005008680079969.html
https://www.aliexpress.com/item/1005008628447953.html
You'd need to dig further to find some fitted on actual carrier PCBs exposing the desired parallel pins if you need a simpler way to attach to a P2 for prototyping etc and didn't want to design a custom board and solder down some FFC/FPC connectors.
This is the display+breakout I got: https://www.buydisplay.com/serial-spi-2-3-inch-tft-lcd-display-module-with-touch-panel-320x240
Note that the RGB mode pins are on JP2, which isn't populated by default, but I emailed them and they did send me RGB-ready ones.
Though remember, the screen quality on these is a bit poor.
They also have a 640x480 one that looks interesting, 24 bit interface: https://www.buydisplay.com/ips-3-5-inch-full-viewing-640x480-tft-display-capacitive-touch-screen
No breakout, so custom PCB required.
Almost more important than screen, you need controls. The regular sort of soldered tact switches are pretty bad for this, they have too little travel, they don't like being held down and will often break contact if you wiggle them. Real controllers use silicone button pads over PCB contacts (or silicone pads without the carbon bit over metal domes soldered to the PCB), but I can't find a source for generic ones, though there's plenty of replacement parts for old consoles. Also mind that the direction pad is not just 4 buttons. It needs a pivot in the center that prevents pressing down all directions at once. If you don't have that it's borderline unusable.
@Wuerfel_21 Ok, I see the display you used now and ebay was showing me random stuff.
Seems that store is closed this weekend for "Tomb Sweeping Day". That's a new one on me
Mind that you want the 3-wire version and then populate JP2 to get at the clock/sync pins (or ask them to do it for you).
I’ll get this to start. But thinking could also twist vga driver to deliver 24 pin color to 640x480 display. If can make a dot clock…
Yeah, making the dotclock happen is easy. The 6 bit RGB mode already needs a dotclock synced to the streamer, serializing the RGB is just a layer on top of that (but that only works at low resolution since it's software based, similar to lowres HDMI)
Maybe also get the 640x480 one I linked from the same store for experimentation.
You should connect it to P4..P31 somewhat like this:
P4: DOTCLK
P5: DE
P6: HSYNC
P7: VSYNC
P8..P15: Blue data
P16..P23: Green data
P24..P31: Red data
P0..P3 can be audio or whatever. With DE+HSYNC+VSYNC no serial is needed (and these 640x480 panels don't seem to have any juicy settings).
I am also discovering right now that LCD support in MegaYume is currently broken. (Never fixed it for new video driver, ouch)
MegaYume 1.4-RC2 out now, fixes LCD6 mode (as discussed above)
Also new: MisoYume beta10, now with LCD support for the first time. The SNES resolution is output resolution is 512x224, so I had to add 2:1 downscaling to the video driver to bring it to 256x224. Games that actually use hi-res modes don't take too well to this, but most only use the low-res modes to begin with, so the scaling is a no-op.
Also attached release ZIP for new MegaYume, as per above
video-nextgen branch for Tempest 2000 also has working LCD6/ILI9342 support again now.
This one actually does a bit of driver-side dithering to smooth over the low 18bpp color resolution (has very noticeable gradient banding otherwise)
Thinking Neo-Geo is newest console emulator, right?
Found this devkit for it: https://github.com/dciabrin/ngdevkit
Any chance the examples there could run on your emulator @Wuerfel_21 ?
The newest is actually MisoYume (for SNES), though that's still in beta due to poor compatibility.
Should be, NeoYume is fairly solid. It does run the NeoGeo version of 240p test suite well enough. Though as mentioned in the README, it can only load ROMsets that have been added into the game database
neoyume_gamedb.spin2, so no plug-and-play like the other emulators.Is there another emulator devkit that might be easier to use?
Or a level editor for something?
SGDK for Megadrive is pretty good
That does look good thanks
@Wuerfel_21 Installed SGDK and it looks very good. Documented very well and kept up to date. There's a "Hello World" example that locks very straightforward.
There are detailed instructions on how to set up Code::Blocks as IDE for this.
But, the output is a ".bin" file. Think the actual games have a ".md" file extension, right? Do we need to somehow turn a ".bin" into a ".md" for it to work with MegaYume?
No, it's all the same.
I see mention of a debug compile option. Guessing have to use PC emulator to use that, right?
You need that in general, my emulators are not designed as development tools, there's 0 guarantee that code working on MegaYume will work on real HW or other emulators.