FPGA Based Videogame System

[Andromeda Stardust]

Can the Analogue Nt Mini output HDMI and analog video at the same time? Because if it does, you can use the composite signal from the analog port to implement this mod without any further tweaking :

 

 

Also, what style of composite video does the Nt Mini output? Is it the jagged three-line staircased (sharper but HD unfriendly) video of a true NES or is it like the NESRGB's straighter but softer composite video?

Unfortunately simultaneous HD and SD output is not possible due to incompatible timings. I believe composite or analog video is disabled if HDMI is hooked up at boot.

[kevtris]

Unfortunately simultaneous HD and SD output is not possible due to incompatible timings. I believe composite or analog video is disabled if HDMI is hooked up at boot.

Well you can switch back and forth at will, but yes it's either one or the other at one time. Hitting select+right will switch to analog output, hitting it again will switch back to digital. It defaults to analog if no HDMI cable is plugged in. i.e. if you unplug it. Plugging HDMI in will switch back to that from analog. You can use the select+right hot key though to switch from HDMI to analog and back, so long as an HDMI cable is plugged in.

 

To support both at the same time I would've had to have a bigger FPGA and a frame buffer, so that's why it doesn't. In analog modes it outputs native frame rate (i.e. for NES it's 60.09) vs. 60.00 for HDMI.

[Great Hierophant]

Well you can switch back and forth at will, but yes it's either one or the other at one time. Hitting select+right will switch to analog output, hitting it again will switch back to digital. It defaults to analog if no HDMI cable is plugged in. i.e. if you unplug it. Plugging HDMI in will switch back to that from analog. You can use the select+right hot key though to switch from HDMI to analog and back, so long as an HDMI cable is plugged in.

 

To support both at the same time I would've had to have a bigger FPGA and a frame buffer, so that's why it doesn't. In analog modes it outputs native frame rate (i.e. for NES it's 60.09) vs. 60.00 for HDMI.

 

Thank you for the concise explanation. Does your composite video output include the quirks of the 2C02's video output, the three line staircase and the dot crawl, or is it like the NESRGB's composite?

[Andromeda Stardust]

 

Thank you for the concise explanation. Does your composite video output include the quirks of the 2C02's video output, the three line staircase and the dot crawl, or is it like the NESRGB's composite?

I would imagine most people would prefer it be clean and free of artifacts, but I have no idea how close the actual match is. The three dot crawl is kinda neat, creating yellow/cyan/magenta moire patterns in some cases. This is evident on the Turtles III game with the diagonal bars in the first stage.

[kevtris]

 

Thank you for the concise explanation. Does your composite video output include the quirks of the 2C02's video output, the three line staircase and the dot crawl, or is it like the NESRGB's composite?

It sure does. in NES mode, it is outputting an *exact* reproduction of the NES composite. This includes all artifacts, voltage levels, timing, etc. The dot crawl and everything should be absolutely identical to a real NES, including emphasis bits. The s-video mode is the same... if the NES could've outputted s-video. It uses the same voltage levels, timing, etc. the luma levels are the average of the toggling signal that the NES uses to create luma+chroma.

 

For other cores, I have a digital RGB to composite/s-video converter that runs directly on the FPGA. It is possible to send the NES RGB through this, and in fact I had it set up to do this at one point but it doesn't work now since I broke it somehow. I was going to eventually fix this. So it might come back at some point.

[kevtris]

 

 

