First Review of RetroN 77

[Flojomojo]

I have really had a devil of a time getting controllers to work in emulators though.

 

So, let me display my ignorance here. I was trying to get the syzygy usb joystick to work with stella on my raspberry pi and system logs said it saw 2 axis, 8 button, 0 hats. There was no way to remap the thing because it didn't register. And what the #$@@ is a hat? Never mind, I don't need to know.

Tough luck, I'll tell you anyway, since this is kinda off topic. A "hat" is a feature on a flightstick joystick. It's typically a little 4-way stick on top that you manipulate with your thumb, usually for different views, but customizable to other functions like selecting missiles. On modern controllers like an Xbox 360 stick, it's often set to the D-Pad. https://en.wikipedia.org/wiki/Joystick#Hat_switch

[Andromeda Stardust]

I have really had a devil of a time getting controllers to work in emulators though.

 

So, let me display my ignorance here. I was trying to get the syzygy usb joystick to work with stella on my raspberry pi and system logs said it saw 2 axis, 8 button, 0 hats. There was no way to remap the thing because it didn't register. And what the #$@@ is a hat? Never mind, I don't need to know.

 

I will be so glad to get my Retron 77!

I discovered a flaw some years ago attempting to pair my RetroUSB NES adapter to Stella. For some reason, the NES adapter had a digital X/Y axis and 8 buttons, the last four unpopulated. Why? Because the NES and SNES adapters are the same hardware. The NES controller sends out 8 pulses, whereas the SNES controller sends out 12 button pulses plus 4 key pulses. The key pulses identify the controller type but otherwise are not tied to inputs. The first 4 pulses are the Dpad, followed by Start/Select/A/B, then the last 4 pulses are null on the NES. On the SNES, it's Dpad, then Start/Select/B/Y, then finally A/X/LT/RT. So where does this tie into Stella?

 

On the RetroUSB NES adapter, tested in control panel, the first four buttons returned Start/Select/B/A. In Stella, none of the buttons worked. On the RetroUSB SNES adapter, same x/y axis, same 8 buttons. Button A on the SNES pad corresponded to button 5 in the control panel. So far so good. Well when I pressed the A button in stella, it mapped to button 1 [!]. Likewise X button mapped to button 2, and LT/RT mapped to buttons 3/4. Where were the inputs that Windows Control panel recognized as 1-4? They weren't detectable at all in Stella. Buttons 5-8 (Windows Control Panel) detected as buttons 1-4 in Stella. So no wonder the NES controller adapter (electrically identical to the SNES controller adapter) didn't work.

 

So, for some USB controller adapters which have more than four buttons, Stella basically ignores the first four button inputs. Why, I have no idea. And if the USB controller adapter can only output to the first four logical buttons, there is no way to register them in Stella. Granted this was a few years ago, and I posted my complaints in the Stella forum of AtariAge, but I don't know if it was ever addressed. Stephena is actively reading this thread, so maybe he'll have an answer for why that behavior existed or if it was ever fixed.

 

Once I got my Harmony cart, I did almost all of my playing on the Atari and forgot Stella for a while. So I don't know if the bug was ever fixed, but some controller adapters with a bunch of extra unused inputs, basically had the first four inputs ignored. If the Sygyzy controller adapter had the same encoding (from the USB port side) as the RetroUSB adapters that I previously had issues with, then the emulator may not be recognizing the first four inputs. And if the adapter maps the FIRE button as button 1, and Stella can't see the first four inputs, then your controller may as well not even have that red button on it because Stella can't see it.

[Keatah]

And the big problem with 'lists' like these is that it will only be a short while before someone quotes it and posts it as fact in some 'publication'

 

..and word goes around on the internet. That's essentially what happened right here. What else is new? And if it gets published or quoted, that's fine by me as it is fact. It describes the perceptions and viewpoints as people see it. I have no qualms or moments of cringing under the desk or anything. I really don't care, it is what it is.

 

