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

[Keatah]

Wonder if MiSTer has enough reserve power/LE to run ARM + 2600. It handles a 486PC, but barely. Really pushing on that.

[+Gemintronic]

1 hour ago, Keatah said:

Wonder if MiSTer has enough reserve power/LE to run ARM + 2600. It handles a 486PC, but barely. Really pushing on that.

 

I'm afraid not.  The handful of shitty 2600 homebrewers using ARM actually curses FPGA core development with bugs and weird requirements like needing 2 RAM modules on your MiSTer.

[youxia]

1 hour ago, Keatah said:

It handles a 486PC, but barely. Really pushing on that.

It's probably more to do with the nature of the ao486 core. It was ported from Bosch's emulator somewhat directly and then kind of roughly chopped to measure on MiSTer. The result is not ideal, and seeing as it's hard to even compile it properly, the devs are reluctant to touch it. Maybe if it was written from scratch te results would be better.

 

Still, it actually works pretty well in most cases.

[RevEng]

It's not just a matter of having enough gates to add an ARM chip. The disparate parts require relative timing correctness. A low-level emulation of an ARM chip feeding the 6502 by bit-banging the bus requires that both parts are cycle accurate. A small slip in the timing and it all blows up. Further complicating things is the fact that "rom" is provided by sdram here, since Mister doesn't have an actual cartridge connector.

 

