RetroN 77

[Shawn]

Best part I've read from Andrew of Hyperkin so far is that the 7800 is being worked on. That would be epic if a future version was 2600 & 7800 compatible.

Edited June 18, 2017 by Shawn

[+stephena]

I would hope so, the new core requires up twice as much CPU power as the old one.*

 

*I only tested with The Official Frogger and Pitfall II, where the maximum CPU usage went from ~3% (4.7.3) up to almost 6% for 5.0pre9. (Intel i5-3570K)

 

There are ways of reducing that for a specific port (vs. the general-purpose builds that are released for general public). Also, Pitfall II is known to take more emulation resources than the average ROM.

[Thomas Jentzsch]

Also, Pitfall II is known to take more emulation resources than the average ROM.

Sure, that's why I used it for testing.

[Andromeda Stardust]

 

And it’s cool that it can be updated. Each new bankswitch scheme is like a new eco-system. There's work that goes into the cartridge side of things too. There may be a discrete 74LS or small GLA to implement the new bankswitch logic. Maybe extra RAM, or sound chips.. Maybe something as simple as a different wiring configuration of the traces. So essentially you have new/different/additional hardware and Stella needs be aware of that new hardware. If not in ROM headers and mappers, then in the emulator itself.

I won't quote your entire text wall but I do agree with it mostly. Bus Stuffing was never intended by the developers nor is it an intended usage of any type of chip logic. Most chips are engineered with redundancy and operate at low enough power levels that bus conflicts or dueling signals will not cause damage, though such usage is considered to be "out of spec" so the actual chip behavior in such situations where it is operated outside of defined parameters is not guaranteed. So while bus stuffing is cool, there is no guarantee that it will work or that long term usage of techniques will not shorten hardware life.

 

Back to the portion of the text I quoted. The "CDF" technique used by Draconian is not a new bankswitch scheme but merely an extension of current Melody bankswitch firmware. So Stella has been emulating Melody for some time now, and Draconian works just fine even on pre-Encore revisions of the Harmony cart. So no new bankswitch scheme has been discovered, only that "bus stuffing", CDF, and other exploits now exist to further utilize existing melody hardware in ways that it has not been utilized before. So one could argue that if CDF is not a new bankswitch scheme but merely an extension of Melody, than the current implementation of Melody bankswitch hardware in Stella is incomplete.

 

The important takeaway from all this is while nothing has been added to Melody to support CDF, the emulator must be updated to add these new extensions. So Melody emulation is largely incomplete, and as time goes on, more exploits will be discovered for the Melody + VCS system, and the emulator will have to be updated again despite the fact the real life hardware has not changed. Stella's incomplete emulation of Melody + VCS runs Space Rocks but is inadequate to run Draconian so it must be updated.

 

No updates are required for the Melody boards, but suppose part suppliers discontinue certain components. Perhaps the 70Mhz ARM inside the Melody is discontinued, so a newer revision ARM chip must be substituted, then forced into compatibility mode and underclocked to 70Mhz. Since the newer revision ARM chip has additional extensions to the instruction set, it may be possible to program new games that use the new extensions that won't work on the older Melody boards. A bigger issue, suppose an existing game uses invalid opcodes in ARM assembly, and on newer revision boards with newer revision ARM chips, these invalid opcodes no longer operate in the same manner. Or suppose the precise amount of cycles required for specific instructions has changed.

 

BOOM! Required revisions to the Melody hardware in the future as manufacturers discontinue or update their product lines may break compatibility with existing games. These games may get discontinued or broken as fabrication technology for required parts are withdrawn from manufacture. Little different from the fact it is now very difficult to procure 5V microcontrollers aside from basic 74XX series type discrete logic, so interfacing with flash carts and other homebrew hardware requires level shifters which complicates the hardware side of things. 5V chips and 3.3V chips have to communicate reliably, very difficult to do if a bidirectional bus is required.

[Keatah]

Maybe the Melody portion of Stella needs to become more modular and more complete. Or outright emulated instead of just simulating the instruction set with no regard to accurate timing.

http://thumbulator.blogspot.ca/

 

Otherwise the only solution is going to be a new version of the emulator every time something new is uncovered.

[Andromeda Stardust]

 

Best news I've heard in a week. In Spiceware we trust!

Don't quote me on this; Spiceware said he was aiming for a PRGE release this fall, but there's no guarantee it will be ready in 2017.

[AAA177]

 

Are you talking about this? http://atariage.com/forums/topic/266480-new-atari-console-that-ataribox/?st=0

 

Easy to find by hitting View New Content.

 

That was it, thank you for the link, and the advice!

[AtariLeaf]

Don't quote me on this

 

Too late

[Thomas Jentzsch]

A bigger issue, suppose an existing game uses invalid opcodes in ARM assembly, and on newer revision boards with newer revision ARM chips, these invalid opcodes no longer operate in the same manner. Or suppose the precise amount of cycles required for specific instructions has changed.

I agree with your points regarding the availability of the chip. But I am pretty sure Fred will find an alternative.

 

Regarding the "illegal" opcodes, I don't think we have to worry much there. AFAIK all ARM-based games are 99% written in C++ anyway. And I am not aware of the existence of undocumented opcodes for the ARM.

[Schizophretard]

I want to thank everyone for their input and warm welcome. Your opinions are truly important, both personally for me and for our company.

 

We licensed an early version of Stella, and being fully aware of its certain technological issues, our software developers continue working hard to implement the promised features. We at Hyperkin fully understand that all the newer versions are subject to different license terms, and therefore plan to ship the product with our own build. Stefan, please contact us at developer@hyperkin.com, hopefully we can negotiate the opportunity to use your newer builds, for the sake of making the product better.

 

What we initially plan to offer is basically a convenient piece of hardware, with a properly configured and licensed Stella (early version). It will not include any other proprietary parts of Stella code from further revisions (unless we negotiate that with Stefan). That build is expected to have the full set of features I listed in my previous post, and hopefully some more.

 

As an additional tinker-friendly feature, we expect to leave an opportunity (for example in a form of a service port) to install other versions of Stella -- we honor everyone's IP rights, but since it's open-source, I believe users are free to rebuild and deploy any build of Stella they want.

 

Also, many of you requested 7800 compatibility. I cannot really promise that at the moment, but we are working on it.

 

Thanks again for your support!

I think this using your developers for adding features for an earlier version of Stella instead of using the modern open source one is a bad idea. Atari VCS gamers are a very niche market and since your device seems to be aimed at those that prefer original hardware on one end by using original carts and emulation on the other end then this other end should be the most respected modern version of Stella. If your reasons for wanting it to be somehow proprietary out of fears of it being cloned or something like that then I think you are missing the full picture of how Atari VCS gamers think. We prefer and support what appears to be the official version of something and don't prefer or support what appears to be a knock off. For an example, if someone makes a knock off of a homebrew game then that person is more likely to get looked down on than bought from because people want to support the creator of the homebrew. So, if you go about it right then, like homebrewers, you would be the preference being supported even if someone created an exact clone. On the other hand, if you don't use what is viewed as the definitive version of Stella but instead use an older but modified proprietary version then your version would look more like the knock off.

 

I don't think you should have the mindset of,"How do we go about creating an HD Atari VCS?" but instead something more like,"How do we go about showing off the quality of Stella by building an HD Atari VCS around it that is implemented so well that people can almost forget that it is running on Stella?" Answering that question is what will appeal to the target audience because those who already love Stella would have a physical manifestation of it in console form to show off its quality and those who love original hardware will be impressed that it doesn't feel like they are playing on an emulator but on a console.

 