Over the past 4-5 years I have followed multiple forums, had personal discussions, watched newbies playing with emulators for the first time.. and more.. Those are the common misconceptions and perceptions on how a non-technically (not developer) oriented gamer views software emulators.

 

Now. MY own personal pet-peeves with software emulators are few, but I do have them.

 

1- Gradually increasing system requirements, however slow or fast the rate. There are now shaders that absolutely require 4+ GHz and a high-end GPU. Just for shaders! And this is because of high level languages and APIs stacked upon APIs. I also take note of the benefit of increasing accuracy - it doesn't go unappreciated.

 

2- Different interfaces and conventions for each emulator. It's all rather confusing and does take some mental energy to context switch between them if you're not used to doing it. Altirra is different from Stella which is different from VICE, WinUAE, and M.A.M.E. Sometimes switching between emus (unless you have them set up to a "T") is tedious. I understand this is unavoidable, developers can't be forced to adhere to a common standard. But nevertheless it is pain point.

 

4- Smaller odds and ends, some of which are WIP on some emulators. And various other minutiae.

 

---

 

At some undetermined point in the future I will list out the extraordinary benefits of software emulators. Currently it's at 167 items and needs combining and de-duping. It will still be around 75 points. I would list them now though my research isn't finished. So we wait.

[Andromeda Stardust]

Tough luck, I'll tell you anyway, since this is kinda off topic. A "hat" is a feature on a flightstick joystick. It's typically a little 4-way stick on top that you manipulate with your thumb, usually for different views, but customizable to other functions like selecting missiles. On modern controllers like an Xbox 360 stick, it's often set to the D-Pad. https://en.wikipedia.org/wiki/Joystick#Hat_switch

Because someone asked what a "POV hat" was, I felt obliged to share it with you folks...

 

 

This is Cappy. He's a hat, and he lives on top of a famous plumber's head. Being sentient, he has his own POV (Point of View) separate from that of the wearer. He's the physical embodiment of a "POV hat." Sorry, couldn't resist the pun...

https://www.mariowiki.com/Cappy

 

[Thomas Jentzsch]

But isn't it fair to say that if your going to go with a cartridge slot today, fpga emulation is a better choice.

Why? Because FPGA emulates in hardware?

 

To me it looks like completely subjective views play a major role here.

[Thomas Jentzsch]

I discovered a flaw some years ago attempting to pair my RetroUSB NES adapter to Stella.

Did you contact Stephen back then? If not, please open an issue on GitHub, please.

 

If Stephen has the controllers available, I am sure he will want to look into this.

 

BTW: With an FPGA failing, you would be lost now.

[Andromeda Stardust]

 

At some undetermined point in the future I will list out the extraordinary benefits of software emulators. Currently it's at 167 items and needs combining and de-duping. It will still be around 75 points. I would list them now though my research isn't finished. So we wait.

Your research into emulation will never be finished Keatah. You should just post what you have now while you're still alive. You can edit it and make addendums whenever you want.

 

You will be buried with your hard drives full of ROMs. Maybe they'll be buried with you and share a casket. Maybe you'll be in a cemetery and the ROMs will be in a landfill. Maybe you'll be cremated and the hard drives will be recycled to make boat anchors.

 

But rest assured that your efforts in preservation have not gone unnoticed, and at any moment in time for at least the next few centuries, there will be millions of hard disks scattered across the planet with copies of all the files you've collected, some encrypted and locked away, some open for inspection.

 

But emulators and ROMs will outlive you. They will outlive their authors and developers. They will outlive the systems they were developed for, and the physical media that originally embodied them. They will outlive the media they were copied from, and they will outlive the media they were copied to. Copies of copies of copies will be enjoyed across the galaxy by extraterrestrials or whatever humans ultimately evolve into.

 