Honestly this is probably the easiest solution, start a repo for all your projects(even if you don't share the code), and then we can post issues against them if we find bugs.

 

On that note, @kevtris, how open is the system currently? In the way it's currently setup can I program my own cores and use the firmware upgrade process to flash them in safely just targeting the fpga chip(without risking the original functionality). I realized it'd be kinda fun to use it as a decent devboard with a lot of fun peripheral options(hdmi/analog, controllers, sound etc), the stuff that's normally tedious to program yourself in verilog/vhdl on random boards(or pay yuck license fees to access premade modules) but could be fun to piggyback off of on an existing design to make game-centric circuits that I could share with the community.

 

I haven't looked at it seriously, but it'd be nice to know if sharing some of the info to facilitate that is feasible, or if I'd need to basically reverse engineer it to do what I'm thinking.

 

At this time it isn't an open system, sorry 'bout that.

 

I have a few bugs to report for the Analogue NT Mini Jailbreak Firmware using the SD Card loading.

 

US / JP Games:

*Holy Diver: Graphics seem to be wrapping about 1/4 of the way into whatever direction you move resulting in block appearing where they are not.

*Kaijuu Monogatari: Blue Screen on boot.

*Kid Niki 2: Freezes after intro.

*Kid Niki 3: Flickering textures.

 

FDS Games:

*Battery Err L02 on any FDS game that boots up with the "Nintendo Please set Disk Card" screen.

 

Hacks:

*FF7 Advent Children Complete - The start screen actually loads which is more than flash carts can do but when you hit new game the game seems to loop back to the start screen.

* Holy diver seems to be an actual problem here too, so I will add it to my todo.

 

* The other three games are all mapper 16/32 I believe, and require an NES 2.0 header to work properly. Those two mappers are actually multiple mappers and the nt mini needs more clues on how to distinguish them.

 

* I don't support FDS games yet.

 

* I have not seen that FF7 hack before. maybe it needs RAM and crashes/fails because of that?

 

 

I think it's also crucial to create a guideline ("read this first") on how to report bugs affecting your projects properly. This is to avoid invalid and duplicate reports. For example, the guideline might instruct people to:

• report exactly what version of the game they're playing including region and revision info
• include hardware they're using (in the case of the Hi Def NES or Nt mini peripherals)
• provide TV model
• test the game on the original hardware (whenever possible)
• write what settings were used
• use only good ROM dumps for testing (maybe only No-Intro and in some instances goodset ROMs should be allowed when reporting?)
• format their SD cards in proper way; correct file system, allocation size, etc. (BTW, kevtris, what do you think about SD Card Formatter? Some SD card manufacturers strongly recommend it.)
• what SD card to use
• avoid situations when data on the SD card might get corrupted like forgetting to safely remove the SD card
• clean cartridges before reporting (cleaning tips included, some people don't know about the eraser method. One more question, does the Nt mini require cleaner carts than the original NES? I've heard that games which work on the NES, sometimes need cleaning before running them on the mini.
• read what the limitations of FPGAs (included in the guideline) are, so that they won't keep asking for something impossible
• etc.

There are actually bug trackers which force the user to fill certain text fields before clicking the "report" button. This increases validity ratio.

yeah these are good ideas, thanks!

[simbin]

Kevtris, Will your Sega Master System core support FM audio on the Analogue NT Mini?

 

I think if you can add PC Engine/SuperGrafx support, it could justify the purchase for many who don't already own a SuperGrafx. Really wouldn't need a controller adapter either.

[kevtris]

Kevtris, Will your Sega Master System core support FM audio on the Analogue NT Mini?

 

I think if you can add PC Engine/SuperGrafx support, it could justify the purchase for many who don't already own a SuperGrafx. Really wouldn't need a controller adapter either.

Yes, the SMS core supports FM. it's got that "release bit" issue which I am going to try and fix before I release the core. This is technically broken in the VRC7 too but it isn't very obvious. On the SMS the music sounds great but some games have sound effects that don't end, basically. other games' SFX sound great.

[Andromeda Stardust]

@kevtris, not trying to derail your thread at all, but as the one of the most knowledgable people in the forums, what is your opinion of the "Hybrid Emulation" bit the Retroblox guys are pitching? Basically in a nutshell he is using a 1.7Ghz ARM CPU to interface the cartridge port in a similar manner to how your FPGA cores operate.

 

WHAT’S HYBRID EMULATION?

 

Hybrid emulation is a completely new way of tackling emulation, providing the cost-effective and future-friendly advantages of high level emulation as well as the accuracy and compatibility advantages of using clone hardware or FPGAs (Field-Programmable Gate Arrays) to model the original consoles.

 

Hybrid Emulation is unique in that it requires software emulators to function at a much lower level than the ones you can simply download for your PC, Phone or RetroPie / RetroArch / LibRetro box. RetroBlox’s proprietary RBXOS and Richter UI environment are built from the ground up in Linux, fully optimized for our system so that we can access the architecture from the bus-level and I/O from cartridge interfaces and controllers directly via high level emulation on the heart of the system, the Rockchip RK3288. This means we don’t have to rely on software emulation of memory mappers and/or co-processors that may not be fully optimized, which in turn frees up valuable resources to ensure other aspects of the machine run smoothly. This is especially important to the homebrew community where many developers have created their own bank-switching and mapping mechanisms to extend the abilities of the original platform far beyond the manufacturers original intent. With Hybrid Emulation, we do not need to be privy to the intimate details of how the cartridge expansions function to have their software run on RetroBlox. It just works.

 

While this may sound like a magical, do everything under the sun console – some discerning folks recently asked what it WON’T do. Right off the bat, you won’t be able to play games that purely rely on light gun controller input. The limitations of light gun technology vs. HDTVs have been a constant struggle for those that enjoy the genre (including us!). However, we would like to address this issue sometime down the line after RetroBlox launches. For the moment, we are 100% focused on delivering what we have committed to above. Please note that light-gun type games that support controller D-Pad input will work fine on RetroBlox.

http://retroblox.com/2017/02/08/everything-you-need-to-know/

 

Probably your Zimba3000 idea, or even a jailbroken Analogue NT Mini, sounds like a safer bet, but I'm cautiously optimistic that these guys aren't total frauds like Mike Kennedy and Co.

 

Retroblox discussion thread: http://atariage.com/forums/topic/261689-retroblox/

[TheRedEye]

[ignore, I had a bug report but realized I could test more before reporting]

Edited February 9, 2017 by TheRedEye

[Guspaz]

@kevtris, not trying to derail your thread at all, but as the one of the most knowledgable people in the forums, what is your opinion of the "Hybrid Emulation" bit the Retroblox guys are pitching? Basically in a nutshell he is using a 1.7Ghz ARM CPU to interface the cartridge port in a similar manner to how your FPGA cores operate.

 

http://retroblox.com/2017/02/08/everything-you-need-to-know/

 

Probably your Zimba3000 idea, or even a jailbroken Analogue NT Mini, sounds like a safer bet, but I'm cautiously optimistic that these guys aren't total frauds like Mike Kennedy and Co.

 

Retroblox discussion thread: http://atariage.com/forums/topic/261689-retroblox/

 

It's basically the same as regular software emulation (and I'd doubt it'll be remotely close to cycle-accurate on a CPU that slow), except they're implementing the cartridge interface instead of trying to emulate all that stuff. It's true that it will improve compatibility/accuracy (no need for mappers, no need to emulate the VRC or MMC or whatnot), but I don't think it's really a panacea. The rest of the console is still emulated and using tricks to run fast enough.

[kevtris]

@kevtris, not trying to derail your thread at all, but as the one of the most knowledgable people in the forums, what is your opinion of the "Hybrid Emulation" bit the Retroblox guys are pitching? Basically in a nutshell he is using a 1.7Ghz ARM CPU to interface the cartridge port in a similar manner to how your FPGA cores operate.

 

http://retroblox.com/2017/02/08/everything-you-need-to-know/

 

Probably your Zimba3000 idea, or even a jailbroken Analogue NT Mini, sounds like a safer bet, but I'm cautiously optimistic that these guys aren't total frauds like Mike Kennedy and Co.

 

Retroblox discussion thread: http://atariage.com/forums/topic/261689-retroblox/

Yep posted my reply in that thread. Unlike the rest, you can buy this one today.

 

When I saw the Retroblox thread I was thinking about that Simpsons episode for some reason where Homer goes to professor Frink to learn how to be an inventor.

 

[retro_fan]

It sure does. in NES mode, it is outputting an *exact* reproduction of the NES composite. This includes all artifacts, voltage levels, timing, etc. The dot crawl and everything should be absolutely identical to a real NES, including emphasis bits. The s-video mode is the same... if the NES could've outputted s-video. It uses the same voltage levels, timing, etc. the luma levels are the average of the toggling signal that the NES uses to create luma+chroma.

 

For other cores, I have a digital RGB to composite/s-video converter that runs directly on the FPGA. It is possible to send the NES RGB through this, and in fact I had it set up to do this at one point but it doesn't work now since I broke it somehow. I was going to eventually fix this. So it might come back at some point.

Do you think that the Zimba 3000 might be useful for serious hardware preservation? Maybe some tech museums would be interested in your projects (a grant $$$)? Ask around. I think that in the future you could also try to reproduce analog outputs of other consoles with a similar level of precision as you did with the NES. Is there a better way to convince people to FPGA consoles than connecting an original console and an FPGA one to the same CRT TV model and showing that the output looks identical? Analogue should create such a comparison video for the Nt mini... This and a lag test...

 

[...]

 

* I have not seen that FF7 hack before. maybe it needs RAM and crashes/fails because of that?

The NES FF7 demake is one of the most interesting Chinese conversions. Read more about it at BootlegGames Wiki and while you're at it, you may also want to check Pokemon Yellow for the NES. I can see that people often use these two games to check the compatibility of clone consoles. I strongly suggest you look through other articles in BootlegGames Wiki, it's such a great resource! You might just find there candidates for new mappers.

Edited February 10, 2017 by retro_fan

[kevtris]

Do you think that the Zimba 3000 might be useful for serious hardware preservation? Maybe some tech museums would be interested in your projects (a grant $$$)? Ask around. I think that in the future you could also try to reproduce analog outputs of other consoles with a similar level of precision as you did with the NES. Is there a better way to convince people to FPGA consoles than connecting an original console and an FPGA one to the same CRT TV model and showing that the output looks identical? Analogue should create such a comparison video for the Nt mini... This and a lag test...

 

The NES FF7 demake is one of the most interesting Chinese conversions. Read more about it at BootlegGames Wiki and while you're at it, you may also want to check Pokemon Yellow for the NES. I can see that people often use these two games to check the compatibility of clone consoles. I strongly suggest you look through other articles in BootlegGames Wiki, it's such a great resource! You might just find there candidates for new mappers.

Well the other cores do that. They output as pretty much exact representation of the video, including timing and frame rate and everything. I did take a few minor liberties with the channel F since it outputted a weird number of scanlines (264?) and made a new frame buffer renderer that did 262. But since the system has zero feedback on the frame buffer's position relative to the CPU, cycle timed effects are impossible, so this works out. Other systems like the Master System output an exact copy of the video in RGB mode. The 7800 outputs the 263? scanlines like a real one (I think it's 263) and so on.

 

It pretty much is all a very low level approach to simulating/emulating everything from the real system. Both the 2600 and 7800 are transistor-level recreations pretty much. It's all identical logic and stuff. I had to use latches to simulate the pass transistors and such, but i.e. the DMA state machine is the exact identical one in the 7800. I even wrote a program to convert the PLA for it into verilog. I entered the PLA bits twice- once right side up and once upside down then the software checked it to make sure I didn't enter any wrong bits. There's actually a couple PLAs in there and I did this for all of them. It ended up working out well and the state machine works great.

 

All systems got hooked up to the logic analyzer and custom hardware was made to check out timing. This was important on the Odyssey^2 and Intellivision and for edge cases on the 2600's RIOT which weren't well documented.

[Kismet]

To FPGA or not to FPGA, that is the question. I signed up just to comment/vote, I read the entire 45-page or so thread to get here.

Admittedly, I didn't really know that much about FPGA's until last year when I saw the AVS and the NT Mini. Since then I've done significant research on the viability of certain consoles, computers and some other hardware. I've been using software emulators since the late 90's, and remember how awful many first generation free emulators were.

Suffice it to say, there is never going to be a one-size-fits-all-everyone-happy solution. So lets break this down:

• A modular/upgradable system makes the most sense as it requires the least investment in parts that people don't want or don't have an investment in. However a modular system ultimately costs the most, as everyone isn't subsidizing all the parts. The benefit here is that kevtris doesn't need to build all the modules, someone else can.
  

• 8-bit computer's and consoles can currently be emulated accurately enough on high end computers, so the market for the AVS, NT Mini, and various other FPGA-based systems is smaller than that of 16-bit. So I feel the Zimba 3000 should focus on being able to run all 16-bit consoles and computers. Emulating 16-bit consoles and computers has never been accurate enough, even on the highest-end computers. There is an entire generation of people who grew up without the SNES, Sega Genesis, Amiga, and have no idea that things like the Nintendo Virtual Console and PC-based computers aren't supposed to look, sound or have that much latency.
  

• I feel that ARM-based emulators (eg Raspberry Pi, Retron 5, Retro Freak and such) are a cop-out, as they rely on the inaccurate hacky/laggy emulators, and the crapshoot of TV compatibility (let's not assume TV manufactures care, and just side-step them by putting the scaler in the console,) providing no ability to use your existing game investment accurately. So the goal for the Zimba 3000 should be to "replace all 8-bit and 16-bit consoles, and their add-ons/expansion devices", while still allowing people who have a great investment in those games and accessories to use them, and save them from the landfill.
  

• The last argument is input and output. I think everyone is on the same page about the need for HDMI and SD card support in "this version" of the Zimba 3000, but I think many people are barking up the wrong tree about what is really viable on a FPGA while keeping the costs low.
  

• 4K TV's and monitors are available today, the 4k monitors are "gaming", but the TV's so far are pretty terrible. 8K TV's are around the corner, so planning for that today should be done, but maybe not in the current version of the Zimba 3000. These are going to be HDMI/Displayport over USB-C. It's entirely possible to drive 1080p from the FPGA (the NT Mini does this AFAIK,) but right now, even FPGA systems that support 4K, are often paired with HEVC decoder/encoders with the intent of being used for SmartTV's. So it's likely that the FPGA needed do to 4K/8K over DP/USB-C exceeds that of what kevtris wants to use. However, why not toss access to the main FPGA's output to the video expansion header so that at some point a "4K" or "8K" usb-c based complex scaler output could be built without having to put it into the onboard HDMI? Maybe leave the onboard HDMI as only a simple integer scaler. VGA, DVI, RGB(SCART/PVM), JAMMA, and so forth could be put on their own video boards.
  

• Original cartridges should be on an expansion bus. I'm not sure how kevtris wishes to do this as the number of address and data pins on the systems range from 24 pins on the Atari 2600 (13 address lines, 8 data, +5V and 2 ground), to SNES (16 address A bus, 8 address B bus, 8 data bus, 8 expansion bus, 16 SNES-specific pins, 2 Vcc, 2 ground, Left analog audio, right analog audio. ) From images seen, I don't see any 240 pin connector (Neo Geo MVS), so I get the feeling that a third FPGA might need to be involved, where this third FPGA sits on the end of the voltage shifters.
  

• Original controllers, keyboards, mice, joysticks should be on an expansion bus. This is likely best done by combining it with the cartridge expansion bus. EG (Z3K = Expansion bus - controller bus) or (Z3K - controller bus), thus allowing one to swap their Sega/Atari DB-9 with the NES/SNES controller bus if that's what they want. USB-C or USB connectors can be used for onboard USB HID, Xbox 360/Xbox One/PS3/PS4-style controllers, or HID USB-bridge (SNES, PSX, PS2, gamecube.) I don't think the Zimba 3K should even bother with wireless controllers.
  

• If it's modular enough, third parties can support computers (MSX, PC9801, DOS, etc) , obscure expansion cards, music devices (eg MT-32, midi devices) using the Zimba 3000 base hardware, and thus being able to justify lowering unit costs with higher quantity orders of parts. But if it's too flexible, it becomes aimless, and kevtris's time doesn't get used efficiently. In many ways, this feels a lot like the early 80's microcomputer era where people were building their own computers from kits. kevtris should probably make it clear that current generations of FPGA will not be able to do certain things and still be affordable. Like I've talked to people casually about what is possible in software, FPGA, dynamic recompiling, and so forth, and people are under the impression that everything can be done in FPGA. From what I understand, the highest-end CPU (alone) that can be emulated on a FPGA is the PS1, 32X/Saturn, 68020, Pentium (x86) @50Mhz but emulating these with a single FPGA today might be too expensive, and would require a multi-chip solution.
  

One thing that frequently becomes the unwanted focus in every emulation scene I've been to, is that people get extremely pedantic over the developers intent. In the PC/MSDOS emulation, it's incredibly difficult to get correct aspect ratio emulation since all the emulators have to use a framebuffer, thus one frame is buffered in system memory, and then it has to be integer sampled up and then rescaled down, sometimes at the expense of 3 frames of latency. But most DOS era games didn't use framebuffers (ISA bus is slow,) they wrote directly to the video cards memory. In the console emulation communities, we again get into the same arguments about "should it look pixeled" and again come back to the aspect ratio. Even in this thread. It is my belief that you shouldn't second-guess the developers intent. So integer-scaling should be the default, and only if the user opts to, let them override the aspect ratio and scaling. Not everyone wants to experience "the CRT effect" because as much as we want to say the CRT was better to play the games on, it was never good for your eyes, and no two CRT's have the same focus, color and brightness as they change with age, even if they all use the same phosphors.

Referring back to kevtris's block diagram, if it's made so that a "Zimba 3K" base unit can emulate most 8 and 16 bit systems, using USB and the SD-card, over HDMI, that solves about 50% of the needs of the people who would be willing to pay $200 for it. The other 50% would be willing to spend the extra money to get whatever expansion bus to enable 100% compatibility with real cartridges and controllers for a system (most NOAC/GOAC things are $20-40USD each by comparison, and they use the SNES as the base unit.) Then I think this is a solid direction. If at some later date a Zimba 3K2 or 4K (for 4K TV) comes along and also adds the ability to play something else that was impossible with the existing FPGA, all the existing expansion parts could still be used, and the previous generation Zimba3K is doesn't lose any value.

I do express a bit of reservation about the games being stored on a SD-card or being able to support copier/flash drives, since that encourages piracy, but if you're going to spend $200-$500 on an accurate FPGA console, you likely have the money to buy the games off eBay to have an accurate experience.

TL;DNR version: I look forward to seeing this. While I think 98% accurate software emulators might be good enough for people to just nostalgia trip (eg the Virtual Console service.) Those are not the intended audience of FPGA systems. I've looked at things like the MiST board, I feel these are not powerful enough, and make no attempt to address the need for upscaled HDMI connections.

Edited February 10, 2017 by Kismet

[Andromeda Stardust]

Awesome first post Kismet. You'll go far here.

[Keatah]

But most DOS era games didn't use framebuffers (ISA bus is slow,) they wrote directly to the video cards memory.

 

Videocard memory is the framebuffer.. Then there's double-buffering and triple buffering.

 

In other news: This z3k system may be the first "hardware" based system I can recommend. If it makes the grade I'll be happy to pick up 8 of them straight away. I also humbly suggest using the best, most feature-rich, parts available. If it makes the system more expensive then so be it. I'd hate to see things compromised because of cost alone.

Edited February 10, 2017 by Keatah

[Keatah]

 

To FPGA or not to FPGA, that is the question. I signed up just to comment/vote, I read the entire 45-page or so thread to get here.

Admittedly, I didn't really know that much about FPGA's until last year when I saw the AVS and the NT Mini. Since then I've done significant research on the viability of certain consoles, computers and some other hardware. I've been using software emulators since the late 90's, and remember how awful many first generation free emulators were.

 

Some were downright elementary. Indeed. Barely getting the job done, but they were there and bought hope (and the idea) of reliving classic gaming on the PC. Think Activision Action Packs, DASarcade, Microsoft Arcade (simulation re-write), the good old days of Windows 3.1 and MSDOS 6.22.

 

Today, now, we have quite sophisticated software emulators that are versatile and easy to use because they make use of the host's hardware and OS to provide the many conveniences a full-fledged file system can offer. This is something where I feel that all present-day FPGA rigs come up short.

 

Anyhow it's good to see effort going into both hardware and software based emulation.

Edited February 10, 2017 by Keatah

[roland p]

Today, now, we have quite sophisticated software emulators that are versatile and easy to use because they make use of the host's hardware and OS to provide the many conveniences a full-fledged file system can offer. This is something where I feel that all present-day FPGA rigs come up short.

 

Well, it would be cool if the Zimba had LAN so you can have a huge NAS with all games on it.

[Keatah]

Yes. Or some way to connect to mass storage at the same time the PC is connected. Then you'd have the ultimate in file management and organization. To me it's highly desirable feature,. Without it one is resigned to using cartridges or shuttling a series of SD cards back and forth.

[Kismet]

 

Videocard memory is the framebuffer.. Then there's double-buffering and triple buffering.

 

In other news: This z3k system may be the first "hardware" based system I can recommend. If it makes the grade I'll be happy to pick up 8 of them straight away. I also humbly suggest using the best, most feature-rich, parts available. If it makes the system more expensive then so be it. I'd hate to see things compromised because of cost alone.

I guess I should have said double-buffering.

 

I'd buy the z3K in a heartbeat even if it cost as much as the DE2-115 development board. If it costs $200 or less it's still a viable replacement. I'm only worried about companies like Nintendo or Sega trying to shut down these projects instead of trying to license them to build their own stand-alone virtual console version.

Edited February 10, 2017 by Kismet

[Andromeda Stardust]

Well, it would be cool if the Zimba had LAN so you can have a huge NAS with all games on it.

Nah, a 64Gb SD card is large enough to hold nearly every cartridge based ROM ever made, uncompressed. I believe GBA have the largest No-Intro set, followed closely by NEO-GEO and N64. Everything else is tiny by comparison.

 

ISOs for the CD systems are another story for storage however, but 5th gen and 6th gen are only currently accessible by emulation, and 6th gen (Dreamcast/PS2/Game Cube) really needs a modern x86 rig or a minimum Tegra X1 ARM to pull it off.

 

Switch reportedly has enough horsepower to run Game Cube VC at 480p. Doubtful they run it at 720p when the original hardware was 480p native.

[kevtris]

As promised, here's my latest firmware!

 

This update fixes several bugs and adds FOUR new systems!

 

* SG-1000 (place your games under /SMS for this)

* Sega Master System (yes with FM support, though a little bit buggy, I will fix it eventually)

* Game Gear

* Colecovision

 

So now the nt mini plays what nintendon't. (sorry, I had to)

 

These bugs were fixed:

 

* MMC5 square channels 2x too high in pitch (because of a code change)

* Holy Diver mapper mirroring (be sure to set NES2.0 submapper to 3)

* Crime Busters mapper fixed

* Hopefully the "hang on boot" for v0.9 was fixed. I did some refactoring from the last version. This only affected a small number of units though.

 

These things were changed/added:

 

* Changed the front LED to green so you know it's "doing stuff" on boot by default

* Added a dipswitch menu

* Added a menu to change how the B button works in the file browser (so you can choose your favourite mode)

* Dozens of code cleanups/fixes.

* Added GG/Coleco/SMS/SG-1000.

 

http://blog.kevtris.org/blogfiles/ntm_firmware_verJB1.0.zip

 

To upgrade to the latest you can either format your card and dump the new files on there, or update it piecemeal. If you have 0.9, updating to 1.0 requires you to do the following things:

 

* replace the entire /SYSTEM/ directory and its contents (the cores live here)

* add the /SMS/ /GG/ /COLECO/ and /BIOS/ directories

* replace the firmware .bin in the root directory with the new one.

 

Then after the card is done, you need to add the BIOS files for these various systems as indicated by the text file in the /BIOS/ directory.

 

Please read release notes on each system in their respective directory. The main readme has the changelog and some other things.

 

That's about it, enjoy!

[Pixelboy]

Still waiting for my NT Mini, but I plan to jailbreak it soon after I receive it. Thanks for the update, Kev!

 

Question: Did you look into the sound problem that happens after a couple of hours of play, which was reported by someone else earlier in this thread?

[TheRedEye]

I can't express how relieved I am to not have to invest in an RGB Game Gear anymore.

 

EDIT: Question for Kev: do you think this might become a ROM dumper for other systems once you start selling those cart connectors?

Edited February 11, 2017 by TheRedEye