Jump to content
IGNORED

The Atari 2600+ is live for preorders!


jgkspsx

Recommended Posts

1 minute ago, tep392 said:

That is probably the easiest way to do it.  Otherwise some algorithm would need to be developed to write hotspots and attempt to deduce presence of RAM and ROM and bank logic.  But this also means that future updates will be needed as new homebrews are released, unless some new standard is developed to include a header in the binary. :)

Yeah, while this works well, I'm not crazy about it as it does require the emulator itself needs to be updated to properly support new games.  If there wasn't an active homebrew scene producing new games, this wouldn't be a big deal at all, but obviously that is not the case.  So, yes, this will require periodic updates for both Stella and ProSystem.

1 minute ago, tep392 said:

It also means that you will need some help from the devs of carts you didn't produce to get MD5 data for any revisions they made during cart production.

Yes, once I get all the AtariAge-related games in there, I'll need to reach out to others for help getting the necessary data for games produced in physical form from other parties. 

 

 ..Al

  • Like 1
Link to comment
Share on other sites

1 minute ago, Albert said:

Yeah, while this works well, I'm not crazy about it as it does require the emulator itself needs to be updated to properly support new games.  If there wasn't an active homebrew scene producing new games, this wouldn't be a big deal at all, but obviously that is not the case.  So, yes, this will require periodic updates for both Stella and ProSystem.

Yes, once I get all the AtariAge-related games in there, I'll need to reach out to others for help getting the necessary data for games produced in physical form from other parties. 

 

 ..Al

I made a quick edit to my post while you were replying.  How about devs agree to put the A78 header data in the binary.  Maybe just before the signature data.  The 2600+ could check that first, and if a header is present there's no need to check the database.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

12 minutes ago, tep392 said:

I made a quick edit to my post while you were replying.  How about devs agree to put the A78 header data in the binary.  Maybe just before the signature data.  The 2600+ could check that first, and if a header is present there's no need to check the database.

I do like the idea that the data is in the binary, but that would require modifications to the emulator itself, and it would need to support both mechanisms if the header metadata is not present.  This also assumes there's enough room in the binary to add this information, since you obviously cannot increase the size of the binary itself for physical carts. 

 

This also doesn't solve the problem for the many thousands of homebrew carts already out in the wild, though, nor can you force developers to include this information, so you're very likely going to need to continue updating the emulator database over time regardless. 

 

 ..Al

  • Like 2
Link to comment
Share on other sites

14 minutes ago, Albert said:

I do like the idea that the data is in the binary, but that would require modifications to the emulator itself, and it would need to support both mechanisms if the header metadata is not present.  This also assumes there's enough room in the binary to add this information, since you obviously cannot increase the size of the binary itself for physical carts. 

 

This also doesn't solve the problem for the many thousands of homebrew carts already out in the wild, though, nor can you force developers to include this information, so you're very likely going to need to continue updating the emulator database over time regardless. 

 

 ..Al

My suggestion is for new homebrew releases.  If those extra 128 bytes means a game is going from a 48k cart to a banked cart, then that might be a drawback.  But I do see an incentive for devs to include some data in their new games if it means will be compatible with the 2600+ without having to wait for a firmware update to be released.  Most modern games don't use every last byte, so including the data shouldn't be a problem.  Maybe it can be discussed at the next meeting of the 7800 Homebrew Software Engineering Standards Committee. ;)

 

  • Like 2
Link to comment
Share on other sites

4 hours ago, Ben from Plaion said:

Have you isopropanol alcohol and qtips to hand? I really recommend cleaning your cartridge contacts as you go through them.

Of course.  Although a lot of what I intend to test on the 2600+ is already clean thanks to me also pulling out my 2600jr, my 7800, and hooking up a Retron 77.  I really want to see the 7800 titles in action with better video quality.

 

 

Link to comment
Share on other sites

22 minutes ago, tep392 said:

