You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
I really appreciate your feedback it's very detailed and constructive! I can only say thank you so much for your time to write this text and the useful comments.
I agree with most of your comments, and sometimes it is difficult to see from your own when you are working on it. I will continue working on the firmware to fix the issues and try to optimize it.
A note about the case, I just finished re-printing my case on my anycubic Photon S and after a bit of sanding and post prep it is way nicer than the factory case that warped due to heat exposer. That being said I was able to print mine on the Prusa Mini + first and really enjoyed it as well.
Firmware issues, I've reported the bug you listed on the firmware github as well.
Overall this is an amazing little board and great for road trips with the kids... Mine can't see anything wrong with it and that's perfect for me!
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.
The text was updated successfully, but these errors were encountered: