First Review of RetroN 77

[+stephena]

Any input lag you see in an emulator (in general, and Stella in particular) is probably because the input is (a) coming from a USB device and (b) is only being inspected once per frame.

 

The host OS will package the input into a USB packet, and Stella (actually, SDL behind the scenes) will poll for events on each frame. If the OS is slow in packaging the input, it can be noticeable. And if Stella polls for the input during a frame after the ROM inspects the virtual 'pins' inside the console, it won't see it until the next frame, and again it can be noticeable.

 

None of this is insurmountable. The best way to do it would be for the emulator to have a direct connection to the input port, and when the ROM reads from (for example) SWCHA, it polls the port directly. Just like a real console would. Right now, most emulators work at a higher level of abstraction: host OS -> USB packet -> emulator receiving an event. The zero-lag option would change this to: emulator poll when necessary; no event is generated, but the input is read as it is needed.

 

EDIT: I point this out yet again to the "emulators are crap, FPGA is God" people. There is nothing that an FPGA can do that an emulator cannot, given sufficient hardware.

[Keatah]

In discussing differences about Paddles vs DrivingControllers, and how they work on a technical level, it is clear there are a lot of misconceptions. And I believe that there are loads of misconceptions and misunderstandings about Software Emulation and FPGA.

 

Without getting into too technical a discussion I'll simply use this as an opener..

 

Good to see that Stella 4 is performing well on this hardware; hopefully Stella 5 will be compatible too.

 

But overall, TBH it's kind of disheartening to see repeated mention that it would be so much better if it were using an FPGA (especially in the comments on the Youtube page). Really makes me kind of demotivated to see a lot of people basically saying that all the hard work that went into the emulation is wasted effort, and we should move to FPGA. There's still a lot of "emulation, so it must be crap" people around, it seems.

 

 

..which leads me into pulling some notes from my w.i.p. book Principia Emulata.

 

I'm not entirely sure why emulation gets the bad rap. Over the years I had lots of theories and taken notes. There is no one solid reason, but many. Here are some reasons that people state.

 

1- FPGA is exact precise hardware replication. Can't beat the authenticity of real hardware.

2- Software emulation is built around the complex and buggy PC ecosphere.

3- It's no trivial task to install, set-up, and assign folders, In fact, most users today do not know what a folder is.

4- One single dropped frame out of thousands upon thousands unleashes the wrath of a vocal minority. Imperfection!

5- FPGA plays real carts. Emulation plays but a copy.

6- Cheap low-spec hardware is associated with cheap freely available emulators.

7- Emulation doesn't do CRT approximations very well, you're left with harsh edges and perfect razor-sharp pixels.

8- Tedious controller setup.

9- Because wall of cartridges.

10- FPGA is PARALLEL like the original hardware. Software emulation is old & slow SERIAL operation.

11- FPGA is energy efficient vs a 4GHz processor typically required for software emulation.

12- Software can be abstracted away into a boring black box case. Uninspiring to say the least.

13- Traditional software emulation must co-exist with a host operating system, including all its bugs and problems, lagginess and interruptions, and instabilities.

14- Software emulation is always associated with cheap shitbox AllWinner SoCs, NOACs, and even cheaper products sold at the dollar store.

15- Underpowered R-Pi boards exacerbate slow and bloated emulators. Lacklustre experience.

16- Software emulation is buggy as all hell, and is under constant revision. No one wants the hassle of constant updating and changing user interfaces.

17- Interfacing real controllers has always been an issue, the results are mediocre at best.

18- Software emulation is way too complex, PC, OS, .INI files, Folders, Monitor Resolutions, Sound Settings, Controller Assignments, Setups.. FPGA is simple, Chip + Core = Done!

19- Software emulation is fake, not real. FPGA is real.

20- FPGA achieves higher accuracy and timing when conducting cycle-exact operations. In fact it’s cycle-exact across the entire recreation!

21- Software is not realtime. FPGA is!

 

Regardless of how true or not those statements are it is how the gaming populace at large views emulation.

Edited June 23, 2018 by Keatah

[Flojomojo]

^ "shit my dad says," via Keatah!

Pursuant to #3, what's a folder???

[Jim Pez]

Did you get a chance to try the cassette games ?

[80s_Atari_Guy]

That "Thing" looks a abomination.

 

And how, exactly, is 720p a PRO ? Why in god's name would you want to scale 2600 graphics to 720p ?

[Thomas Jentzsch]

In discussing differences about Paddles vs DrivingControllers, and how they work on a technical level, it is clear there are a lot of misconceptions. And I believe that there are loads of misconceptions and misunderstandings about Software Emulation and FPGA.

 