I think it would also be real appealing to homebrew developers because they try to make their games run on both Stella and original hardware and would find it less appealing to do that as well as another version of Stella. In other words, homebrew developers may use it as a devkit and those who buy homebrews may buy it to play them on because they would have identical hardware as the developers.

 

Also, using the most up to date version of Stella would give you an edge over similar products like Flashbacks.

 

If you want to license something proprietary that would make the 77 more appealing than potential knock offs then do something like contact homebrew developers to work out deals to make a 77 multicart as a pack-in instead of working with some gimped version of Stella that the community would have less respect for.

 

 

[atarifan88]

I think this using your developers for adding features for an earlier version of Stella instead of using the modern open source one is a bad idea. Atari VCS gamers are a very niche market and since your device seems to be aimed at those that prefer original hardware on one end by using original carts and emulation on the other end then this other end should be the most respected modern version of Stella. If your reasons for wanting it to be somehow proprietary out of fears of it being cloned or something like that then I think you are missing the full picture of how Atari VCS gamers think. We prefer and support what appears to be the official version of something and don't prefer or support what appears to be a knock off. For an example, if someone makes a knock off of a homebrew game then that person is more likely to get looked down on than bought from because people want to support the creator of the homebrew. So, if you go about it right then, like homebrewers, you would be the preference being supported even if someone created an exact clone. On the other hand, if you don't use what is viewed as the definitive version of Stella but instead use an older but modified proprietary version then your version would look more like the knock off.

 

I don't think you should have the mindset of,"How do we go about creating an HD Atari VCS?" but instead something more like,"How do we go about showing off the quality of Stella by building an HD Atari VCS around it that is implemented so well that people can almost forget that it is running on Stella?" Answering that question is what will appeal to the target audience because those who already love Stella would have a physical manifestation of it in console form to show off its quality and those who love original hardware will be impressed that it doesn't feel like they are playing on an emulator but on a console.

 

I think it would also be real appealing to homebrew developers because they try to make their games run on both Stella and original hardware and would find it less appealing to do that as well as another version of Stella. In other words, homebrew developers may use it as a devkit and those who buy homebrews may buy it to play them on because they would have identical hardware as the developers.

 

Also, using the most up to date version of Stella would give you an edge over similar products like Flashbacks.

 

If you want to license something proprietary that would make the 77 more appealing than potential knock offs then do something like contact homebrew developers to work out deals to make a 77 multicart as a pack-in instead of working with some gimped version of Stella that the community would have less respect for.

 

 

 

What he said!!!

[+SpiceWare]

The "CDF" technique used by Draconian is not a new bankswitch scheme but merely an extension of current Melody bankswitch firmware. So Stella has been emulating Melody for some time now, and Draconian works just fine even on pre-Encore revisions of the Harmony cart. So no new bankswitch scheme has been discovered, only that "bus stuffing", CDF, and other exploits now exist to further utilize existing melody hardware in ways that it has not been utilized before. So one could argue that if CDF is not a new bankswitch scheme but merely an extension of Melody, than the current implementation of Melody bankswitch hardware in Stella is incomplete.

 

 

Stella does not emulate H/M(Harmony/Melody), it emulates cartridge bankswitch schemes (all those files that start with Cart).

 

Likewise H/M emulate bankswitch schemes - these are done by a driver. When H/M loads up Pitfall 2, it also loads the DPC driver. To the 2600, there's no difference between that and a real Pitfall 2 cartridge.

 

We've been designing new bankswitch schemes (DPC+, CTY, BUS, CDF) then writing a new driver to implement it. We also write a new Cartridge Type for Stella, so it can implement it as well.

[AAA177]

