Jump to content
Thomas Jentzsch

Legacy versus ARM-based 2600 Game Development

Recommended Posts

1 hour ago, Thomas Jentzsch said:

Right. And I doubt they worked only 40 hours per week.

BITD 80-100 hour weeks were common for many of us when facing a deadline.  Work... eat... sleep... work....

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
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.)



 

Share this post


Link to post
Share on other sites

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 3

Share this post


Link to post
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 6
  • Thanks 1

Share this post


Link to post
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

Share this post


Link to post
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. 

Share this post


Link to post
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?

Share this post


Link to post
Share on other sites
22 minutes ago, splendidnut said:

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

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

Share this post


Link to post
Share on other sites
3 minutes ago, Thomas Jentzsch said:

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

Enhanced games?

Share this post


Link to post
Share on other sites
1 minute ago, hizzy said:

Enhanced games?

That could be anything, e.g. 128 bytes of extra RAM. How about "Cray games"? ;) Or "Atari 26000 games"?

 

Anyway, "ARM driven games" might make sense. 

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)
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

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

I can't remember ever mentioning the hardware specifics of a cart unless it had a marketing purpose.  There's no upside to this.

  • Like 1

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
Share on other sites
2 hours ago, splendidnut said:

Now, if I could just get off my butt and finish it...

👍

  • Like 1

Share this post


Link to post
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

Share this post


Link to post
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! 

  

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
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 :) 

 

Share this post


Link to post
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...