Someday in a post-human universe, when a post earth is scorched by an ever expanding post sun, some geeky space cadet will be exploring our old video games, running them in some sort of hyper virtual machine running on a quantum computer. The hyper virtual machine runs a silicon die emulator, running some ancient version of Windows / Linux, running a PC emulator running classic console and arcade games.

 

There is no physical joystick interface, just mind control, cybernetic beings feeding digi5tal inputs into and interface sending back little rectangular bits of color and crude sounds, small interactive binaries being worshipped as gifts from the distal ancestors, carbon based lifeforms whom slowly outsourced themselves into extinction by crafting silicon based beings relying on streams of bits and electrical impulses as a form of consciousness.

 

Wow, that was a fun stream of consiousness...

[Andromeda Stardust]

Did you contact Stephen back then? If not, please open an issue on GitHub, please.

 

If Stephen has the controllers available, I am sure he will want to look into this.

 

BTW: With an FPGA failing, you would be lost now.

Here is where I first posted about the issue:

http://atariage.com/forums/topic/228366-anybody-have-syzygy-controllers-that-wont-work-in-stella/?p=3045661

 

I have a similar problem with the retrousb NES/SNES USB adapters. On the NES USB adapter, Stella detects the joypad but not the action buttons. On the SNES controller, B, Y, Select, and Start act as buttons 1-4. A, X, L, and R act as buttons 5-8. On Stella, buttons 1-4 on the USB controller are not detected, and buttons 5-8 (based on Windows Control Panel) are detected as buttons 1-4 in Stella. So the workaround for me was to use the USB-to-SNES RetroUSB adapter and the "A" button, which mapped as button 5 in control panel, button 1 in Stella. I notified the author of Stella of this bug some time ago. Stella recently released version 4. It is sad they haven't fixed this yet. For some reason, Stella doesn't detect buttons 1-4, only buttons 5 & up. Some USB controllers exhibit this bug, others apparently don't. I use windows 8 64-bit btw, but apparently, the bug affects HID USB controllers in other OS such as Mac OSX.

 

Another (earlier) mention of the same issue here:

http://atariage.com/forums/topic/181321-announcing-new-2600-controller-usb-adaptor/?p=2947801

 

Cool beans. I've got a disconnect switch on the paddle lines to optionally disable paddle control on my custom joystick (although most joystick games ignore these inputs so it's safe to leave it turned on most of the time), so this adapter seems like it will come in handy.

 

Unfortunately there is a bug with Stella that for some reason ignores the first four inputs on all my RetroUSB NES/SNES/Genesis adapters, making the NES and 3-button Genny controllers impossible to use for some reason. As a workaround, SNES "A" button (button 5 in the control panel; shows up as button 1 in Stella) works fine. Stella bugs excluded, the RetroUSB Atari adapter is redundant because the Genesis one already works with Atari joysticks (Fire button activates two separate inputs though), but I like the idea of using Paddle controls in Stella so I'm going to give your 2600 'dapter a try. Thanks for the quick response...

 

I'm not on Github btw. I'll test the RetroUSB adapters later with Stella 5 when I get around to it.

 

The RetroUSB adapters are here:

https://www.retrousb.com/index.php?cPath=21&osCsid=8c146dc297e9454a703244b37a995a2d

 

Apparently it appears there is a new version of the NES adapter so I don't know if it's still affected or not.

[Keatah]

Why? Because FPGA emulates in hardware?

 

To me it looks like completely subjective views play a major role here.

 

To me it is matching modes of usage and operation. Real hardware with real FPGA with real carts and real non-virtualized controllers. That's one way of doing things. All hardware.

 

If going software emulation, then go with binary dumps and virtualized/different/host controls, on-screen menus and options and filesystems and all that. A virtual/software environment. Some emulators are practically separate virtualized OS'es already.

 

It's like pairing fine wine and making a meal. Match the ingredients and the meal comes out right.

Edited June 24, 2018 by Keatah

[Lordmonkus]

 