Thought came to mind today: Imagine if Netflix promoted Stranger Things with an actual 2600 game/cart, with the box/manual/maybe even a catalog, all printed on old stock (if possible)? Almost seems like something someone here should pitch the company considering the upcoming release of this product. (I think someone did make a game in the style of the 2600, maybe posted online, but I'm talking a proper one.)

[+stephena]

Stella does not emulate H/M(Harmony/Melody), it emulates cartridge bankswitch schemes (all those files that start with Cart).

 

Likewise H/M emulate bankswitch schemes - these are done by a driver. When H/M loads up Pitfall 2, it also loads the DPC driver. To the 2600, there's no difference between that and a real Pitfall 2 cartridge.

 

We've been designing new bankswitch schemes (DPC+, CTY, BUS, CDF) then writing a new driver to implement it. We also write a new Cartridge Type for Stella, so it can implement it as well.

 

Yes, that's what a lot of people don't seem to understand. Every time you update the ARM driver code for a scheme, it is essentially the same as writing a new scheme (or at least significantly changing an existing one). So of course the same thing needs to happen in Stella. The main advantage of the Harmony here is that the driver is pre-pended to the ROM, and immediately works when uploaded, while in Stella the C++ bankswitch code needs to be updated.

 

In the longer term, I wonder how difficult it would be to have Stella read from the ARM driver and implement bankswitching that way, so it would have the same advantage as the Harmony (simply upload the ROM and it 'just works'). Maybe it's not possible at all, since we hook into the bankswitch code for the debugger, etc.

[Keatah]

Love these little tidbit side-discussions of how emulation works.

[toiletunes]

If, for whatever reason, this doesn't work with some games- it's no worse than the Flashback Portable, and we get HDMI plus a cartridge port for maybe $50. I enjoy my Flashback Portable, and I'll enjoy this too.

[Thomas Jentzsch]

If, for whatever reason, this doesn't work with some games- it's no worse than the Flashback Portable, and we get HDMI plus a cartridge port for maybe $50. I enjoy my Flashback Portable, and I'll enjoy this too.

Aim high, shoot low?

[+SpiceWare]

In the longer term, I wonder how difficult it would be to have Stella read from the ARM driver and implement bankswitching that way, so it would have the same advantage as the Harmony (simply upload the ROM and it 'just works'). Maybe it's not possible at all, since we hook into the bankswitch code for the debugger, etc.

 

 

I suspect it'd be way more hassle than its worth considering how infrequently we create new bankswitch schemes. After DPC+, BUS and CDF, I don't foresee myself involved in creating any others (and CDF only came about because of hardware compatibility issues with BUS).

[ClassicGMR]

Probably mentioned somewhere in the 15 pages of this thread but I will be buying one for the modern tv hookups alone IF IF IF the Harmony cart is compatible!

[DirtyHairy]

Yes, that's what a lot of people don't seem to understand. Every time you update the ARM driver code for a scheme, it is essentially the same as writing a new scheme (or at least significantly changing an existing one). So of course the same thing needs to happen in Stella. The main advantage of the Harmony here is that the driver is pre-pended to the ROM, and immediately works when uploaded, while in Stella the C++ bankswitch code needs to be updated.

 

In the longer term, I wonder how difficult it would be to have Stella read from the ARM driver and implement bankswitching that way, so it would have the same advantage as the Harmony (simply upload the ROM and it 'just works'). Maybe it's not possible at all, since we hook into the bankswitch code for the debugger, etc.

 

I have thought about the same thing (triggered by the discussion of the various DPC+ versions). I think it would be possible, but the hassle wouldn't be worth the gain. We'd need a full flegded ARM emulator to start with (the Thumbulator won't do), and every cartridge access would need to go through ARM emulation, so there would be considerable speed penality. Also, we'd lose all banking-specific debugging functionality.

[Andromeda Stardust]

 

 

Stella does not emulate H/M(Harmony/Melody), it emulates cartridge bankswitch schemes (all those files that start with Cart).

 

Likewise H/M emulate bankswitch schemes - these are done by a driver. When H/M loads up Pitfall 2, it also loads the DPC driver. To the 2600, there's no difference between that and a real Pitfall 2 cartridge.

 

We've been designing new bankswitch schemes (DPC+, CTY, BUS, CDF) then writing a new driver to implement it. We also write a new Cartridge Type for Stella, so it can implement it as well.

So basically without having new drivers written into Stella, it cannot emulate new Melody exploits. I think optimally Stella should emulate the entire Melody hardware for those games that require it, to future proof it against future homebrew games, but this may be extremely difficult given the complexity of the 70Mhz ARM chip.

 

While it doesn't concern much for PC users or Harmony cart users, it will affect embedded devices (Raspberry Pi, Wii, Android, et al) running outdated Stella codebase as well as potentially prevent the upcoming Retron77 from running new homebrew. Ironically FPGA consoles such as AVS or NT Mini (and possibly that Walkman Atari thing if it gets released to the public) are for the most part immune to incompatibilities as a result of future homebrew development.

 

But FPGA is a very different beast compared to cart dumper + emulation. Another potential legal hurdle with Retron77 is if they open source the firmware, hackers could use it as a dumping tool and steal both commercial and homebrew ROMs, which Hyperkin would be in their best interest to avoid.

 

Still, Hyperkin could release the official firmware along with the source code and choose not to support or acknowledge custom firmware or hacks while still allowing end users to tinker with the hardware if they so choose. NES Mini, Retron5 were closed off and it didn't stop them getting hacked, so encouraging hacking without officially supporting it may be a wise alternative if it means better game support with official firmware (ie being able to employ later versions of Stella). I'm not even sure if Stella 1.1 / 1.2 even supports Pitfall II, and might be difficult to port over to modern hardware. This was 16-bit DOS era emulation, after all...

 

 

 

I have thought about the same thing (triggered by the discussion of the various DPC+ versions). I think it would be possible, but the hassle wouldn't be worth the gain. We'd need a full flegded ARM emulator to start with (the Thumbulator won't do), and every cartridge access would need to go through ARM emulation, so there would be considerable speed penality. Also, we'd lose all banking-specific debugging functionality.

Yeah it appears the Melody hardware may be more difficult to emulate than thought. Worth noting that Harmony will continue to be compatible with these new games for some time to come...

 

 

 

 

I suspect it'd be way more hassle than its worth considering how infrequently we create new bankswitch schemes. After DPC+, BUS and CDF, I don't foresee myself involved in creating any others (and CDF only came about because of hardware compatibility issues with BUS).

Never say never. The VCS/2600 hardware, and Melody by extension, still likely has a lot of exploits just waiting to be discovered. Someone will come up with something even more mind-blowing that CDF, whether by you or someone else carrying the torch!

[AW127]

Would be nice, when they would give the "Retron 77" a SD-Card slot and the possibility to run roms on it, like the "Atari Flashback Portable" can do it. That would be a good feature additionally to the cartridge-support.

[Thomas Jentzsch]

I think optimally Stella should emulate the entire Melody hardware for those games that require it, to future proof it against future homebrew games, but this may be extremely difficult given the complexity of the 70Mhz ARM chip.

 

And when the specs for Melody change in the future? (Melody 2.0, based on a different chip). Nothing can be 100% future-proof.

[Keatah]

I think Stella should emulate:

 

1- Reading Electronic Games magazine

2- Watching Saturday morning cartoons and videogame advertisements

3- Discussing it with your grade-school buddies

4- Begging mom & dad for a new game

5- Getting in the family car for a trip to the store

6- The smell of the store

6- Looking at the box on the way home

7- Opening the box

8- Plugging in the game

9- Watching the TV go from static snow to the game playfield

 

..in that order for the complete cartridge experience!

Edited June 19, 2017 by Keatah

[Andromeda Stardust]

 

And when the specs for Melody change in the future? (Melody 2.0, based on a different chip). Nothing can be 100% future-proof.

Yeah I covered that in an earlier post. Who knows if the current beta of Draconian will work on whatever the current defacto 2600 flash cart hardware 20 years from now.