A 486 may be similar to a 2600+arm in terms of complexity or fpga gates (no idea if that's the case actually) but the same sort of cycle-accurate dance isn't needed for a core capable of playing 486 games. The correspondence of mister components to actual 486 components is also much closer. (sdram provides the 486 sdram, An image on block storage provides the 486 block storage)

[+Gemintronic]

10 hours ago, Gemintronic said:

 

I'm afraid not.  The handful of shitty 2600 homebrewers using ARM actually curses FPGA core development with bugs and weird requirements like needing 2 RAM modules on your MiSTer.

 

Just to be clear this is a joke in regards to the quotes cited in the first post.  I think that FPGA core developers should be celebrated for their work.  But, when they make baseless statements about homebrew (and in turn the community members who make the games) that also should be recognized. 

[Rodney Hester]

I wonder what direction the discussion would take if someone coded a 2600 game to run on an AS/400 or Cray Y/MP and pipe the signal output into the cartridge port of a real 2600.  Would Stella emulate it?

 

At some point, the 2600 isn't even the platform anymore - it's reduced entirely to I/O.  When there's more operational complexity going on in the cartridge than the machine, I think a reasonable line can be drawn.

 

This isn't like Pitfall II or even the FX chip on the SNES.  ARM games are on entirely another level, and calling them "2600 games" is a bit of a stretch IMHO.  They are games, yes, but they could just have readily been programmed for a Raspberry Pi...they just happen to be using the 2600 as a bridge to the output device and redirecting input.  Very little of any import is going on *in the system* anymore.

[orange808]

49 minutes ago, Rodney Hester said:

I wonder what direction the discussion would take if someone coded a 2600 game to run on an AS/400 or Cray Y/MP and pipe the signal output into the cartridge port of a real 2600.  Would Stella emulate it?

 

At some point, the 2600 isn't even the platform anymore - it's reduced entirely to I/O.  When there's more operational complexity going on in the cartridge than the machine, I think a reasonable line can be drawn.

 

This isn't like Pitfall II or even the FX chip on the SNES.  ARM games are on entirely another level, and calling them "2600 games" is a bit of a stretch IMHO.  They are games, yes, but they could just have readily been programmed for a Raspberry Pi...they just happen today be using the 2600 as a bridge to the output device and redirecting input.  Very little of any import is going on *in the system* anymore.

 

[Rodney Hester]

42 minutes ago, orange808 said:

 

I am assuming this is a SOP reply for any argument not fitting the desired narrative and giving it all the respect it therefore deserves.

[orange808]

I hope I can get over it... 

;-/

 

Oh!

8-D

 

I just did! 

[Keatah]

1 hour ago, Rodney Hester said:

I am assuming this is a SOP reply for any argument not fitting the desired narrative and giving it all the respect it therefore deserves.

It is.

 

2 hours ago, Rodney Hester said:

I wonder what direction the discussion would take if someone coded a 2600 game to run on an AS/400 or Cray Y/MP and pipe the signal output into the cartridge port of a real 2600.

Hard to say unless actual discussion commences. I think it's safe to say the 2600 would become a terminal display device.

 

2 hours ago, Rodney Hester said:

Would Stella emulate it?

Tough to say. It depends on how far away from the 2600 the developers would want to take Stella. I guess..?

At some point it would be like designing a GPU shader to give a 2600-lokk to a supercomputer or something like that.

 

2 hours ago, Rodney Hester said:

At some point, the 2600 isn't even the platform anymore - it's reduced entirely to I/O.  When there's more operational complexity going on in the cartridge than the machine, I think a reasonable line can be drawn.

Correct. It's why I don't get excited over other things that connect early 8-bit consoles and computers to the internet. With most accelerators and R-Pi expansions, on the Apple II, the vintage computer is indeed relegated to display duties only. A terminal.

 

But I do reserve a "valid" status for Harmony/Melody expansion. And I do that simply because the games produced for the platform (and it is a platform) are so very much "2600" in content, style, feel, aura, whatever have you. I feel like I'm playing a 2600 game. A game that isn't much different from the better earlier cartridge releases. And I believe this is as far as we should go.

 

As to where to draw the line. I don't know. It's vague. I do know we shouldn't go much beyond it, if at all. Because then just might as well switch platforms to something different and more capable.

 

The SuperCharger is also another valid platform. Unfortunately it's a dead one and I haven't seen any A+ title for it.

 

2 hours ago, Rodney Hester said:

This isn't like Pitfall II or even the FX chip on the SNES.  ARM games are on entirely another level, and calling them "2600 games" is a bit of a stretch IMHO.

Possibly. Games still have to rely on the TIA for sound and graphics. A big plus there because that is the heart and soul of the 2600. And ARM games aren't changing that personality much. I could consider the Harmony/Melody as an upgrade to the 2600 console. Not unlike a 3D chip or a Pentium II to Pentium III upgrade on a PC.

 

2 hours ago, Rodney Hester said:

  They are games, yes, but they could just have readily been programmed for a Raspberry Pi...they just happen to be using the 2600 as a bridge to the output device and redirecting input.  Very little of any import is going on *in the system* anymore.

IMHO that's still open to debate because of TIA. I'm not a developer, just an enthusiast, but I'm sure the 6507 and RIOT are still used in some way.

 

Yes, where the bulk of the processing takes place remains an important point. Perhaps it should be a an important marker.

 

For now I'm happy to "grandfather in" Harmony/Melody as an upgrade. Many respectable games have been done already. But I don't think I'd go any further than it.

[+splendidnut]

Hmmm... I think this discussion has been done before...

 

 

Oh wait, there it is.

 

Carry on.

[Dionoid]

2 hours ago, Keatah said:

7 hours ago, Rodney Hester said:

  They are games, yes, but they could just have readily been programmed for a Raspberry Pi...they just happen to be using the 2600 as a bridge to the output device and redirecting input.  Very little of any import is going on *in the system* anymore.

IMHO that's still open to debate because of TIA. I'm not a developer, just an enthusiast, but I'm sure the 6507 and RIOT are still used in some way.

For each Atari 2600 game, no matter what's inside the cartridge, the 6507 is still the only chip that can instruct the TIA about what graphics it should output to the TV. So also for ARM games, the 6507 and TIA are working like crazy to display each screen frame. But like @splendidnut just mentioned, there is an existing thread on this 🙂

 

I just wish the DE10-Nano would have enough GPIO pins to make it possible to have the FPGA read directly from an actual cartridge, like the CollectorVision Phoenix FPGA console. But from the discussion in this thread, I understand the current implementation of the A2600 FPGA wouldn't support that out of the box.

 

Edited August 30, 2022 by Dionoid

[JetSetIlly]

5 hours ago, Dionoid said:

For each Atari 2600 game, no matter what's inside the cartridge, the 6507 is still the only chip that can instruct the TIA about what graphics it should output to the TV. So also for ARM games, the 6507 and TIA are working like crazy to display each screen frame.

 

This is exactly right and is something that many ARM criticisms perhaps don't take into account.  The interaction of the ARM chip with the  2600 hardware is very interesting and not at all easy to get right for the game developer. It doesn't matter how fast the "coprocessor" is there are still significant limitations on what can be achieved.

[+Andrew Davie]

25 minutes ago, JetSetIlly said:

 

This is exactly right and is something that many ARM criticisms perhaps don't take into account.  The interaction of the ARM chip with the  2600 hardware is very interesting and not at all easy to get right for the game developer. It doesn't matter how fast the "coprocessor" is there are still significant limitations on what can be achieved.

I reject your limitations and impose my own!

[+batari]

On 8/29/2022 at 11:25 AM, Rodney Hester said:

I wonder what direction the discussion would take if someone coded a 2600 game to run on an AS/400 or Cray Y/MP and pipe the signal output into the cartridge port of a real 2600.  Would Stella emulate it?

 

At some point, the 2600 isn't even the platform anymore - it's reduced entirely to I/O.  When there's more operational complexity going on in the cartridge than the machine, I think a reasonable line can be drawn.

 

This isn't like Pitfall II or even the FX chip on the SNES.  ARM games are on entirely another level, and calling them "2600 games" is a bit of a stretch IMHO.  They are games, yes, but they could just have readily been programmed for a Raspberry Pi...they just happen to be using the 2600 as a bridge to the output device and redirecting input.  Very little of any import is going on *in the system* anymore.

Nope, this is not what is happening at all and this shows a lack of understanding about the architecture of the 2600. The ARM chip does not turn the 2600 into an I/O device. It assists at creating a custom instruction stream for the 6507 to run. The 6507 is running code the entire time and 100% of the display is produced via this 6507 code. Take any screenshot of any released ARM-based game, and this static screen can be hard-coded to display without an ARM chip at all.

 

This is why ARM-based games retain the flavor of non-assisted 2600 games - because they are still running 6507 code the entire time. The 6507 is never interrupted or overpowered for any of the current ARM-based games out there.

 

I doubt the FX chip or other 90s coprocessor carts in the 16-bit era had those kinds of limitations.

[Keatah]

2 hours ago, batari said:

The ARM chip does not turn the 2600 into an I/O device. It assists at creating a custom instruction stream for the 6507 to run. The 6507 is running code the entire time and 100% of the display is produced via this 6507 code.

 

This is why ARM-based games retain the flavor of non-assisted 2600 games - because they are still running 6507 code the entire time.

This is the *magic* that happens in these enhanced games. This is why the flavor is vintage Atari through and through. The sounds, the graphics, the other ineffable qualities that we grew up with. A fine explanation understandable by the layperson.

Edited September 1, 2022 by Keatah

[Mr SQL]

On 8/29/2022 at 2:25 PM, Rodney Hester said:

I wonder what direction the discussion would take if someone coded a 2600 game to run on an AS/400 or Cray Y/MP and pipe the signal output into the cartridge port of a real 2600.  Would Stella emulate it?

Interesting analogy, here's an example with a 2600 game coded to run on the Commodore 64 Atari emulator GameLoader which recompiles 2600 source to add fantastic Commodore graphics to enhance the games similar to your hypothetical:

 

Stella could emulate the Commodore 64 enhanced Atari 2600 games if support for the Commodore 64 were added like in your hypothetical example, similar expansion was added for ARM and Pitfall II support.

 

On 8/29/2022 at 2:25 PM, Rodney Hester said:

At some point, the 2600 isn't even the platform anymore - it's reduced entirely to I/O.  When there's more operational complexity going on in the cartridge than the machine, I think a reasonable line can be drawn.

 

It's I/O driven or GameLoader would have remained vaporware, but even with classic 2600  programming the architecture is largely I/O driven with the gameloop and dynamic graphics manipulations in the vertical blanks, driving the kernel.

    

6 hours ago, batari said:

The ARM chip does not turn the 2600 into an I/O device. It assists at creating a custom instruction stream for the 6507 to run. The 6507 is running code the entire time and 100% of the display is produced via this 6507 code. Take any screenshot of any released ARM-based game, and this static screen can be hard-coded to display without an ARM chip at all.

 

This is why ARM-based games retain the flavor of non-assisted 2600 games - because they are still running 6507 code the entire time. The 6507 is never interrupted or overpowered for any of the current ARM-based games out there.

 

Really? The examples above use a soft chip but while it's engaged the Atari can't do anything else. I remember reading the ARM assisted games were similar, and while the ARM was running the game loop and graphics prep in the vertical blanks the 6502 was dormant. Did this design change? It seems like both chips should be able to run simultaneously.

 

6 hours ago, batari said:

Take any screenshot of any released ARM-based game, and this static screen can be hard-coded to display without an ARM chip at all.

 

The soft chip prepares dynamic graphics similarly, and the kernel just renders a static image. The chip can be disengaged and the static screen will stay in place.

Some of the soft ANTIC games also change the video signal to create more time similar to what happens with the ARM.

 

Agree these all retain the flavor of classic Atari games because of the 6502 kernel.

 

4 hours ago, Keatah said:

This is the *magic* that happens in these enhanced games. This is why the flavor is vintage Atari through and through. The sounds, the graphics, the other ineffable qualities that we grew up with. A fine explanation understandable by the layperson.

 

X2!

[+splendidnut]

6 minutes ago, Mr SQL said:

Really? The examples above use a soft chip but while it's engaged the Atari can't do anything else. I remember reading the ARM assisted games were similar, and while the ARM was running the game loop and graphics prep in the vertical blanks the 6502 was dormant. Did this design change? It seems like both chips should be able to run simultaneously.

Your understanding is correct.  Crazy, I know.  I should walk away, but I'm going to elaborate anyways:

 

The ARM chip spends the majority of it's time running as a ROM / bank-switch emulator.  For games that use ARM-based game logic, I believe the 6507 is fed NOPs, so that it would indeed be dormant (but still running...).

 

Using logic that's right up your alley, both chips are running simultaneously (that's how chips work... the TIA, the RIOT, and the 6507 run simultaneously).  But, in the case of the ARM and 6507, only one can be running user code at any given time.  The ARM chip can either be running as a ROM emulator, or running user code, but not both.

 

