RetroN 77

[Andromeda Stardust]

Well, 1.2 added among other things undocumented ("illegal") opcodes and Pitfall II support. And the executable doesn't run on my system anyway.

Was it 32-bit or 16-bit? You need 32-bit executables to run on any version of 64-bit Windows. If it gives you a message like "this executable is not designed to run on this version of windows" then 9 times out of 10 you are attempting to run 16-bit software. You could also try a virtual Machine with Windows XP, but games are generally a poor choice in VMs as you have absolutely zero hardware acceleration.

 

EDIT: Version 1.1 didn't support illegal opcodes, so Thomas is right that this will rule out many newer homebrews. And while I have access to the 1.1 source, I'm not sure I have permission to release it, and it almost definitely won't compile anyway (and there was only a DOS version, I believe). That's what makes me think that if Hyperkin has a version of Stella running on newer hardware, it very likely must be a GPL'ed version.

If it's DOS based, it absolutely will not run on modern Windows platform beyond WinXP. You could always try it in DOSBOX though...

[alex_79]

You can get the oldest version from https://github.com/stella-emu/stella/releases?after=release-2.0, but I don't know if it will run in current Windows; it almost certainly won't run in Linux, and the Mac version is pre-OSX (this is 17 years ago, after all).

You can run the old dos and windows versions in DOSBOX and wine.

 

I tested StellaX 1.1.3a (from this page), stella 1.2.1 (dos version and "cyberstella") and StellaX 1.4. They all seem to run on my system.

Edited June 17, 2017 by alex_79

[Keatah]

Oddly enough, the page now loads through my ISP (ATT UVERSE) just fine but the IS IT DOWN site still showing down for everyone. Strange.

 

Local DNS issues I'm sure..

 

Maybe isitdown is down. Ask them!

Edited June 17, 2017 by Keatah

[maiki]

Cartridges upside down? I know the 2600 label design has been wrong from the '77 but they could have tried something more acceptable than upside down look. Anyway, if it is FPGA I am not interested. No matter whether it is emulation, simulation, configuration, whatever, the thing is: you can always easily rewrite the whole chip to a completely different system - so it has nothing to do with the real hardware, with the real mark. If they want to impress me, they need to come up with custom SoC solution manufactured by an electronic company for them.

 

If for whatever reason I need anything else than real Atari on real CRT, I can always easily hookup my laptop and fire up Stella - for no cost - with much better results. And with money left to spend for some real 2600 hardware stuff.

[Thomas Jentzsch]

You can run the old dos and windows versions in DOSBOX and wine.

That works for me too.

 

And of course all critical ROMs I tested failed.

[Keatah]

Was it 32-bit or 16-bit? You need 32-bit executables to run on any version of 64-bit Windows. If it gives you a message like "this executable is not designed to run on this version of windows" then 9 times out of 10 you are attempting to run 16-bit software. You could also try a virtual Machine with Windows XP, but games are generally a poor choice in VMs as you have absolutely zero hardware acceleration.

 

If it's DOS based, it absolutely will not run on modern Windows platform beyond WinXP. You could always try it in DOSBOX though...

 

I don't think having a lot of layers and an emulator within an emulator is the best solution. It could work, but, kludge..!

 

I can't imagine Hyperkin significantly re-writing old code either. Why bother? There are simply too many improvements in Stella not to use the latest version. These improvements IMHO are a necessity. They are the result of many years of work, both on the part of the developers doing whatever it is they do and of the community through suggestions and bug-reports and testing.

 

And I think people will notice. My wife certainly did not long ago when she noted that VCS-on-the-PC was beginning to take shape, beginning to define itself. That there felt like internal (barely user noticeable) upgrades going on and outright external usability and interface changes happening. Believe me! That's high praise indeed. And only given to 4 other emulators.

 

Have it be known we don't downplay or bastard-gas the early first versions and alpha/beta versions. For those were the start of what we have today. Believe it or not Mr. Mott started a lot of modern "Atari" things in motion. Consider the chain of events chronicled here at AA, without the first versions of Stella we may not have things like StarCastle, or CDF buss-a-stuffing, or LadyBug, Juno First, and god only knows how much other goodness.

 

