Jump to content
IGNORED

ARM based/enhanced Atari development, MISTer FPGA, and preservation


dlmartins

Recommended Posts

15 hours ago, Yurkie said:

Stella emulates Atari 2600 hardware and since we can't update the original hardware, why does Stella require updates?

 

Stella emulates many things:

  • The console
  • The controllers (such as you can play paddle games using your keyboard)
  • The display (position of electron beam, jitter, PAL colour loss)
  • The cartridge

 

As covered in my blog entry extra hardware! many cartridges include additional hardware to allow for ROM that exceeds the Atari's 4K limit, extra RAM, and even coprocessors. Stella needs to emulate the cartridge's hardware to be able to run those games accurately. Stella has been updated over the years as new cartridge hardware is found or created.

 

An example of new hardware that was found, the Pursuit of the Pink Panther prototype (more info here and here) uses unique hardware in the cartridge for 8K ROM (using eight 1K banks) and 64 bytes of extra RAM.

 

196370106_ScreenShot2021-05-27at9_32_30AM.thumb.png.42c6cdd28461bedd962858bf22bf0bb8.png

  • Like 2
Link to comment
Share on other sites

3 hours ago, hizzy said:

Someone attached a card reader to a Mister. That would work with ARM games, no?

Without seeing the project in question, my guess is it's a non-realtime dumper. i.e. it doesn't keep reading the device, but just dumps it once. The de10 nano doesn't have enough free gpios to connect to the cart pins directly.

 

17 hours ago, MrMaddog said:

Forgive me if this sounds naive to experts but doesn't the DC-10 Nano that MISTer runs on have an ARM processor to run the game's ARM based code?

While this sort of hybrid approach has been explored recently, I get the feeling there's some resistance in putting any emulation onto the ARM, or leveraging it any more than it currently is utilised. (see the public arguments against graphical front-ends, or even the ability to launch a core with rom enabled from command-line) 

 

There's also a hurdle in the melody/harmony cart firmware being closed. Even if source was provided openly, the firmware would be twiddling GPIOs for the data and address bus, which isn't how the Mister cores work. Someone would need to implement and maintain a hybrid firmware that did equivalent stuff. Then there's the matter of different ARM memory maps, instructions, and such, which is what threw a big wrench into Unocart support for Melody-arm games. (not sure where that's at right now)

 

IMO Mister FPGA running the melody firmware on the ARM is technically possible, but just very unlikely to happen. It would require someone with access to that firmware source, and an insider knowledge of Melody and MiSTer FPGA development, to also be interested in doing this work. (with the added hurdle that the work may never be part of the main MiSTer distribution)

 

Answers to OP...

 

- Is there a danger for enhanced games, by their nature, to not be preserved or playable?

 

There's no danger in terms of playability, with Stella containing a GPL licensed implementation. One could certainly argue about cycle-accurate preservation here, or hardware-reference preservation, both of which are a big focus of MiSTer. if the principals behind melody have moved on in XX years, will anyone be able to make a melody compatible cart based on publicly documented info? My best guess here is "no".

 

- Is the lack of support in MiSTER and possibly other hardware based approaches for these enhanced games a concern?

 

I doubt those making the enhanced games are concerned with any modern console implementation not running them, so long as the games run on the original hardware.

 

- Is the use of enhanced games lazy and a lazy approach (compared to a Mapper)?

 

I think Kitrinx's choice of calling it "lazy" is unfortunate... the word choice seems to stem from the mistaken idea that an alternate, more period-silicon-correct abstraction could have been made, that could give similar benefits as the ARM enhanced games. That approach was actually tried with DPC+, but the ARM-enhanced game devs found that having the less-abstracted power of a modern cpu (with the 6507 acting as an IO co-processor) to be more alluring than staying period-accurate. It's unsurprising that someone involved in archiving hardware doesn't value, or even intuit, this motivation immediately.


