Jump to content
IGNORED

Legacy versus ARM-based 2600 Game Development


Thomas Jentzsch

Recommended Posts

1 hour ago, kisrael said:

But I know I pushed JoustPong to be more than it would have had it just been a "trophy" port of my basic JoustPong concept

JP has good playability. I won it and a t-shirt free from you back at a Philly Classic show in a competition. Too bad you had to change the name but not really a big deal!

  • Like 1
Link to comment
Share on other sites

3 hours ago, SpiceWare said:

 

Writing homebrew games is not a full time job, the time is comparable:

  • 2 years at a few hours per week ~= 300 hours
  • 2 months at 40 hours per week ~= 300 hours

 

 

Good point! I guess I was thinking more of having breathing room for feedback and iteration with regards to polishing.

Being able to post a WIP (like I see many devs here doing), having end users test it out for a while, gathering some feedback, making some changes and then repeating a few times has to be of benefit.  Even just the luxury of having some lulls on a project or being able to put your attention on other tasks for a while can give your brain some time to work through problems or consider new approaches.  Being in a crunch often just leads to releasing the minimum viable product (Pac-Man, E.T., etc.)



 

Link to comment
Share on other sites

  • 1 month later...

Great discussion - the vast majority of it above-board with lots to think about across the spectrum. 

I'm nobody - having said that, you are free to skip my humble opinions.

First off - huge thanks to the homebrew and hack programmers everywhere! What you do is amazing - I'm guessing nobody is making massive financial gains from any of this and your efforts to provide the community with wonderful new/updated forms of enjoyment doesn't go unnoticed - even by those of us who are usually silent.

I'm an emulator developer for the Nintendo DS/DSi. The little handheld is rock-solid engineering ... like Atari was 40 years ago :)  But it only has a small 67MHz ARM processor and as such the emulators tend to be highly tuned and optimized to run efficiently on that architecture. I imagine that's not totally dissimilar to 6502 assembly programming with or without the use of ARM assisted code. So I can appreciate the herculean effort it takes to polish these things and make them work (forgetting gameplay for a minute... it's a minor miracle to get a stable kernel that does what you want it to do from what I've seen). 

Now, to the topic at hand.  I'm conflicted.

On the one hand - who cares? Fun games are fun. Un-fun games are un-fun. Bankswitching schemes have been around a long time - and some are complex enough to have extra RAM plus some enhanced functionality (specially the DPC scheme used for Pitfall II).  Having said that, I'm in awe of the accomplishments of a number of homebrew games - some of them happen to be DPC+ carts... some are more traditional bank switching schemes.  Conversely, there are a number of games that are... well... not my cup of tea. Some of those happen to be DPC+ carts and some are more traditional bank switching schemes. So DPC+ doesn't make a great game - great (simple!) ideas plus talented programming plus hard work / debugging makes a great game. ARM isn't some magical wand to make that happen.

On the other hand... at some point I feel there is a line where we are no longer talking about the Atari 2600. If someone in 1977 duct taped a CRAY-1 super computer and wired it into the CART slot and it took over as much of the 2600 as was possible... is that still an Atari 2600?  I've read the arguments that as long as you're using the 6502 to process and the TIA to output and the RIOT to input... yeah, it's still an Atari 2600. But it does feel like "cheating" - though I'm not sure how best to define that or where the line is. It's like Congress take on Pornography ... you know it when you see it.

From my very little corner of the world... I'm the lead developer for 4 emulators for the Nintendo DS/DSi:  Stella-DS (2600 games), 5200-DS, 7800-DS and XEGS-DS (for the entire 8-bit library ... .ATR and .XEX only). 

On the 5200-DS... every game plays except Bosconian 128K which can't handle the speech.
On the 7800-DS... every game plays (a handful of 320/SuperCarts run slightly below 60FPS)

On the XEGS-DS... every game plays.

 

But on Stella-DS... every game plays except DPC+ carts (and, the music fetchers in DPC Pitfall II are not working). 

 