1- Gradually increasing system requirements, however slow or fast the rate. There are now shaders that absolutely require 4+ GHz and a high-end GPU. Just for shaders! And this is because of high level languages and APIs stacked upon APIs. I also take note of the benefit of increasing accuracy - it doesn't go unappreciated.

 

 

I would like to speak to this point, the better and heavier shaders are purely graphics card dependent but you don't need anything super fancy at all. I have a terrible 10+ year old PC hooked up to my TV for emulation of older stuff. It has a terrible 2.4 GHz AMD CPU and an old Radeon 7900 series graphics card with 1 gig of DDR5 VRAM and it handles everything up to PS1 emulation with the heaviest shaders in Retroarch (CRT-Royale) without issue.

 

You do however need a fast CPU the more modern of a system you are emulating and emulation accuracy drives up the system requirements again. This is why Higan has much higher requirements than Snes9x.

 

Everything else you said though I 100% agree with and your list is pretty much spot on except controller setup. Setting up a controller in Retroarch and Mame is pretty simple and if you stick to the mainstream systems you can get by on those 2 emulators alone (yes I know Retroarch is not an emulator). Now if only someone would update the Stella core in Retroarch, stupid 3 point whatever version they use makes me sad.

[Keatah]

Did you contact Stephen back then? If not, please open an issue on GitHub, please.

 

If Stephen has the controllers available, I am sure he will want to look into this.

 

BTW: With an FPGA failing, you would be lost now.

 

That is an entire chapter in my book. The long-running support SE enjoys. Even as one developer leaves a project, another one usually takes over. The support for SE projects has exceeded all my expectations and all of the FPGA projects I know of except one.

[Keatah]

Wow, that was a fun stream of consiousness...

 

That makes my evening!

 

The biggest and most impressive emulator I can imagine would need a Type III civilization to construct. A whole galaxy being the CPU or compute-structure. And the individual stars are the elements, with their variability and different forms of radiation forming the compute elements.

 

Entire solar systems representing storage elements and alternate data streams encoded on planetary surfaces and in the atmospheres.. Lesser alien life forms operating cargo routes and freighters moving data along constantly changing routes..

Edited June 24, 2018 by Keatah

[Thomas Jentzsch]

To me it is matching modes of usage and operation. Real hardware with real FPGA with real carts and real non-virtualized controllers. That's one way of doing things. All hardware.

That's your subjective perception. Fine.

 

IMO, the only "real" hardware is a VCS console, an FPGA only emulates that in hardware. IMO this is the same as emulating in software. Also one can attach real controllers to Stella using e.g. 2600-daptor. So IMO that only leaves the real carts. And there RetroN 77 closes the gap.

[Thomas Jentzsch]

I'm not on Github btw.

If you are really interested into this issue, why don't you join? It takes just 1 minute of your time. Stephen has repeatedly given the link and asked people for creating their issues instead of just complaining in forums. This would help us developers tracking, prioritizing, assigning etc. a lot. Also it makes our work very transparent to anyone who cares.

 

Anyway, I created the issue for your.

Edited June 24, 2018 by Thomas Jentzsch

[youxia]

These discussions make me glad that my "strict" ruleset is fairly limited when it comes to retro gaming (at least compared to some folks). First rule is about CRTs - if I don't have one around, I won't bother with retro games. The other is that I won't emulate anything above ~ PS1 - while it may be impressive there are almost always some glitches present. This hobby would turn into a chore if I was to add any more regulations.

 

I do overall support efforts of accuracy freaks such as byuu or FPGA builders, undoubtedly we should always strive for 100% & 1:1 at the cutting edge But there's no avoiding the fact that sometimes proponents of these solutions leave the domain of reason and step into the zealotry zone. For me the only thing that matters is what happens on the screen, and how it is achieved is much less of a concern. Original, simulated or emulated - whatever. As long as the output is good enough (and I believe the one under aforementioned limit is) I'm cool with any method.

 