- What are the primary reasons for using ARM based enhancements?

 

To create games that aren't possible on the 2600 otherwise.

 

  • Like 2
  • Confused 1
Link to comment
Share on other sites

Sorry, RevEng, but:  All those questions were pretty much answered.  I feel like your post was composed entirely as a vessel for damage control on your friend's behalf.  The answered questions feel like filler to me; designed to sandwich a carefully worded statement to contain the discussion.  It's wooden and it's calculated.

 

Look, if she thinks the games are shitty, fine.  There's definitely no shortage of shitty games.  I hate Undertale.  (A failure of game design and poor presentation on every level.)  Everyone has an opinion.

 

But, calling Spiceware and Champ Games lazy crosses a line.  It's not really "unfortunate".  It's bullshit.  It's the same thing as MrSQL.  It's not different.  Sorry.

 

She isn't Carol Shaw or Rebecca Heineman.  You have to be a great individual game software developer to start talking shit at other devs.  What has she done?  MiSTer cores aren't video games. 

 

Roger Ebert had quite a prolific career.  Didn't make his dumbass opinion on games okay.  Come to think of it, outside of the lovely technical production values, Citizen Kane is a shit movie, Roger.  It's boring.  If you're going to put that much effort into the raw production (top notch), you need to present a great story.  At its core, the film is empty and boring.  So, maybe he wasn't a great critic after all.  Rise of the Robots had great graphics, but there wasn't a game behind it. 

 

Miyamoto privately seethed that Donkey Kong Country was boring and lazy.  Compared to Yoshi's Island, it is.  Miyamoto can get away with it, because he did something better.  Is DKC really lazy?  No.

 

What is lazy?  I can't think of too many examples of lazy game devs.  Can you?  I think Custer's Revenge qualifies. Jewel swiping clone games on mobile are pretty lazy.  Champ Games and Spiceware?  Not so much. 

 

Even Superman 64 had a team of people working hard behind the scenes; there were a lot of reasons it failed--and it wasn't because nobody cared.  ET is regularly bashed as lazy, but that's a lazy shitty meme; ET sparkles with polish and craftsmanship--despite the polarizing game mechanics.

 

Everyone has worked on a stinker.  Doesn't make us lazy.  Although, I can't think of any substandard shitty Spiceware or Champ Games releases.  There's nobody forcing the game out the door or creating havok with those Atari devs.  There's no clueless boss, politics, or budget hammering the new Atari games into oblivion.

  • Confused 1
Link to comment
Share on other sites

3 hours ago, orange808 said:

Sorry, RevEng, but:  All those questions were pretty much answered.  I feel like your post was composed entirely as a vessel for damage control on your friend's behalf.  The answered questions feel like filler to me; designed to sandwich a carefully worded statement to contain the discussion.  It's wooden and it's calculated.

Nope. I just see someone else's perspective on the matter, and how they might have been led astray, or have a different opinion without the facts. I don't assume bad faith or intent, like you have. For sure "lazy" was insulting, and I didn't defend it.

 

My preference is always debate, discussion, and education, unless someone has historically proven themselves to argue in bad faith. It seems that you don't feel the same, or you've already put me in that latter category. Either way, not much point to further discussion, then.

 

As for questions being "pretty much answered", sorry, but I don't recall OP asking people to stop answering the open questions posed. I do think my replies added to the conversation. Apologies they were too wooden for your taste.

 

 

  • Like 5
Link to comment
Share on other sites

1 hour ago, RevEng said:

While this sort of hybrid approach has been explored recently, I get the feeling there's some resistance in putting any emulation onto the ARM, or leveraging it any more than it currently is utilised.

This is not necessarily true; if you check the link in the first post of the thread you referenced, you'll find it was in fact Sorgelig himself who made the initial suggestion to combine ARM emulation with the FPGA:

 

"I want to bring attention to one interesting thing which can be achieved on MiSTer. It's hybrid emulation. It's where both emulation worlds can meet each other."

 