Mainly because the Nintendo DS ARM processor running at 67MHz struggles to emulate the Thumb processor while also emulating the 6502, TIA, RIOT chips (plus drawing to the dual screens of the DS, handling sound, input from buttons, etc).  When I detect a DPC+ ARM-assisted rom, I put up a little disclaimer as shown below. 

What does this have to do with the price of tea in China?  Nothing... except that from the cheap seats, the DPC+ stuff feels like half-an-order of magnitude more advanced than anything in the Atari 8-bit line just on a pure emulation point of view.  Would I have DPC+ support if I could manage the skill to get it working on this little handheld?  You bet. But I've also convinced myself that I'm emulating the Atari 2600 fairly well but I'm not emulating the DPC+ ARM Thumb... and so I consider the DPC+ stuff a "different world". 

Having said all that, I do enjoy the DPC+ stuff on my real 2600 (I've got 2 setup in the house ... both with Harmony Carts - non Encore editions).

Hope everyone is well - be kind to each other!

image.png.81426eefa24783365119e4d8409f0c6a.png

  • Like 4
Link to comment
Share on other sites

These days I think "cheating" is a highly loaded word that detracts from any discussion on the subject. I think it places an implicit and unfair judgement on the ethics of programmers of ARM-based games, which I think should be unwelcome in our hobby. So, even in quotes, I would like to see this word removed from the discussion.

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

@llabnip

 

ChaoticGrill is DPC+ without the need for ARM.  So you could probably get that working if you really wanted to.  You just need a way to detect that there's no custom ARM code, which would probably be a pain and not really worth it. 

 

You could probably also support bBasic DPC+ games... but then again, I'm guessing detection would be a pain.

 

ADDENDUM:

I probably should clarify that first statement lest my head get bit off.  ChaoticGrill is a DPC+ game that doesn't use CUSTOM ARM code as it only relies on the DPC+ driver.

  • Like 1
Link to comment
Share on other sites

4 minutes ago, Andrew Davie said:

These days I think "cheating" is a highly loaded word that detracts from any discussion on the subject. I think it places an implicit and unfair judgement on the ethics of programmers of ARM-based games, which I think should be unwelcome in our hobby. So, even in quotes, I would like to see this word removed from the discussion.

Apologies - the use of the word was not intended as a slight to you or the other amazing programmers working on games of any type — but I understand that it came off that way. I don't seem to have the rights to edit my post - so this apology will have to do in its stead. 

Link to comment
Share on other sites

22 minutes ago, Andrew Davie said:

These days I think "cheating" is a highly loaded word that detracts from any discussion on the subject. I think it places an implicit and unfair judgement on the ethics of programmers of ARM-based games, which I think should be unwelcome in our hobby. So, even in quotes, I would like to see this word removed from the discussion.

What would you suggest instead? What would be less negative and still describe what the term "cheating" means?

Link to comment
Share on other sites

46 minutes ago, Thomas Jentzsch said:

Detection should be easy, but I suppose the DPC+ driver uses ARM code.

Yeah, detection isn't a big deal. Easy enough to search for the 'DPC+' and/or 'LOADER' bytes in the binary, but I also employ the MD5 scheme that stella uses. Partially for better bankswitch detection and for special controllers, but also for the DS I also have to contend with limited screen resolution (192 vertical pixels which is almost ideal for NTSC games... except so few games adhere to that standard - even Atari's pack-in Combat is notoriously longer). So I keep some information for scaling and cropping - I don't mind a bit of sky or ground being cut off but scores and active playfield are sacred.  So I could just match the MD5s for games that only use the DPC+ bankswitching scheme but don't rely on any ARM code.  To be honest, I figured there were none of these... otherwise F4 or F4SC seems a more likely choice for the programmer. 

Anyway, I do have a preliminary DPC+ driver that implements the bank switching, random numbers, the fetchers, etc... but it stops short of being able to execute any code in "Thumbulator" mode.  