Hopefully that clarifies things a bit.

 

P.S.  Please note I'm not an expert in this, only a mere bystander that tries to fully understand and appreciate the totality of what the 2600 can offer without accusing it of being just an I/O device.

[+Andrew Davie]

6 minutes ago, splendidnut said:

The ARM chip spends the majority of it's time running as a ROM / bank-switch emulator.  For games that use ARM-based game logic, I believe the 6507 is fed NOPs, so that it would indeed be dormant (but still running...).

I didn't really want to get into this "argument", but since I think I understand somewhat how things work, I thought I'd at least make a note on the above point.  What is happening is that usually the ARM services the BUS for the 6507 -- so the 6507 puts an address on the BUS and the ARM detects this and puts appropriate data on the data BUS.  However, during VB and overscan, the ARM is able to run "user code" but in doing so it no longer services the 6507 BUS, so the 6507 - still running - becomes a free agent. But the BUS is no longer serviced, so no matter what the 6507 puts on the address BUS (aside from internally mapped addresses such as zero page and TIA), there will be no change in the data BUS.  Normally this would be a disaster, but if before the ARM stops servicing the BUS, it places a NOP ($EA) on the data BUS, then for all intents and purposes, the 6507 will think it's being fed a bunch of NOPs, as it puts an address on the BUS, "gets" a NOP on the data bus, and continues "to the next instruction address".  In quotes, because, as I said, the BUS isn't being serviced.

 