My suggestion is for new homebrew releases.  If those extra 128 bytes means a game is going from a 48k cart to a banked cart, then that might be a drawback.  But I do see an incentive for devs to include some data in their new games if it means will be compatible with the 2600+ without having to wait for a firmware update to be released.  Most modern games don't use every last byte, so including the data shouldn't be a problem.  Maybe it can be discussed at the next meeting of the 7800 Homebrew Software Engineering Standards Committee. ;)

 

While the current plan for existing homebrews makes a lot of sense, the more I think about it the more I think it is a bad way to go for future releases.  It will require periodic software updates which is an ongoing expense for Atari.  And what happens when Atari eventually stops making updates for the 2600+.  Any homebrews developed after that point will not be supported by the 2600+.  They way we have been doing it works fine because the old hardware is fixed.  I believe we need some standards going forward to support new and future hardware releases.  Constantly updating databases in firmware is less than ideal.

  • Like 2
Link to comment
Share on other sites

4 hours ago, Ben from Plaion said:

 I said to him you know people actually develop fake overlays over that crisp display to mimic long obsolete CRT screens whilst pointing to his monitor.

 

He said in disbelief "Why the hell would people do that?"

 

With that I activated the neuralyzer and hot skipped it back to 2023 where I filed CRT overlays task into the "Maybe - if we can do it after launch" folder.

Back in the day, if you could afford one you were looking for a line doubler and a capable displays to eliminate scanlines.  Now that we no longer need to mess around with that, people want to put the scanlines back in!

 

Nostalgia is a strange beast.

  • Like 2
Link to comment
Share on other sites

10 minutes ago, tep392 said:

While the current plan for existing homebrews makes a lot of sense, the more I think about it the more I think it is a bad way to go for future releases.  It will require periodic software updates which is an ongoing expense for Atari.  And what happens when Atari eventually stops making updates for the 2600+.  Any homebrews developed after that point will not be supported by the 2600+.  They way we have been doing it works fine because the old hardware is fixed.  I believe we need some standards going forward to support new and future hardware releases.  Constantly updating databases in firmware is less than ideal.

What you're proposing would need to be done for Stella as well...

 

 ..Al

Link to comment
Share on other sites

27 minutes ago, Albert said:

What you're proposing would need to be done for Stella as well...

 

 ..Al

Is there a technical reason for that?  Seems like it would be nice, but not required for 2600 carts.  The 2600+ is surely able to determine if a 2600 or 7800 cart is plugged in.  

Link to comment
Share on other sites

4 minutes ago, tep392 said:

Is there a technical reason for that?  Seems like it would be nice, but not required for 2600 carts.  The 2600+ is surely able to determine if a 2600 or 7800 cart is plugged in.  