Every timeline detailing the success of something will have a few inflection points which went critical. And I believe Emulator Stella was an influence there. It helped developers by being a valuable tool for game creation and testing. Especially testing.

 

But since this is a thread about RetroN 77 I'll stop here. The buffet will remain open for those who wish to feast on more knowledge.

Edited June 17, 2017 by Keatah

[+SpiceWare]

...without the first versions of Stella we may not have ... CDF buss-a-stuffing

 

 

No bus stuffing in CDF.

 

Stella is how I got back into the Atari. I ended up getting a light sixer to help with my port of Stella to OS/2. At the same time I was introduced to homebrews with Okie Dokie and Oystron.

[Keatah]

No bus stuffing in CDF.

 

Yes of course. I re-checked just to be sure and you're right..

[AndrewHyperkin]

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!

[Thomas Jentzsch]

Thanks for the update.

 

Using an age-old core and trying to update it yourself, seems like a huge waste of resources to me. And the result is more than questionable. And at least for me, if there would be no way to update to an new Stella version, this would kill my interest instantly.

 

IMO you should get in touch with Stephen immediately.

[Schizophretard]

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.

 

Yes, with its license you can deploy any build of Stella you want. As long as you share the source code that includes your modifications and give your version the exact same license as the original. In other words, you can't change it from free and open source software into non-free proprietary software because you have to pass along the same freedoms you gained to others. Some open source licenses are that permissible. The GPLv2 is not.

[DirtyHairy]

Andrew,

 

thanks alot for reaching out and for honoring Stella's current license; that's the honest and proper thing that, sadly, many companies don't do when using OS in their products. However, I'd like to second Thomas, the work that needs to be invested in getting this ancient core even close to the compatibility provided by Stella 5 must be considerable --- a full rewrite would likely be easier Getting a current version of Stella to run legally on the device would be a huge gain for everyone.

 

Providing the means to run a current version of Stella without distributing it would be compliant with the GPL. However, depending on how you implement access to physical cartridges, I guess there is a patchset to Stella involved --- that would have to be GPL, too. I think it would make sense to try and get support for this merged into Stella directly. Then again, if you go so far, opening enough of the fírmware to distribute the GPLed version of Stella is within reach, too.

 

If you want to license Stella under terms that are not compatible with the GPL, be aware that negotiating with Stephen won't be enough, but you'll also have to track down everyone whose contribtutions are part of the current codebase and get their consent, too (or remove those parts from your build).

 

I guess that, if you are actively exploring options to using the GPLed codebase, I may be preaching to the choir here so, in this case, sorry for that

Edited June 18, 2017 by DirtyHairy

[AtariLeaf]

Can someone explain in laymans terms why Hyperkin seems unwilling or unable to use the latest version of Stella? If it's simply a matter of releasing "source code" for open source software I'm not seeing the problem here and why they refuse. Is it money? Do they have to pay for this license? If so how much time and money is being spent re-engineering something that is already working.

[DirtyHairy]

 

Stella is how I got back into the Atari. I ended up getting a light sixer to help with my port of Stella to OS/2. At the same time I was introduced to homebrews with Okie Dokie and Oystron.

 

Funny, I haven't been here even remotely as long as you, but that's about the same story with me: I got myself a Jr. (that what I had as a kid, so there is some nostalgia associated with it) when I started porting the 6502.ts core to Stella and getting serious about stomping the remaining discrepancies to hardware. At this point, I guess I have gotten myself a new hobby and even find myself toying around with ideas for homebrew development (but currently lack time to attempt those seriously)

Edited June 18, 2017 by DirtyHairy

[DirtyHairy]

Do they have to pay for this license? If so how much time and money is being spent re-engineering something that is already working.

 

No, they don't, they just have to comply with the GPL by opening up the relevant parts of their software under the GPL, too. However, depending on how they are integrating Stella, they may be aftraid of revealing parts of their own (or someone elses) intellectual property and any losing a competitive advantage or even violating other licenses by doing this. Consider for example the possibility that integrating Stella with their cartridge reader involves including headers from and linking to other parts of their stack that are licensed from a third party under a NDA (non disclosure agreement). Then you essentially have a deadlock because opening up the emulation core will imply opening up those bits, too, and that would violate the NDA.

 