I think what is discouraged is porting projects directly to the ARM (i.e. Retroarch, etc.), essentially treating the DE-10 Nano as a very underpowered Pi.  This type of use seems like strictly an academic exercise to me, and not of much value to the end user.

 

Edited by Jstick
Link to comment
Share on other sites

1 hour ago, Jstick said:

This is not necessarily true; if you check the link in the first post of the thread you referenced, you'll find it was in fact Sorgelig himself who made the initial suggestion to combine ARM emulation with the FPGA:

 

"I want to bring attention to one interesting thing which can be achieved on MiSTer. It's hybrid emulation. It's where both emulation worlds can meet each other."

Fair point. :thumbsup: I guess I let the infamous laughing shoes post, and historic resistance to opening things up to front-ends, incorrectly colour my perception on the general ARM-for-emulation point here.

 

Link to comment
Share on other sites

A while back someone talked about putting a MiSTer-like configuration on a PCIe card for PCs. And we know i7/i9 machines are potent emulation rigs. What's not to like?

 

Wonder if the concept will be revived? And it doesn't need to be on an internal card. Use one of the high-speed interfaces like Thunderbolt3. Good enough for eGPU, good enough for FPGA simulations.

Link to comment
Share on other sites

18 hours ago, orange808 said:

But, calling Spiceware and Champ Games lazy crosses a line.  It's not really "unfortunate".  It's bullshit.  It's the same thing as MrSQL.  It's not different.  Sorry.

Orange I don't always agree with @RevEng, but I think you may be upset for not understanding his perspective.

 

Regarding "lazy programmers" Assembly takes a long time so writing in a high level languages like BASIC or c (particularly the new variants of c) that make it easier to manage and minimize complexity, which you can never get away from because it gets complex anyway hence the initiative to not get complex. I think RevEng understands this pretty well from building tools for programmers to use.    

 

My standpoint is similar to the Audacity team wanting to do the most possible with legacy technology so I wrote a cross compiler for CBS RAM and the SuperCharger format  which was really interesting to explore as part of the nostalgia for me as a programmer is learning more about technology from bitd. With the Atari's flexible architecture there is so much room to learn.

 

Why not try writing in Assembly without MACRO's if you want maximum difficulty as a programming exercise? I think this holds true for the ARM as well; I'd be curious what programmers have written games in pure asm regardless of the chip used.   

 

  • Like 1
Link to comment
Share on other sites

Meh.  I look in the toolbox and try to find the right tool for the job at hand.  I dislike BASIC and always will; it's buried at the bottom of my skull case.  Maybe I'm doing it wrong, because I've never found anything worth doing to be particularly easy.  And...like any other language, I have winding complex love/hate relationship with everything C. 

 

I must be doing it wrong, though.  :-)  Even C# stubbornly refuses to write itself--and I still have to know a lot more about the linker and compiler than I would like.  *shrug*

  • Like 1
Link to comment
Share on other sites

1 hour ago, orange808 said:

Meh.  I look in the toolbox and try to find the right tool for the job at hand.  I dislike BASIC and always will; it's buried at the bottom of my skull case.  Maybe I'm doing it wrong, because I've never found anything worth doing to be particularly easy.  And...like any other language, I have winding complex love/hate relationship with everything C. 

 

I must be doing it wrong, though.  :-)  Even C# stubbornly refuses to write itself--and I still have to know a lot more about the linker and compiler than I would like.  *shrug*

I feel the same way about C# but I like it better than C. PowerShell without c# seems a more intuitive c variant to me, but it has a lot of features reminiscent of BASIC including immediate mode which I really like.

 

I think whichever tools allow us focus more abstractly help make programming projects "relatively easier" to complete.  

 

 

Link to comment
Share on other sites

  • 1 year later...
On 5/26/2021 at 10:54 AM, dlmartins said:

As an aside, this thread/discussion may also be important when AtariAge, Champ Games, etc. start selling roms. People may want to play them on their MiSTer, for the various advantages it provides (lower latency, more accuracy if the core is implemented correctly, etc.), not knowing they will likely never be playable.

At present, if we (and most folks do) consider the Harmony/ARM add-on to be "official", then that makes the MiSTer core incomplete. At the moment its 2600 core doesn't have the capability to understand ARM game code. I would imagine that would change in the future.

 

On 5/26/2021 at 5:57 PM, Yurkie said:

Please forgive my ignorance.

 

Stella emulates Atari 2600 hardware and since we can't update the original hardware, why does Stella require updates?

But from the "game program's" point of view, the original hardware IS updated. There is suddenly a new and different 70MHz processor present. The hardware stack is all-new. Emulators and Simulators have to now provide that new resource.

 

If we look at hardware and software as two separate and distinct things it suddenly becomes clear.

 

The program is the program and that is that. It's no different than any other program. But suddenly the hardware is new again. You've got the original 2600 hardware + the ARM processor in Harmony. This 2600 + ARM combo is an entirely different piece of hardware now. It is a different machine altogether. And this "combo machine" runs code that would not run on a standard 2600 alone. The hardware is still one entity.

 

So. Your emulator or FPGA simulator needs to handle this new combo machine. The code is expecting that hardware (new and old) to be there. Older versions of Stella weren't ARM aware. Didn't know what to do with ARM code. Newer versions are more complete in that they do.

 

A 2600 core for MiSTer now has to include an ARM processor in addition to TIA/RIOT/6502 - if you want to run the new code, the new games.

Edited by Keatah
  • Like 1
Link to comment
Share on other sites

On 7/29/2022 at 4:31 AM, Keatah said:

A 2600 core for MiSTer now has to include an ARM processor in addition to TIA/RIOT/6502 - if you want to run the new code, the new games.

IMO the MiSTer 2600 core should focus on perfect implementation of the 2600's internal hardware (TIA/RIOT/6502), not the carts. I'm not very hardware savvy, but you could connect the FPGA to a physical cartridge slot and then you would be able to plug in and play any Atari 2600 cartridge (even the ARM-based homebrews), right?

That's what I like about the CollectorVision Phoenix FPGA console: it has a cartridge slot which allows you to play any (new or old) ColecoVision cartridge. Note that the Phoenix also has a '2600 core, but that showed several glitches the last time I saw it played on the ZeroPageHomebrew show end of 2019. Hopefully implementation has improved since then.

 

To me, FPGA-implementing the ARM-based cartridges seems like a moving target, as these carts are in active development (i.e. 64k/128k Melody upgrade, PlusCart, MovieCart, etc.)

 

Edited by Dionoid
  • Like 2
Link to comment
Share on other sites

 

On 5/26/2021 at 9:14 AM, dlmartins said:

I had a recent discussion on the MiSTer FPGA discord. It started off as a discussion about preservation that eventually led to enhanced games and their use. I really enjoyed the back and forth discussion.

 

[..]

 

1167412670_MISTer-Atari-HarmonyMelody.thumb.png.9674c08913c952bff74c0330a07bfa3e.png

 

Personally, from a technical level, I can totally understand support in MiSTer not being feasible and it doesn't echo the strict, museum preservation guidelines of MiSTer.

 

However, it does seem disturbing (to me) that any new games for older consoles must be written in a time capsule/time appropriate approach, so they can be supported by older emulation. My thinking is these games are being made today (in 2021) and many Atari DEVs approach it that way, they want to use the latest technology available at this time, not 1992.

The onus is on the people doing the preservation to, well, actually do the preservation and not place blame on developers for not adhering to a certain undefined nebulous spec that isn't in and of itself complete or accurate. For if it were accurate from the get-go there'd be no complaining.

 