Without getting into too technical a discussion I'll simply use this as an opener..

 

 

..which leads me into pulling some notes from my w.i.p. book Principia Emulata.

 

I'm not entirely sure why emulation gets the bad rap. Over the years I had lots of theories and taken notes. There is no one solid reason, but many. Here are some reasons that people state.

 

1- FPGA is exact precise hardware replication. Can't beat the authenticity of real hardware.

2- Software emulation is built around the complex and buggy PC ecosphere.

3- It's no trivial task to install, set-up, and assign folders, In fact, most users today do not know what a folder is.

4- One single dropped frame out of thousands upon thousands unleashes the wrath of a vocal minority. Imperfection!

5- FPGA plays real carts. Emulation plays but a copy.

6- Cheap low-spec hardware is associated with cheap freely available emulators.

7- Emulation doesn't do CRT approximations very well, you're left with harsh edges and perfect razor-sharp pixels.

8- Tedious controller setup.

9- Because wall of cartridges.

10- FPGA is PARALLEL like the original hardware. Software emulation is old & slow SERIAL operation.

11- FPGA is energy efficient vs a 4GHz processor typically required for software emulation.

12- Software can be abstracted away into a boring black box case. Uninspiring to say the least.

13- Traditional software emulation must co-exist with a host operating system, including all its bugs and problems, lagginess and interruptions, and instabilities.

14- Software emulation is always associated with cheap shitbox AllWinner SoCs, NOACs, and even cheaper products sold at the dollar store.

15- Underpowered R-Pi boards exacerbate slow and bloated emulators. Lacklustre experience.

16- Software emulation is buggy as all hell, and is under constant revision. No one wants the hassle of constant updating and changing user interfaces.

17- Interfacing real controllers has always been an issue, the results are mediocre at best.

18- Software emulation is way too complex, PC, OS, .INI files, Folders, Monitor Resolutions, Sound Settings, Controller Assignments, Setups.. FPGA is simple, Chip + Core = Done!

19- Software emulation is fake, not real. FPGA is real.

20- FPGA achieves higher accuracy and timing when conducting cycle-exact operations. In fact it’s cycle-exact across the entire recreation!

21- Software is not realtime. FPGA is!

 

Regardless of how true or not those statements are it is how the gaming populace at large views emulation.

Sorry, but that list is rubbish. The bullshit starts with point 1 and ends with point 21.

 

And if you read between the lines, its obvious that the list is not meant to be serious.

[Metal Jesus]

Did you get a chance to try the cassette games ?

 

 

The Supercharger just blinked the screen and never brought up the menu to hit play...

[SS]

 

 

The Supercharger just blinked the screen and never brought up the menu to hit play...

Have you tried the Supercharger games on the SD card as BIN files?

[Shawn]

Any input lag you see in an emulator (in general, and Stella in particular) is probably because the input is (a) coming from a USB device and (b) is only being inspected once per frame.

 

The host OS will package the input into a USB packet, and Stella (actually, SDL behind the scenes) will poll for events on each frame. If the OS is slow in packaging the input, it can be noticeable. And if Stella polls for the input during a frame after the ROM inspects the virtual 'pins' inside the console, it won't see it until the next frame, and again it can be noticeable.

 

None of this is insurmountable. The best way to do it would be for the emulator to have a direct connection to the input port, and when the ROM reads from (for example) SWCHA, it polls the port directly. Just like a real console would. Right now, most emulators work at a higher level of abstraction: host OS -> USB packet -> emulator receiving an event. The zero-lag option would change this to: emulator poll when necessary; no event is generated, but the input is read as it is needed.

 

EDIT: I point this out yet again to the "emulators are crap, FPGA is God" people. There is nothing that an FPGA can do that an emulator cannot, given sufficient hardware.

 

Which is why I'm still confused why they didn't just hire you to make sure stella ran perfectly on this machine in the first place.

[Keatah]

Have you tried the Supercharger games on the SD card as BIN files?

 

Those should work. Stella Emulator has supported Supercharger games for a long time running.

 

I suspect they are using version 4.x, and thus "PC roms" from there will work on R77. Eventually Stella 5.2 and later will make its way to R77 and I would expect near perfect compatibility across the board with anything you put on the SD card.

 

I expect that cartridge limitations like no Supercharger, ARM, Melody/Harmony, extra RAM, DPC+, and all that. None of that will ever work because of hardware limitations on the SoC board they use. But with roms its clear sailing.

 

Since Hyperkin isn't talking, someone should tear one down or at least take a peek to find out what's inside.

Edited June 23, 2018 by Keatah

[Keatah]