But what's still happening here is that the 6507 is running and its PC is incrementing.  So you have an inherent limitation here -- eventually the PC will wander into address ranges that are actually mapped to internal locations and the data BUS will change - and then you have all sorts of disasters, as the 6507 starts executing essentially random code.

 

So you have two issues; firstly you need to make sure that the 6507's PC is somewhere low in ROM -- the lower the betterer - and that gives you more time for the "NOP trick" to work. More time to do ARM user-code stuff.   And secondly you need to make sure when you resume from the ARM user-code, you somehow get the 6507 back into a "known state" with regard to the PC and the data BUS servicing by the ARM.

 

That's my understanding, anyway.  This would be so much simplified if the ARM could use an interrupt-based routine to service the data BUS... but that's not how it works at the current time.  In actual practise, it's a fairly transparent process -- once you've got the basics setup, you can go away and do an awful lot in the ARM code, and to some degree syncrhonise it with the 6507 code so they both communicate variables, states, etc.  It's a very clever system.

 

Ultimately, though, the 6507 is doing all the writes to the graphics and sound registers -- from data placed on the BUS by the ARM as a result of requests from the 6507.  In VB and overscan it is possible to "halt" the 6507, though in fact it is not halted at all. If you wanted to run zero page code while the ARM was doing stuff, I believe that would work.  The mostest cleverness of the ARM assist hardware, in my view, is allowing the 6507 to minimise cycles in the loads by directly placing the data on the bus in response to a two-cycle immediate load instead of requiring it to place an address on the address BUS and wait for a few cycles to lookup/return data.

 