However, I am curious about the same same thing, too

Edited June 18, 2017 by DirtyHairy

[+stephena]

I will be speaking to them soon, but DirtyHairy is right. It's not so much a negotiation on my part as a statement of fact, because I personally can't negotiate; I don't own all the changes to the latest Stella, nor do I want to track everyone down. DirtyHairy is a large contributor with basically the entire TIA core in version 5, but most of the GUI code came from ScummVM, large parts of the debugger from Brian Watson, many bankswitch schemes from Eckhard Stolberg, and then minor patches here and there from a multitude of people.

[Andromeda Stardust]

Man, the legal quagmire with this. If Space Rocks and other homebrew like it don't run on this thing, it's essentially a no buy for me.

 

Draconian is coming out soon, which runs on stock Melody hardware like the others, but employs new CDF methods which require a bleeding edge build of Stella to run.

 

This is why hardware based solutions would be preferable over software. A 1:1 hardware clone will always 100% compatible, but software will require endless refinements as more exploits are discovered to push hardware.

 

If Stella 5 could be ported over to Retron77, that would be great, so I hope Hyperkin will consider open-sourcing the project and any firmware updates. Of course that would leave competitors open to cloning the hardware. At least the Chinese copycats seem to have little interest in Atari because that system is dead to the home market.

 

I wish you guys well and thank you for sharing these developments.

[Atari Dogs]

Is there a pause button? At $40 it is cheaper than the retail of the Flashback models which is $49.99.

[+stephena]

Man, the legal quagmire with this. If Space Rocks and other homebrew like it don't run on this thing, it's essentially a no buy for me.

 

This is why hardware based solutions would be preferable over software. A 1:1 hardware clone will always 100% compatible, but software will require endless refinements as more exploits are discovered to push hardware.

 

The legalities can be worked through; nothing is set in stone yet.

 

As for hardware vs. software, this is an age-old argument and there are pros and cons for each. It's true that a 100% hardware solution would be better, but who is to say that a hardware solution would be 100%? There are always new things being found that invalidate older assumptions. And for most new hardware, this means implementing an FPGA or something, which is still software (or at least the description of the circuits are). So that leaves the possibility of having to update the FPGA, which means access by the end user. But if you already have that access, then using a software-based solution is now on the table as well

 

Basically, the only 100% hardware solution is original hardware. So on any new system, there's always the chance of incompatibility. I would take software over hardware in such a case, since it can be updated much easier and more quickly.

[Albert]

Basically, the only 100% hardware solution is original hardware. So on any new system, there's always the chance of incompatibility. I would take software over hardware in such a case, since it can be updated much easier and more quickly.

 

Even 100% hardware is not 100% compatible with all games. The Heavy/Light Sixers, 2600 Jr. and 7800 all have compatibility issues with some games (even some first-party Atari games). The Taiwan six-switch systems seem to be the most reliable in terms of compatibility with everything.

 

..Al

[Keatah]

Man, the legal quagmire with this. If Space Rocks and other homebrew like it don't run on this thing, it's essentially a no buy for me.

 

That's ok. If I was involved in this I wouldn't mind putting the shitkickers on and wading through it.

 

I don't know all the details, but if they have some sort of cartridge reader software under NDA or something, they may have to write a go-between. An intermediate bit of code that acts as an interface.

 

Not unlike a microprocessor-controlled gamepad. The gamepad remains secret and separate. Stella (and its license) just talk to it. Not have anything to do with it. The cartridge reader would be just another plug-in device. A module that presents data to Stella. In fact. I could see Stella having something like that as a command-line option.

 

 

 

Draconian is coming out soon, which runs on stock Melody hardware like the others, but employs new CDF methods which require a bleeding edge build of Stella to run.

This is why hardware based solutions would be preferable over software. A 1:1 hardware clone will always 100% compatible, but software will require endless refinements as more exploits are discovered to push hardware.

 

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.

 