IDK.. I think the R77 is neat in that it lets cartridge lovers love their cartridges. And it's stand-alone console to boot.

 

Personally I think (but many disagree with me) the premier Stella experience is to be had on the PC or other full-fledged computer. You have access to all the menu options that bring seemingly endless niceties to the table. IMHO, it's good enough to be considered a gold-standard console itself - what with the recent push for accuracy and compatibility. It just so happens it's a virtual console and not a physical one. That one itty-bitty difference, virtual vs real, is a real panty buncher for some.

[mr_me]

I think sofware emulation is awesone and I expect it to always be a valuable option for high accuracy emulation with plenty of advantages. But isn't it fair to say that if your going to go with a cartridge slot today, fpga emulation is a better choice.

[SS]

Personally I think (but many disagree with me) the premier Stella experience is to be had on the PC or other full-fledged computer. You have access to all the menu options that bring seemingly endless niceties to the table. IMHO, it's good enough to be considered a gold-standard console itself - what with the recent push for accuracy and compatibility. It just so happens it's a virtual console and not a physical one.

 

I am inclined to agree. I have my A/V modded 7800 hooked up full time with virtually all of the 2600 library on flash cart yet, when I want to play a 2600 game, my go-to is the STELLA emulator on my PC using a 2600-daptor with a real CX40.

[Keatah]

I think sofware emulation is awesone and I expect it to always be a valuable option for high accuracy emulation with plenty of advantages. But isn't it fair to say that if your going to go with a cartridge slot today, fpga emulation is a better choice.

 

Well, yes, you WANT to use compatible paints and canvases when creating your work. And if you're working with cartridges in the physical realm, you want to work with hardware that can properly access them. That would be FPGA - in the physical realm

 

Software Emulation presents itself as an entirely different beast when discussing in this context. One of Software Emulation's purposes is to recreate the gaming experience on the PC, and virtually, and as a "hey look at me I'm running arcade Gyruss!" sort of thing. And SE currently works best with cartridges put into binaries/roms.

 

The way Stella is architected now it is DESIGNED from the ground up to use binaries. And that is perfectly fine. And that is its purpose. I'm not a pro-level developer, but I see no reason why it couldn't be re-written to poll a cartridge bus and work from there. But it IS NOT intended to operate that way. And that is an important takeaway point.

 

In R77, Stella is still operating internally the same way as Mr. Mott designed it - to read binary images off of a disk.

 

I sometimes think R77 is like using several pickup trucks to haul a full-size trailer. When instead you should be using a proper Kenworth tractor. All are nice vehicles, but manufactured for different purposes.

[Flojomojo]

IDK.. I think the R77 is neat in that it lets cartridge lovers love their cartridges. And it's stand-alone console to boot.

 

Personally I think (but many disagree with me) the premier Stella experience is to be had on the PC or other full-fledged computer. You have access to all the menu options that bring seemingly endless niceties to the table. IMHO, it's good enough to be considered a gold-standard console itself - what with the recent push for accuracy and compatibility. It just so happens it's a virtual console and not a physical one. That one itty-bitty difference, virtual vs real, is a real panty buncher for some.

I'm with you for emulation, but there's a lot of charm in having it in a cheap, toy-like dedicated device. This is a nice middle ground.

[Andromeda Stardust]