Stella uses the same mechanism for determining the bankswitching scheme for 2600 games.  It generates an MD5 checksum, looks the game up in its internal database, and if found, it knows how to run the cart.  Otherwise I think it makes an attempt to determine what bankswitching scheme might be used (or if it's just a 2K/4K game), but I don't know how well it works.  If you want new homebrew games to run without having to continually update that stella.pro file and make updates available for people to download in order to run those new games, you'd need to do the same thing for 2600 games that you are proposing for 7800 games. 

 

 ..Al

  • Like 1
Link to comment
Share on other sites

5 minutes ago, Albert said:

Stella uses the same mechanism for determining the bankswitching scheme for 2600 games.  It generates an MD5 checksum, looks the game up in its internal database, and if found, it knows how to run the cart.  Otherwise I think it makes an attempt to determine what bankswitching scheme might be used (or if it's just a 2K/4K game), but I don't know how well it works.  If you want new homebrew games to run without having to continually update that stella.pro file and make updates available for people to download in order to run those new games, you'd need to do the same thing for 2600 games that you are proposing for 7800 games. 

 

 ..Al

Hmm.  But Stella doesn't run the 7800 carts.  Don't they identify 2600 vs. 7800 first thing, and then decide which emulator to run?  Or did they use Stella code to implement the same MD5 checksum process on 7800 carts?  Either way, they need to decide if the cart is 2600 or 7800 and that doesn't require any checksums.  The flags to identify 7800 carts are part of the original Atari 7800 cart standard.  If they cart is a 7800, then it's easy to check if it has the A78 header data.  If it doesn't then use the MD5 process.  Doesn't seem very hard to me.

  • Like 1
Link to comment
Share on other sites

1 hour ago, Chemical Burrito said:

Back in the day, if you could afford one you were looking for a line doubler and a capable displays to eliminate scanlines.  Now that we no longer need to mess around with that, people want to put the scanlines back in!

 

Nostalgia is a strange beast.

Its easy to say cleaver things like this to get likes but dont group one group in with the other.

I, nor anyone I knew ever complained about the CRT screens and their lines and blooming. 

Link to comment
Share on other sites

7 minutes ago, tep392 said:

Hmm.  But Stella doesn't run the 7800 carts.  Don't they identify 2600 vs. 7800 first thing, and then decide which emulator to run? 

Sure, the 2600+ definitely needs to first determine if you've plugged in a 2600 or 7800 cartridge, then it has to attempt to dump the cartridge so it can pass the resulting binary to the appropriate emulator.  I'm not sure how it does the check, but since the 7800 has eight extra lines on the cartridge connector, I have to assume it's pretty easy to do.

10 minutes ago, tep392 said:

The flags to identify 7800 carts are part of the original Atari 7800 cart standard.  If they cart is a 7800, then it's easy to check if it has the A78 header data.  If it doesn't then use the MD5 process.  Doesn't seem very hard to me.

Yes, for 7800 carts, what you have proposed solves the issue for new 7800 games going forward.  But you'd want to do the same exact thing with new 2600 games if you also want to give Stella the ability to play those games if there's no stella.pro entry for them yet.  Or am I misunderstanding what you're saying?

 

 ..Al

Link to comment
Share on other sites

4 minutes ago, Albert said:

Sure, the 2600+ definitely needs to first determine if you've plugged in a 2600 or 7800 cartridge, then it has to attempt to dump the cartridge so it can pass the resulting binary to the appropriate emulator.  I'm not sure how it does the check, but since the 7800 has eight extra lines on the cartridge connector, I have to assume it's pretty easy to do.

Yes, for 7800 carts, what you have proposed solves the issue for new 7800 games going forward.  But you'd want to do the same exact thing with new 2600 games if you also want to give Stella the ability to play those games if there's no stella.pro entry for them yet.  Or am I misunderstanding what you're saying?

 

 ..Al

My suggestion is keep the stella.pro process for existing carts, future 2600, and add the option to check the 7800 dump for the header data so that it can configure the emulator without need of the stella.pro database.  I would guess that initial updates will be limited to the database, but if there is a larger update to the 7800 emulator, to fix emulation issues, then that would be the time to add A78 header support.  

  • Like 1
Link to comment
Share on other sites

12 hours ago, Ben from Plaion said:

Ah, yes. I should of added that indeed some carts I tried at first wouldn't boot or would load garbled. But once the cartridge contacts were cleaned and game booted I didn't have any further issues and never have did I experience any in game crashes.

 

 

I have seen a crash tonight. I was playing Berzerk (as badly as I ever do) and screen froze, part of it corrupted and the sound effects that were happening stuck as a buzzing sound.  Controller was not working, no switches on the console worked, Game Reset did not work I had to power it off. 

IMG20231117010357.jpg

  • Sad 1
Link to comment
Share on other sites

2 minutes ago, tep392 said:

My suggestion is keep the stella.pro process for existing carts, future 2600, and add the option to check the 7800 dump for the header data so that it can configure the emulator without need of the stella.pro database.  I would guess that initial updates will be limited to the database, but if there is a larger update to the 7800 emulator, to fix emulation issues, then that would be the time to add A78 header support.  

Just curious why you would only want to do this for 7800 games and not 2600 games?  Especially as the pace of releases for 2600 games is always going to outpace 7800 releases?  And just to be clear, the ProSystem emulator has it's own database of games that's stored in the ProSystem.dat file, it's not using the Stella.pro file. 

 

 ..Al

Link to comment
Share on other sites

Just now, Albert said:

Just curious why you would only want to do this for 7800 games and not 2600 games?  Especially as the pace of releases for 2600 games is always going to outpace 7800 releases?  And just to be clear, the ProSystem emulator has it's own database of games that's stored in the ProSystem.dat file, it's not using the Stella.pro file. 

 

 ..Al

I didn't say that I don't want to do it for the 2600.  I'm just guessing it might be more difficult to fit header data with the space constraints of 2600 carts.  I don't even know if the 2600 has an existing header format.  If not, it might not have to be as lengthy as the 7800 is.  If 2600 programmer are willing to develop a header and can fit it in their games, then they should go for it.

  • Like 1
Link to comment
Share on other sites

5 hours ago, Ben from Plaion said:

Yeah, Earlier in the year I managed to get a flux capacitor and neuralyzer on the blackmarket and put my foot down in the car, soon as I hit 88mph I was transported back to 1980 something, incredibly I was actually in Activisions office, David Crane was there with Garry Fisher, both were tinkering on their computers. I said I'm from the future and showed them my smartphone, Garry feinted at the sight of it, I then explained to David what was happening in 2023 with Atari 2600+, showed him footage of the 2600+ playing on a 75inch OLED, he was astounded. I said to him you know people actually develop fake overlays over that crisp display to mimic long obsolete CRT screens whilst pointing to his monitor.

 

He said in disbelief "Why the hell would people do that?"

 

With that I activated the neuralyzer and hot skipped it back to 2023 where I filed CRT overlays task into the "Maybe - if we can do it after launch" folder.

I'm sorry, but I am from the past, writing this in the future not knowing the past - but if it hasn't been acknowledged that this is a brilliant response to this query - maybe I should stay in the future.

  • Haha 1
Link to comment
Share on other sites

I take this opportunity to add that it would be great and much appreciated if @tep392 DK XM cartridges could work on 2600+. Many people could finally play with the POKEY sound on. Thank you.

 

 

"Regarding POKEY audio, most homebrews expect to address the chip at $450, which has become the defacto standard. The old Prosystem emulator only supports POKEY at $4000, as implemented with the Ballblazer cart.  Games that support TIA or POKEY and try to detect a physical POKEY will likely fail due to inaccurate emulation.  I remember looking at the Froggie code years ago and it would write to POKEY at both $450 and $4000, which is probably why it works, though the bad notes indicate the POKEY emulation needs improvement.

 

edit: I should add that I would be thrilled if the 2600+'s 7800 emulation supported POKEY at $450 because then all those Donkey Kong XM (no POKEY in cart) carts will finally work with sound.

edit2: Using all the updates made in JS7800 seems to be the solution."

 

 

  • Like 2
Link to comment
Share on other sites

2 hours ago, Albert said:
2 hours ago, tep392 said:

And what happens when Atari eventually stops making updates for the 2600+.  Any homebrews developed after that point will not be supported by the 2600+.  They way we have been doing it works fine because the old hardware is fixed.  I believe we need some standards going forward to support new and future hardware releases.  Constantly updating databases in firmware is less than ideal.

What you're proposing would need to be done for Stella as well...

Take it easy guys - no need to panic (yet).

 

46 years from now, some geek will make for the 2600+ a Super 2600 AtariMax Multicart + which will run every original cart even more perfectly and make 98,5% of later homebrews (46 years of them!!) to work too…

 

Just sit back and relax folks… its coming…

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

4 hours ago, Thomas Jentzsch said:

The Micro-USB(?) port and the recover button he found on the HDMImainboard are interesting for sure

They're probably very handy when a firmware update has gone wrong and for debugging.

Other interesting things I noticed is that there is a footprint for an micro SD card connector on the bottom and several debug headers.
Didn't see the dumper chip it's most likely on the otherside io board we didn't get to see. I'm very curious about that one.

image.thumb.png.70bbc37f20818a10d0d3dba691bec988.png

  • 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...