Again - I hope to get DPC+ stuff working someday - or at least leave it in a state where the next bright guy can tackle it... there aren't many of us who want to write emulators for 20 year old platforms (DS) to emulate a 40 year old platform (VCS).  That's the nichest of niches** :)  Anyway - all my stuff is open source (since it's all based on open source Stella code from 2005 and hand-tweaked for the Nintendo architecture... with a few key backports of improved bankswitching schemes and critical bug fixes).


** For anyone wondering: why emulate Atari games on an outdated handheld?  There are more than 150 million of these DS units out there worldwide - and the DSi/DSi-XL are near the pinnacle of handheld gaming machines in terms of rock-solid design... and they have SD card slots where clever folks have hacked in to create custom menus and launchers for games... with the help of a dedicated community one can now obtain a $50 DSi-XL and play more than 15,000 classic 8-bit games from the 1970s and 1980s (PC Engine, NES, GG, SMS, Colecovision, Atari 2600/5200/7800/8-bits, etc). 

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

I would think detecting a DPC+ game using only the DPC+ ARM driver vs a game using Custom ARM code would be a bit difficult.  But, maybe I'm wrong?

 

 

ADDENDUM:

 

Really, I'm just wanting to see how many extra platforms will support ChaoticGrill.  That's my evil plan anyways.  Now, if I could just get off my butt and finish it...

  • Like 1
Link to comment
Share on other sites

53 minutes ago, llabnip said:

there aren't many of us who want to write emulators for 20 year old platforms (DS) to emulate a 40 year old platform (VCS).  That's the nichest of niches** :) 

And a major achievement. :thumbsup:

53 minutes ago, llabnip said:

Anyway - all my stuff is open source (since it's all based on open source Stella code from 2005 and hand-tweaked for the Nintendo architecture... with a few key backports of improved bankswitching schemes and critical bug fixes).

Like!

  • Like 1
Link to comment
Share on other sites

2 hours ago, splendidnut said:

You could probably also support bBasic DPC+ games... but then again, I'm guessing detection would be a pain.

 

bB DPC+ games use a small amount of custom ARM code, so would require thumb emulation to work.

 

1 hour ago, Thomas Jentzsch said:

Detection should be easy, but I suppose the DPC+ driver uses ARM code.

 

Stella does not use the ARM code of the DPC+ driver, so it should be possible for DS-Stella to emulate ChaoticGrill.  I would start with the DPCplus demo in the Harmony DPC+ programming topic.

  • Like 2
Link to comment
Share on other sites

20 hours ago, SpiceWare said:

bB DPC+ games use a small amount of custom ARM code, so would require thumb emulation to work.

 

If anyone would like to review that code look for bB/includes/custom/main.c in your bB installation. It handles:

  • pfvline
  • pfhline
  • pfpixel
  • zero-fill
  • sprite collision check
  • pfread
  • pfclear
  • pfscroll
  • sprite flicker logic
Link to comment
Share on other sites

20 hours ago, Andrew Davie said:

These days I think "cheating" is a highly loaded word that detracts from any discussion on the subject. I think it places an implicit and unfair judgement on the ethics of programmers of ARM-based games, which I think should be unwelcome in our hobby. So, even in quotes, I would like to see this word removed from the discussion.

There is nothing unethical about using a 32-bit Computer in the cartridge.

 

Marketing the technology as being like Pitfall II isn't cheating but it is marketing Hyperbole that can invite unfair comparisons with the games using Pitfall II contemporary technology. The VGC's review of Super Cobra (grade F) and the ARM remake (A+) is a good example comparing apples to oranges.  

 

People who lived through the era tend to be more tech savvy about comparisons. There are considerable differences in comparing 4K to 16K or 16K to 32K games even when they are on the same 8-bit platform! 

  

Link to comment
Share on other sites

  • 3 weeks later...

Years ago we also had a small discussion among Italian fans on how to identify "cheating" in games developments.
The epilogue, widely shared by the vast majority of all of us (including myself, and I support it, absolutely!) was:
 

>>>>> IT IS NOT CHEATING WHEN A GAME is able to RUN ON THE ORIGINAL MACHINE, as it was conceived from the beginning <<<<<

In other words: 

 

> including enhancement processors inside the cartridges (for example the ARM-based DPC+ or -other o.t.- the SFX of some SNES cartridges) IS NOT CHEATING; 

> internal co-processors or hardware modifications to the machine = CHEATING; 

> memory expansions are valid only if if the methodology of addition is conceived in origin (-ot- example: Commodore Amiga 256-> 512-> 768-> 1024-> and so other, MB). 

To connect this thread with that of the "Movie Cart", it can be said that it is designed to read A/V files appropriately created and present in a cartridge through the VCS hardware itself. This IS NOT cheating.
It would remain to evaluate an hypotetic device similar to a "superimposer" able to mix the images generated by a FMVplayer installed inside a "supercartridge" with those generated by the VCS, which would also have the task of controlling the execution of these clips by means of appropriate commands set through the usual Joystick and button controllers. 
All this would make possible conversions from laserdisc-based games such as the AmericanLaserGames series, FireFox, Astron Belt... not to mention the various Dragon's Lair, Space Ace and so on ;) . Also the display interface system would be ideologically complex: audio/video outputs of the VCS should first be connected to the supercartridge and then other A/V outputs would start from this last and have to be connected to the TV. 

Link to comment
Share on other sites

On 7/20/2021 at 6:17 PM, orange808 said:

Well, if you can say cheating, I can say pretentious.

 

1 hour ago, macdlsa said:

internal co-processors or hardware modifications to the machine = CHEATING

I don't think either is cheating but I think we can agree it's not retro development when the gameloop is running on a 32-bit processor. 

 

I think the Atari 800 modified with an internal 6809 CPU is still very retro, but it's hard to find compatible software.

 

A Pitfall II EPROM Sara board would be an awesome development tool for seeing how far David Cranes DPC chip could be pushed using just retro technology, anyone have one they want to sell or lend me? I'll explore it and write some cool games :) 

 

Link to comment
Share on other sites

  • 5 months later...

After all this this discussion, my humble conclusion is:

I think most of us work with Atari games because is something that for some reason we enjoying doing, being because we consider an art, a challenge, because of the community or for reasons we cannot explain rationally...

It is impossible to everybody agree where a line should be draw, if DPC+ is considering "cheating", if should be another category on ZPH, etc...

To give another example, my game is 4KB, but somebody might say am cheating by using git version control, Stella to run and debug the game, and having access to the internet and the community. Is there even a line?

Since is impossible to draw a line, my suggestion is to always this information clear, this make some accomplishments even more awesome, but will not eclipse any games that use extra features. Like when watching a demo from the demo scene, you might just watch the art and the music, but is even more interesting if you know a little bit about the hardware, know the conditions the demo is running, and you can be truly amazed by the technical wizardry that is going on.

@ZeroPage Homebrew awards, this is a small suggestion, It would be nice in the voting page, and in the show, to have this information as well, besides the actual size of the cartridge.

I don't think this should be enforced on the box, or rules should be dictated, but for public events, this is nice information that helps with the enjoyment. It also helps the community, making easer for a newcomer to weight the pros and cons of each technic, what him want to achieve and the challenges that will pursue and limitations he wants to self impose, when joining such an open and embracing community.

Edited by Octavio Pinho Bokel
  • Like 2
Link to comment
Share on other sites

"cheating" is a loaded word, and in this context it's being used to smuggle in implications of morality and zero-sum competition that don't belong. A person using it to describe some dev approach is either deliberately arguing in bad faith, or they're just incapable of arguing in good faith; either way, there's little point to getting sucked into a debate on whether or not something is cheating with them.

 

It used to be a common Usenet truism that if you referenced Nazi's or Adolf Hitler within a thread, you effectively ended discussion in the thread and lost the debate. I suggest that using the word "cheating" to describe some dev approach has the same effect, for similar reasons.

 

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