Can't ask the ancient Egyptian's to make a mummy a certain way, now, can we. I think not.

Can't ask a modern games developer to not use the tools they have at hand, now, can we. I think not.

 

 

On 5/26/2021 at 9:14 AM, dlmartins said:

My main questions for the Atari development community:
- Is there a danger for enhanced games, by their nature, to not be preserved or playable?

There is not. Emulator Stella has it covered.

 

On 5/26/2021 at 9:14 AM, dlmartins said:

- Is the lack of support in MiSTER and possibly other hardware based approaches for these enhanced games a concern?

Likely only for the users of the current iteration of MiSTer. The way I see it is the A2600 core needs to be re-architected and then placed on a more capable FPGA. Till then it is a concern.

 

On 5/26/2021 at 9:14 AM, dlmartins said:

- Is the use of enhanced games lazy and a lazy approach (compared to a Mapper)?

Absolutely not. And WTF is the difference between an ARM-enhanced game and a mapper? None.

Mapper is just a holdover term from the early days of using basic TTL logic (74LSxxx series) to add in a 2nd ROM. Or a larger ROM with more address space. Above and beyond what the console's bus supports. The term's scope has grown over the years and has come to include complex ASICs. And the ARM is a complex part. And therefore it is a "mapper". https://www.nesdev.org/wiki/Mapper

 

On 5/26/2021 at 9:14 AM, dlmartins said:

- What are the primary reasons for using ARM based enhancements?

To put "complexly processed" data right onto the 2600's bus and into the TIA. Among other reasons, like more memory, more involved game logic, control the TIA in a way the 6502 can't. Sure there's more and I'm happy to leave it to the developers working with Harmony to take it from here.

Link to comment
Share on other sites

9 minutes ago, Dionoid said:

 I'm not very hardware savvy, but you could connect the FPGA to a physical cartridge slot and then you would be able to plug in and play any Atari 2600 cartridge (even the ARM-based homebrews), right?

That would be ideal. Unfortunately the de10-nano doesn't have enough GPIOs free to pull off cart slots. So like an emulator, it has to provide both the console hardware and the cart hardware.

 

If modern homebrew cart hardware makes that feat impossible with the de10-nano (or at least more difficult than mister devs would like) then it just is what it is.

Link to comment
Share on other sites

1 hour ago, Dionoid said:

To me, FPGA-implementing the ARM-based cartridges seems like a moving target, as these carts are in active development (i.e. 64k/128k Melody upgrade, PlusCart, MovieCart, etc.)

Is it really a moving target? 

 

If a cart (regardless of type) works on real hardware, but doesn't work on a FPGA simulator of that hardware, then is it the cart's fault? 

 

I'd say the simulator would need to be corrected so it does work. 

 

1 hour ago, Dionoid said:

IMO the MiSTer 2600 core should focus on perfect implementation of the 2600's internal hardware (TIA/RIOT/6502), not the carts.

That's basically what @Keatah is saying, too. 

 

If the FPGA simulator is perfect, then shouldn't all carts work, yeah? 

 

So what happens if a cart doesn't work? If it works on the real hardware, then you can't blame the cart. 

Link to comment
Share on other sites

9 minutes ago, Dionoid said:

IMO the MiSTer 2600 core should focus on perfect implementation of the 2600's internal hardware (TIA/RIOT/6502), not the carts.

Yes. That is what should be happening. There's a few issues that stop that from happening. Some core developers are simply lazy and don't pay attention to detail. That's one. Second, the 2600 was designed in 1976/1977 when Digital Logic & TTL was still rather new. Analog was still very much a part of things.

 

FPGA implementations, like A2600, are lazy attempts. It doesn't exactly duplicate the cartridge slot signal characteristics. It doesn't bother at all. And if it did try, it wouldn't work because voltage and impedance levels coming from a modern FPGA aren't electrically compatible with 2600 carts. Especially Harmony.

 