Those who know better, please correct my errors. I've shared what I think I know but of course I'm just a learner.

 

 

[+SpiceWare]

47 minutes ago, Andrew Davie said:

If you wanted to run zero page code while the ARM was doing stuff, I believe that would work.

Yep - I did that in an early DPC+ music test before we had support for IRQ driven 3 voice music while running custom ARM code. I prefetched audio values into ZP RAM, then had a loop running in ZP RAM that feed the cached values to TIA once per scan line. The loop would check a known ROM location and exit once the expected value came back (ie not the NOP).

 

it worked, though the audio was terrible because I didn't realize it wasn't designed to let you prefetch values.

[orange808]

+1 on the misconceptions about what the 6507 is doing.

 

By definition, DPC music is hammering an audio register very quickly and the 6507 is the only one that can talk to TIA. So, when people say the 6507 isn't working during blanking periods, it's misleading.

 

And, when you do put the 6507 into an extended NOP status and (simultaneously) maintain the program counter, you incur a tradeoff penalty with audio--and the developer is forced to rely on "standard" TIA audio. There's no free lunch with the Atari.

[orange808]

Ah, the amazing efficiency of the legacy dev. Like identical caches of the lives counter in Burgertime on the zero page. Why? Well, the score kernel and the game will check it, so let's cache it twice. So efficient. Great job.

Edited September 9, 2022 by orange808

[RevEng]

[!!!sarcasm detected!!!]

 

Seems a bit of a cheap shot. A working programmer sometimes does something sub-optimally with an idea to return to it later, but later never comes because everything works and the product has to ship. Maybe Surratt had code that originally stomped one of those locations. Or maybe he did forget, because he had enough zp memory available anyway.

 

I don't think that takes away from the fact that the 6502 in general, and the 2600 in specific, has a pretty high baseline of efficiency you need to adhere to to get things done.

 

[orange808]

On 9/12/2022 at 8:27 PM, RevEng said:

[!!!sarcasm detected!!!]

 

Seems a bit of a cheap shot. A working programmer sometimes does something sub-optimally with an idea to return to it later, but later never comes because everything works and the product has to ship. Maybe Surratt had code that originally stomped one of those locations. Or maybe he did forget, because he had enough zp memory available anyway.

 

I don't think that takes away from the fact that the 6502 in general, and the 2600 in specific, has a pretty high baseline of efficiency you need to adhere to to get things done.

 

Oh, no. If you want to see cheap shots, hit up the Displaced Gamer YouTube channel. There, you'll find plenty of it--especially in comments.

 

My point is:  legacy games are romanticized to extreme levels and the realities don't always match the narrative--and that narrative is right here in this thread. And, sorry for the cheap shot, written by some people that don't look at the code of the games.

 

I know good and well why things aren't perfect. It's because working in assembler with E1 bank switching is difficult--and the environment itself limited the dev's ability to be efficient. There were likely some other things going on, too. It seems unfinished.

 

Yet, the romanticized lie of perfect "tight code" from the hands of Gods on Mount 6507 gets used to tar and feather anything ARM.

 

Plenty of cheap shots to go around, I suppose. And, I found plenty more silliness disassembling Burgertime--although I'm not done, yet. I want to fix some of the worst problems. There's a playable game in there.

[RevEng]

On 9/14/2022 at 10:42 PM, orange808 said:

Yet, the romanticized lie of perfect "tight code" from the hands of Gods on Mount 6507 gets used to tar and feather anything ARM.

Yeah, both are stupid generalisations. Unfortunately these generalisations get propagated by clueless people who wouldn't know good or bad 6502 code, or the difficulties in optimally interfacing the ARM to the 6502. Also a different group, but still as clueless, are the ones who think recent ARM enhanced titles would have saved Atari back in the day. I don't think there's much to be done here, beyond factual corrections when you see bad assertions.

 

I think it's fine to point out sub-optimal 6502 code in a technical review sense. Singling one game out for a bit of "bad code" shaming just seems overly harsh to the author, given the game runs as intended, and was written decades ago in a commercial setting. Could entirely be just my own personal hangup, though.