One way or another, new bank logic typically means some development work is done for the cartridge’s PCB.. And if you have an emulator, in its logic. So it's understandable a new version is required. We are now emulating a tiny bit of new hardware!

 

It’s only fair if you upgrade the hardware that you upgrade the emulation software. Right?

 

I wonder how an FPGA rig might handle bus-stuffing? A rhetorical question because I don't think it would. The FPGA would be able to respond to data coming in on the address and data lines, but not necessarily allow itself (and the stuff inside) to be bullied around, like in BUS. There'd be electrical compatibility issues. Would it respond precisely as the VCS' chipset? Doubt it. Not off the bat. It would have to modeled and simulated. At the very least you’d need to make updates.

 

BUS is like overclocking, overdriving. BUS is new hardware not part of the VCS + cartridge gig of the 1970's. Standard masked ROMS don't stuff anything. BUS is a new active chip (the ARM in Harmony/Melody) that introduces an unknown analog quantity into a digital world.

 

Mass-produced console hardware that has undergone several revisions can be pushed and prodded only so much before it all breaks down except for 1 revision, 1 production run. The situation arises because with BUS some things are operated out of specification, and a few lucky variations, a few chance combination of parts, happen to come together to give you a unit that works in extreme conditions. Or the opposite happens. Everything works EXCEPT a couple troublemaker revisions/units.

 

How many revs of TIA are there? How many revs of the VCS itself? Each one subtly different than the next.

 

Even a 1:1 hardware clone fabricated on a transistor level would still have issues. Think. You would need to have the same chemistry in the MOS or nMOS fab process (whatever they used in 1977). The silicon would need to be doped the same way. Not to mention making all the transistor's wiring the same length and their geometry the same size. The resistance and beta-curves gotta be identical. If you don't do all that your hardware is going to behave differently when in a corner case, like with BUS.

 

It isn't enough to duplicate what happens on the pins. But how it happens and the electrical characteristics surrounding it. Both inside and outside of the chip. A 1:1 clone would need a lot more engineering than just getting the logic right.

 

I bet you each revision or individual machine that failed testing with BUS could be modified to pass. Extra resistors, extra drivers. Extra parts to make the electrical characteristics more consistent from one machine to the next. And then there’s thermal control to consider. How about internally produced noise and interference? How about shortened life?

 

The developer must find a happy medium in all this. And here it looks like stability, reliability, and consistency won out. By staying within the digital domain many analog factors are simply not important, like heat dissipation, current loading and sinking, things like that.

 

BUS was interesting. But I have higher hopes on CDF and its revisions.

 

All this is why software emulation is so cool. It puts a stop to analog variations. You get one platform that is consistent. Yet you can create the world's rules as you see fit. And those rules will remain identical whether it be one installation of Stella running or 20,000 installations of Stella running.

 

So.. Architecting Stella's internal code is much easier than building a fab to recreate a 1:1 chipset trio whose characteristics match those of parts made in the 1970's. There's always going to be some corner cases with real-life hardware that ain't cut'n the mustard.

 

---

 

This is no different in aerospace, where you have a coffin corner. A jet is flying high, where the air is thin. If it goes 5 knots too slow, the plane stalls and falls out of the sky. If it goes 5 knots too fast, you have supersonic airflow where do you don't want it and the plane goes out of control. All sorts of funkiness happens like control inversion or boundary layer breakage.

[AtariLeaf]

 

Draconian is coming out soon

 

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

[atarifan88]

As a potential customer of the Retron 77, I would prefer Hyperkin ship their product with the latest version of Stella even if it meant not making the deadline for this Christmas. That way there would be more games compatible as well as some great homebrews! Is anyone else on here in agreement with me or am I talking nonsense?

Edited June 18, 2017 by atarifan88

[Keatah]

What kind of hardware is in this console? Will it be powerful enough to handle the latest version of Stella?

[Thomas Jentzsch]

What kind of hardware is in this console? Will it be powerful enough to handle the latest version of Stella?

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)

Edited June 18, 2017 by Thomas Jentzsch