Also consider that "perfect implementation" of the 2600 and its main chips must (absolutely must) include the ability to talk to and listen to cartridges and their internal circuitry, ROM and any supporting/enhancement circuitry. That is a fundamental requirement.

 

If you transcend the physical hardware (FPGA or 1977 original) into the world of Software Emulation, then you can do any damned well thing you please. You can have ARM simulation. You are operating in a different dimension.

 

Such a farce claiming high-accuracy reproduction of hardware in FPGA, but not being able to talk to a cartridge using mid-70's electrical signaling and protocols.

 

"Loading" a ROM from modern SD card and "playing" it on FPGA is a partly acceptable. But soon reveals its ugly head when the core is incomplete, lacking advanced mappers. Remember, hardware is hardware, and that includes the power supply, the console, the chipset, the switches, the RF modulator, the cartridge connector, the PCB that plugs into the cartridge connector, and especially any parts & processors ON that cartridge. All that hardware has to be simulated in the core. And the core developers must not be lazy and be sure they cover it all.

 

The only thing not required to be in there is the game program software - that comes from the outside like ROM on SD card. That comes from the game developer. Just like in 1977. Make sense?

 

9 minutes ago, Dionoid said:

I'm not very hardware savvy, but you could connect the FPGA to a physical cartridge slot and then you would be able to plug in and play any Atari 2600 cartridge (even the ARM-based homebrews), right?

Ideally yes. You'd likely need some voltage and current translators to interface with vintage parts in vintage cartridges.

 

As long as the FPGA is programmed as an interactor and not a blind-reader, then sure.

 

10 minutes ago, Dionoid said:

That's what I like about the CollectorVision Phoenix FPGA console: it has a cartridge slot which allows you to play any (new or old) ColecoVision cartridge. Note that the Phoenix also has a '2600 core, but that showed several glitches the last time I saw it played on the ZeroPageHomebrew show end of 2019. Hopefully implementation has improved since then.

 

To me, FPGA-implementing the ARM-based cartridges seems like a moving target, as these carts are in active development (i.e. 64k/128k Melody upgrade, PlusCart, MovieCart, etc.)

Not necessarily. Look at it this way. If the FPGA Simulator is correct and true to the original, then it doesn't matter what you put in the slot. It will work.

 

If the developers (of the emulator/simulator) are lazy and made shortcuts (or took the wrong approach), then there will need to be updates and patches and hacks for each new game & mapper that comes out. So much for preservation, or the hubristic pretense of preservation. We don't go around upgrading each 2600 console everytime a new cartridge comes out, now, do we..?

 

So much for preservation. Whoot!

 

  • Like 1
Link to comment
Share on other sites

Emulating proper hardware behavior while using physical carts is not a moving target. That's FUD.

 

Edit:  I didn't say it's easy. I didn't say it's even possible. But, emulating the existing hardware behavior with accuracy does not qualify as a moving target. And, that's the context of the latest discussion on this. We were talking about emulating with real carts. 

 

That removes the need to emulate the Harmony. I also don't care if the MiSTer runs new roms. That encourages bad behavior.

Edited by orange808
  • Like 1
Link to comment
Share on other sites

37 minutes ago, orange808 said:

Emulating proper hardware behavior while using physical carts is not a moving target. That's FUD.

Yes. I get what you're saying.

 

When emulating and simulating, you have two things the endeavor can be broken down into:

1- the stuff that does the recreation (FPGA or Software Emulator).

2- and the game rom program.

 

In case of using FPGA with cartridges, all you need to do is duplicate the behavior of the original console at the signal level. Get the signals to and from the cartridge true to the original. You're good to roll. Your simulacrum is accurate (e.g. not lazy) and that's all you need. MiSTer doesn't do it, for whatever technical/developer reason.

 

In the case of FPGA reading roms from SDcard, it's a whole new ballgame. The simulacrum must now virtualize not only the original console, it must absolutely include the various hardware in the cartridges. And that's because that's what the rom itself is expecting to see.

 