As it is, I believe the whole "lag" debacle is vastly exaggerated. Undeniably educating folks why it is a bad thing is much needed and commendable, but as with so many things on the internet it also often escalates into the extremes, where some types will sneer at you if you don't sport the latest "zero" lag solution (even though your modern TV will add some anyway).

 

Meanwhile most gamers won't care a jot for a few frames of lag and it also won't matter much unless you're a speedrunner, 1CC'er or some other kind of Street Fighter. Recently I've done a test using the frame advance feature on my RPi 3, wired pad and a CRT and came up with results ranging between 1-5 delayed frames, differing between systems (MAME the biggest culprit unusrprisingly). This is entirely tolerable for me. My CRT is definitely a plus factor but others might be using more powerful machine, low-latency TV or even the latest tricks like the "lagfix" which libretro have just introduced. So, it's also possible to stay within a reasonable limit.

 

Not everybody has enough time, patience or $$$s to have every system either in original form or the FPGA one, or cares about zero lag or connecting some original peripherials. Emulation is therefore a totally viable solution and should not be demonised.

[mr_me]

Why? Because FPGA emulates in hardware?

 

To me it looks like completely subjective views play a major role here.

It's because fpga emulation achieves better cartridge compatibility than software emulation. Even if it's possible to achieve similar cartridge compatibility with software emulation, would it be worth the effort?

[Thomas Jentzsch]

It's because fpga emulation achieves better cartridge compatibility than software emulation.

What makes you believe so? What kind of magic do you expect to happen just because it is hardware emulation?

 

Effectively the opposite is true. Since software can be updated regularly, it will stay compatible even with never games.

[DirtyHairy]

It's because fpga emulation achieves better cartridge compatibility than software emulation. Even if it's possible to achieve similar cartridge compatibility with software emulation, would it be worth the effort?

 

 

A FPGA based emulator is still precisely that: an emulator. It is written in Verilog or VHDL, and it is compiled to a dedicated arrangement of gates instead of an executable for a general purpose machine, but it still remains an emulator, not a recreation of the original hardware. Its faithfulness depends on the accuracy the hardware model, just as with a software emulator.

 

If you want to plug in and play original hardware cartridges, just get yourself a VCS — that’s the only way to do really achieve 100% compatibility Other than that, there is no reason to expect more from a FPGA that from a software emulator.

 

Concerning lag: as Stephen already said, typical input lag with Stella (and any other good emulator) is about one frame — that’s 20msec at most, about an order of magnitude below human reaction speed. I am convinced that is much too low for most people to even notice. To put things into perspective: sound travels 7 meters in 20msec. In addition, games usually process input only once per frame, too.

Edited June 24, 2018 by DirtyHairy

[mr_me]

You don't have to understand the difference between fpga emulation and software emulation; you don't have to expect anything but compare existing fpga implementations with existing software implementations. Software emulation has many advantages over hardware emulatiom but cartridge support is not one of them. The importance of cartridge support is debateable anyway.

[Thomas Jentzsch]

Uhm... You are aware that RetroN 77 does software emulation and has a cartridge slot?

[+xucaen]

And what the #$@@ is a hat?

 

 

https://forums.x-plane.org/index.php?/forums/topic/26178-what-is-a-hat-switch-on-a-joystick/

 

 

Never mind, I don't need to know.

 

Oh, umm... never mind, nothing to see here. *whistles innocently*

[+stephena]

Here is where I first posted about the issue:

http://atariage.com/forums/topic/228366-anybody-have-syzygy-controllers-that-wont-work-in-stella/?p=3045661

 

Another (earlier) mention of the same issue here:

http://atariage.com/forums/topic/181321-announcing-new-2600-controller-usb-adaptor/?p=2947801

 

The RetroUSB adapters are here:

https://www.retrousb.com/index.php?cPath=21&osCsid=8c146dc297e9454a703244b37a995a2d

 

Apparently it appears there is a new version of the NES adapter so I don't know if it's still affected or not.

 

