jfm92 / microbyte Goto Github PK

Hi! I received my microByte a few days ago from the Crowd Supply campaign. Congrats on delivering the project! My device works and everything that I expected was included in the package.

After spending some time playing with the microByte, I felt like sharing my feedback about the project so far:

• Either the processor is underpowered for the intended use, or the software is not optimized enough. Unfortunately, either way, this is kind of a show-stopper for me. In this day and age, emulation of 8 and 16 bit systems should run at nothing less than full-speed, and the microByte fails to achieve this. Games suffer constant frame-drops and the audio jitters. I think this is the most pressing issue, since this is the device's entire reason for being. If the software can be significantly optimized, great. Otherwise, I'd recommend that future revisions of the hardware use a faster chip/platform. Performance should not be compromised.

• The screen resolution (240 × 240) is an issue. The resolutions of the currently-supported systems range from 160 × 144 (Game Boy, Game Boy Color, Sega Game Gear) to 256 × 192 (Sega Master System) and 256 × 240 (NES). Just for reference, the SNES resolution is 256 × 224 and the Sega Genesis maximum resolution is 320 × 224. One additional note is that NES and SNES are intended to have a 4:3 aspect ratio, and overscan on the NES means its functional (visible) resolution is 256 × 224, so both of them should ideally be displayed at either 300 × 224 or 320 × 240. I don't believe the compromise to use a 240 × 240 display is worth the cost of awkward display scaling. In fact, I have a feeling that pixel-accuracy actually becomes more important at tiny display sizes. I would highly recommend switching to a 320 × 240 display, which—at the same pixel density—would add roughly 7 mm in width. This would also require a processor fast enough to perform at least bilinear scaling for the systems with non-square pixel aspect ratios.

• As a short-term remedy for the above issue, I'd recommend adding a software setting to crop 8 pixels from the left and right sides of the image in order to render 256-pixel-wide systems without any scaling. The current scaling, which appears to simply omit 1 column of pixels out of every 16 columns, is visually unappealing since it creates artifacts.

• There should be a way to remap buttons in the configuration menu. At present, for NES games, the bottom button is mapped to A, and the right button is mapped to B. This is inconsistent with the actual NES controller, which has the B button to the left of the A button.

• There appears to be a serious software bug in the main menu. If there are no ROMs or applications loaded on the card, and you select "Emulators" or "External Aplications" (this has a typo and should read "Applications") then a message will pop up saying eg. "Any app available" (this should read "No apps available"). After this message is dismissed, the main menu icons will no longer launch their corresponding function. For example, selecting "Emulators" may launch the configuration menu, and so forth, which is very confusing, and the device must be rebooted to fix it.

• There is a mismatch between the silicone button inserts and the spacing of the buttons, which results in slightly less-than-ideal performance on the soft-touch buttons. The silicone insert has a spacing of 15 mm, but the hardware (PCB and enclosure) has a spacing of 13.5 mm. This results in the button "springs" not being located in the dead-center of the buttons, but instead slightly off-center. The buttons should be revised to have 15 mm spacing so the targets align with the centers of the insert. This is less of a problem on the PCB since the contact doesn't have to be perfectly centered on the traces. This change would add roughly 3 mm to the overall width of the device.

• I'm not going to say much about the enclosure, since enclosures are the easiest parts to replace, modify, and rapidly prototype (eg. print). My enclosure arrived with cracks, and the D-pad fell out of the housing. I do think that the current D-pad design does not have enough overhang keeping it from falling out. Also, the precision of the plastic parts was not very accurate. I'd suggest aiming for a stock enclosure that's designed for printing on commodity FDM hardware (eg. Prusa printers). Like I said before, I think the enclosure is one of the least important issues, since it's the easiest aspect for the community to contribute to, and for users to replace. I've already designed and printed a new enclosure for my unit.

Sorry for the length here! I tried to be pretty thorough. You've made a nice tiny device here, but I do think it needs a fair amount of design revision in order to be a really fun, usable, and polished product.

1.There is something wrong with the L button, which is different from the R button
2.There is a problem with the direction key. It can't hold it. It will fall out of the case

I have a gg micro, and this vs that with this screen is night and day. the screen on this is far better.

however i would prefer better sg-1000 implementation.
i guess it's a hidden feature but i'm getting improper colors and speed on the sms emulator.

and also coming from the gg micro, it uses 240x180 and that should be fine as an option for most of the emulators on this device, (given the micro is a smaller screen). and imo preferred as it maintains 4:3, wasted pixels suck, but native resolution is more important.

sound and certain aspects suck, badly tbh, but should be fixed with firmware. i suggest talking with the game box mini team at myretro game case, as they sell esp 32 and similar devices.
(gamebox mini being very)

there's some mods for the odroid go firmware, which i thought this would be at least similar to, given that was an esp32, suggest maybe getting in touch there.
the rghanandhelds.com discord may be helpful for finding people.

Hi! Got MicroByte from CrowdSupply but cannot make it run.

I've formatted a 32 GB MicroSD card to FAT32 with default allocation size.

I've inserted the card into MicroByte to generate folders, then copied 128 uncompressed GameBoy games (.gb file extension) and 91 uncompressed GameBoy Color games (.gbc file extension) to the corresponding folders.

The device freezes when I select GameBoy or GameBoy Color in the Emulators section.

If I select any other emulator, it displays "Oops! Any game available." and then freezes in a weird way: I see the Emulators menu item, I cannot go left, right or up. When I hit A, I see the settings menu. When I go up (B), I see the Emulators menu item again.

The device reports firmware version v0.6-41-g4064fdc-dirty.

I put the microByte_0.83.bin file into the MicroSD root. This let me enter the Update firmware submenu. But the only item there is mangled. It's eiether just ? or something weird like ?6@@bla (cannot remember exactly`. When I select this item, the device reboots immediately and reports the old version.

Please help.

The face buttons are EXTREMELY mushy and tight fitting making it hard to accurately press and release them. The whole face-plate is also pretty flexible, making the issue worse.

hello , Really do like your project ! ,
I have managed to get most all the components
LCD ST7789 ,TCA9555 , ESP32-wrover 16MB flash but RAM 4MB ONLY not 8MB
it seems working OK , screen , buttons all OK
except the SD-CARD problem not getting Detected
I have tried too many SD-CARDs and modules (micro sd , MMC ), ( FAT16 and FAT32 ) as well tested , NO Luck ,
PINs are connected as they mentioned in system_configuration.h

/********************************

• SD CARD pin configuration
• ******************************/

#define VSPI_MOSI 23
#define VSPI_MISO 19
#define VSPI_CLK 18
#define VSPI_CS0 5

Any Help , suggustions ,

Thanks A Lot ,