Combat and Miniature Golf are simple 2K roms. Nothing special required. But all the new bankswitch stuff (4k and up) and cartridges with active processors going on.. Well, now, your simulacrum needs to do that hardware - because that's what the software is expecting. And MiSTer can't do that either.

 

Any complaining about it isn't going to fix anything.

 

It's like a librarian/preservationist asking Leonardo DaVinci to put his writings on a different color paper because their scanner doesn't like parchment or whatever. Ain't gonna happen! Instead the lazy preservationist needs to get off their ass and fix their equipment.

 

DaVinci made no accommodations. And neither should a developer making modern-day ARM-enhanced games.

 

37 minutes ago, orange808 said:

Edit:  I didn't say it's easy. I didn't say it's even possible. But, emulating the existing hardware behavior with accuracy does not qualify as a moving target. And, that's the context of the latest discussion on this. We were talking about emulating with real carts.

Actually we're wanting a MiSTer to replace an old ratbaggy console from 50 years ago. Because users don't want to give up a wall of carts on display. Because users are lazy and not bothering to learn how to repair and maintain old hardware. Or more gently, users don't want to put wear and tear on their prized vintage hardware.

 

Besides, all kinds of cognitive dissonance arises when you plug a SlotRacers or FlagCapture cartridge into a small square box that looks nothing like the original 2600. The experience is incomplete. At conflict with itself. If you're going to go for a modern 2022-made box, then just use the fucking rom. Modernize that rom's delivery mechanism (SDcard) just as you modernized the console's (FPGA or SoftwareEmulator) into a tiny silver box.

 

Essentially you're asking for a remake of the 1976/1977 era hardware. MiSTer and the lazy devs can't or won't do that. There's that word again, L A Z Y ! ! I wonder why that keeps coming up?

 

37 minutes ago, orange808 said:

That removes the need to emulate the Harmony. I also don't care if the MiSTer runs new roms. That encourages bad behavior.

It could. Skipping emulating/simulating the Harmony hardware is just like skipping any old mapper. Or the SuperCharger, or DPC.. Those are ingrained into 2600 culture. And Harmony has grandfathered itself into the same group because of time. It's been around forever. Is popular. And is just another enhancement mapper. Albeit a feature-rich and complex mapper.

Link to comment
Share on other sites

On 7/31/2022 at 7:23 AM, Keatah said:

Combat and Miniature Golf are simple 2K roms. Nothing special required. But all the new bankswitch stuff (4k and up) and cartridges with active processors going on.. Well, now, your simulacrum needs to do that hardware - because that's what the software is expecting. And MiSTer can't do that either.

Not sure if you are up to date with recent developments, but the 7800 MiSTer core can perfectly replicate any bankswitch scheme from the original 2600 carts, all the way up to the Pitfall II DPC and Supercharger (it can even load supercharger games via physical audio tape). 

 

It's only the modern Melody enhanced games (the "active processors" you refer to) that it doesn't attempt to simulate.

 

From my testing, the 7800 core is at least as accurate as Stella for 2600 games released during the VCS's lifetime.

 

 

  • Thanks 1
Link to comment
Share on other sites

  • 3 weeks later...
On 8/5/2022 at 11:10 PM, Jstick said:

Not sure if you are up to date with recent developments, but the 7800 MiSTer core can perfectly replicate any bankswitch scheme from the original 2600 carts, all the way up to the Pitfall II DPC and Supercharger (it can even load supercharger games via physical audio tape). 

 

It's only the modern Melody enhanced games (the "active processors" you refer to) that it doesn't attempt to simulate.

 

From my testing, the 7800 core is at least as accurate as Stella for 2600 games released during the VCS's lifetime.

 

 

I hope someday it can run Melody enhanced games so I can buy all of the champ roms and enjoy them on the Mister.  

  • Like 2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...