Please tell me exactly which adaptors on the RetroUSB page are causing you issues.

 

I already have the SNES version (and original SNES controller) to use for testing. I'd be willing to purchase both a Genesis and Atari version to do further testing. There is currently no point in me buying the NES one, since I don't have an NES controller (unless someone wants to donate one ).

[Keatah]

These discussions make me glad that my "strict" ruleset is fairly limited when it comes to retro gaming (at least compared to some folks). First rule is about CRTs - if I don't have one around, I won't bother with retro games. The other is that I won't emulate anything above ~ PS1 - while it may be impressive there are almost always some glitches present. This hobby would turn into a chore if I was to add any more regulations.

 

My gaming rules are even simpler. And there is only one. Can I play it natively or through emulation on the PC?

 

The reasoning:

This has enabled me to keep nice aesthetically pleasing working and living areas. And it has reduced frustration by not having to manage mounds of electronics, cables, controllers, carts, and various connectors. Frustration has also been eliminated through reliability and convenience. Emulated consoles never break down or require maintenance other than curation, organization, and the occasional update. Frankly that can happen at any time in any size time slot - in other words I don't have to set aside time in bulk.

 

Emulation also lets me fulfill a childhood dream of wanting all my (then) gaming systems to be put into one "superbox" that plays it all.

 

And I STILL have material from the Apple II days I have yet to go through as well as newer present-day AAA titles. I may do the occasional tablet game - but that comes out to be like 2 hours a month at best and often in a social situation.

 

 

Not everybody has enough time, patience or $$$s to have every system either in original form or the FPGA one, or cares about zero lag or connecting some original peripherals. Emulation is therefore a totally viable solution and should not be demonized.

 

Unfortunately it still is, and it's on the rise.

 

FPGA solutions tend to be simpler and familiar in practical real-world usage. They plug-in like original hardware, they accept cartridges like original hardware, and have a simple power button.

 

A software emulator requires basic computer skills to get going. You have to install the executable, assign folders, and set video parameters, among other things. While those things are old hat to computer hobbyists. They are totally alien to the new moms and dads of today. And even kids are resistant to learning how it fits together. They just don't want to do it. Much easier to fart around with physical consoles that are not abstracted away into file folders and whatnot. Or much easier to click on "app" icons.

 

Heh. I once replied to a thread that asked how many VCS consoles everyone has. I said I had a virtual console through emulation, and was for all intents and purposes told to go away because emulation was meaningless. Virtual consoles don't count. Seems like emulation remains the whipping boy.

[Keatah]

It's because fpga emulation achieves better cartridge compatibility than software emulation. Even if it's possible to achieve similar cartridge compatibility with software emulation, would it be worth the effort?

 

It is not worth the effort in my opinion. It may result in an amusing exercise in compatibility testing, sure. But there are many limitations. Software Emulation as it exists today isn't meant to drive a cartridge slot. And that is ok. It's simply different.

 

FPGA is a physical chip that you can purchase from Digi-Key and do things with in the physical realm. And because it has programmable i/o pins it's a natural for talking to cartridges.

 

While you can program a general purpose CPU to communicate with a cart as well, you need to have some i/o pins or interface that is capable of accessing the cart. And you need the appropriate instructions (or program) to talk to the cart. And it is the depth and capability of the interface that makes the difference. The R77 interface doesn't seem that capable.

 

That is something that costs time and money, and no one wants to do that. So you go with the cheap solution.

 

Whether it is a software limitation or hardware limitation, none of will know until a teardown occurs.

 

 

[Lordmonkus]

What kills me most about emulation haters is they dump all over emulation when done on PC the traditional way but as soon as someone does it "officially" it's all good. Take the recent release of Donkey Kong on the Switch, people who would normally rage on playing the arcade version any other way than a real arcade cabinet are now suddenly perfectly fine to play it using Nintendos emulator. They somehow think Nintendo "isn't emulating" or their emulator is somehow better.