Also... I didn't include it in the video, but the Atari driving controllers didn't work with Night Driver (button worked, but steering didn't) and the SuperCharger just blinked and didn't work either.

 

The driving controllers don't work with Night Driver anyway. That game uses paddle controllers.

 

Wait...what?! LOL

Driving controllers were officially supported by one game (well two counting label variations): Race (Sears label) / Indy 500 (Atari label).

 

Pop in Indy 500 and retest please...

 

 

*tears off a corner of your geek card*

 

Only Indy 500 from the original games uses the Driving controllers. There are a few home-brews that do as well?

Even my real car, which has a steering wheel, doesn't spin all the way around. It works like a paddle!

Ditto.

[Andromeda Stardust]

Looks aside, paddles and the driving controllers are completely different internally. They don't even use the same pins for the most part.

Correct.

 

Paddles: Pins 3,4,5,7,8, and 9 connected.

Driving controller: Pins 1,2,6, and 8 connected.

 

The only common pin shared between both controller types is Ground (pin 8 ).

[Andromeda Stardust]

 

Do both. Have a list of everything, and then your killer no-filler list.

 

As far as 18 goes? It's probably some arbitrary low random number, inspired by legalities. Perhaps guided by the UI. There is no technical practical limitation of how many roms stella can access.

18 makes sense with the UI. They got 3 rows of 6 games each. They could have added multiple pages though and just let people with thousands of ROMs scroll endlessly through page after page until the cows came home. That alone would give gamers motivation to prune down their ROM directory Flipping through 50+ pages of janky ROMs would naturally be a pain in the ass. 18 as it stands seems smallish. As it stands, it's like not being able to scroll through multiple pages in the harmony menu.

 

What 18 games will I add?

 

Pitfall II, Space Rocks, and Scramble are a given. Draconian and Super Cobra Arcade I'll toss in anyway, though those games will require an update of the Stella core before they can be made to work. From there it gets more obscure. Definitely I'll throw in the GB_Chetiry ROM (public prototype version of Chetiry, a Tetris clone). Also I'll add Pacman 8k, VCS Donkey Kong, and DK Arcade, which are still in development. I'll probably throw in a test cart ROM to debug the controller ports and test with my custom joystick (built in paddles). Seems like feeding the paddle pins high logic will change the way the console interprets the controller ports. Defintely Princess Rescue and Zippy the Porcupine, as I have my doubts that Zippy will read correctly.

[Andromeda Stardust]

EDIT: I point this out yet again to the "emulators are crap, FPGA is God" people. There is nothing that an FPGA can do that an emulator cannot, given sufficient hardware.

Realtime polling of controller / cartridge ports? Name one emulator that does this. Please note that I have no qualms against emulation. I will say that emulators can be an incredible tool, but please do not make up blanket statements that cannot be backed up by real world examples.

 

If you can list one example of an emulator running on a modern cpu (ie not backwards compatible consoles, etc) that can directly interface a cartridge bus in realtime with 100% cycle accurate outputs, I will retract my statement. Currently only FPGAs are capable of doing this.

 

I would like to add that there are pros and cons to both setups. Just like realtime bus interface by an emulator would be exceedingly difficult, pausing and resuming gameplay from a state machine is exceedingly difficult to do on a cycle accurate FPGA, but extremely easy through emulation.

 

There are two sides to every coin, and each simulation technique has it's fans. But fpgas can better recreate the user experience of an authentic console, whereas emulators can better create a user friendly environment, ie save states making tough games more approachable for mass audiences, as well as being able to save progress at any time.

[Andromeda Stardust]

That "Thing" looks a abomination.

 

And how, exactly, is 720p a PRO ? Why in god's name would you want to scale 2600 graphics to 720p ?

Because 720p is an exact multiple of 240p, which all vintage game consoles output. Please explain how to evenly divide whole number multiples of 240p into 1080p, and I'll concede that 1080p is better. Until then, 720p is the superior format for multiplying scanlines, bar none. With the advent of 4k HDTVs, 720p makes even more sense, since both 1080p (2x) and 720p (3x) scale integer multiples to 2160p 4k native displays.

 

Achievement unlocked: Post 5 consecutive posts in a single thread...

[+stephena]

Realtime polling of controller / cartridge ports? Name one emulator that does this. Please note that I have no qualms against emulation. I will say that emulators can be an incredible tool, but please do not make up blanket statements that cannot be backed up by real world examples.

 

Not a blanket statement, but a statement of what can be achieved if one wants to do it. First of all, I was speaking of directly reading the controller port; reading the cartridge bus is another story entirely.

 

As for an emulator that currently does it, no one does AFAIK. This is because emulators are mostly designed to be cross-platform, and run at a higher abstraction level. What I'm saying is that there's nothing stopping someone from taking Stella (or any other emulator) and hard-coding it to the specific platform it's running on, and give it direct access to the controller hardware.

 

Stella doesn't currently do it because it uses SDL, and SDL abstracts away all those details. But it could, given the motivation of someone to actually do it. It is technically possible is what I'm saying. You'd simply have to open the device somehow (however the OS allows to do it, probably through a type of serial port mode) and bit-bang it.

[mr_me]

In the old days emulators used parallel ports to communicate with old controllers.

 

With the raspberry pi you could connect directly to controllers through gpio.

[SIO2]

I am not really a fan of emulation outside of testing purposes during development of new games. Emulation however is gaining ground. These days, I really can only gripe about 8, 17 and 18 on Keatah's list.

 

So, if the Retron 77 drops out of the box ready to play and I can pick from most of my Atari compatible controllers to play with - good enough.

 

I still would like to purchase an FPGA Atari 7800 some day though. If the price is ever right. Just because I think programmable hardware is a cool concept.

Edited June 24, 2018 by SIO2

[+remowilliams]

Sorry, but that list is rubbish. The bullshit starts with point 1 and ends with point 21.

 

And if you read between the lines, its obvious that the list is not meant to be serious.

 

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'

[SIO2]

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!