Jump to content
IGNORED

Scramble - 2600


johnnywc

Recommended Posts

Fun fact, the coprocessor inside the Space Rocks cart is about 50x faster than the SNES. That would have been one expensive game cart in 1984! :grin:

 

 

I think it would be an interesting project to build a cart capable of running Scramble or other DPC+/ARM games using only period components. (Well beyond my capabilities, but interesting nonetheless.)

  • Like 1
Link to comment
Share on other sites

I think it would be an interesting project to build a cart capable of running Scramble or other DPC+/ARM games using only period components. (Well beyond my capabilities, but interesting nonetheless.)

Did ARM architechture even exist in the 80s? Might need to rewrite a lot of code... :lolblue:

 

EDIT: The ARM came out in 1985, so Space Rocks is fair game, but will have to compete against the juggernaut NES! :grin:

Link to comment
Share on other sites

Did they have 70MHz ARM processors then? Because I'm pretty sure that's the speed of Harmony and Melody..?

-

What I continue to find impressive is the low power consumption of ARM. Intel is a lost cause against these guys. Even back in the 90's ARM were doing chips running at 200+MHz while only consuming 1 or 2 watts at most!

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

Did they have 70MHz ARM processors then? Because I'm pretty sure that's the speed of Harmony and Melody..?

-

What I continue to find impressive is the low power consumption of ARM. Intel is a lost cause against these guys. Even back in the 90's ARM were doing chips running at 200+MHz while only consuming 1 or 2 watts at most!

I'm wondering if those new overclocked 2.5Ghz quad core ARM CPUs they are cramming in those Android boxes compare to a mobile quad core x86-64? My laptop is AMD quad core 2.3Ghz excluding turbo speeds.

 

I'm thinking perhaps the huge caches afforded to Intel/AMD processors may be contributing to the excess performance but also excess power consumption. It would be neat to see what one of these ARM juggernauts could really pull off when paired with high performance DDR3 and an OS that isn't walled off. You could throw in 32 parallel cores and it would still run cooler than today's top x86 desktop CPUs.

Link to comment
Share on other sites

It would be neat to see what one of these AMD juggernauts could really pull off when paired with high performance DDR3 and an OS that isn't walled off. You could throw in 32 parallel cores and it would still run cooler than today's top x86 desktop CPUs.

The x86 carry a lot of historic load with them. Internally they work like RISC CPU, while they externally they have to support 20 year old code. For sure this costs more energy than a modern design.

Link to comment
Share on other sites

The x86 carry a lot of historic load with them. Internally they work like RISC CPU, while they externally they have to support 20 year old code. For sure this costs more energy than a modern design.

Dangit, I meant ARM juggernaut, but it came out wrong... :P

 

Do ARM CPUs require more cycles than x86 to do the same work?

Link to comment
Share on other sites

  • 2 months later...

How many times more powerful than an Asteroids machine?

The ARM is 70Mhz. Divide that by whatever clock speed the Asteroids machine uses. Also gotta take into consideration instruction sets, cycles per instruction, and memory requirements. Needless to say the ARM beats anything that could have existed in the 80s.

 

Perhaps some guru could figure out what percentage of the ARM time is actually being utilized in Space Rocks. The Tournament Edition ROM could be used to test this since it pretty much maxes everything out in the Space Rocks engine.

Link to comment
Share on other sites

Heh.. you know.. when a homebrew of this quality comes out (it happens usually 2 times a year) I almost just want to download it. Then save it. Then take a drive to K-Mart or Toys'R'Us AND THEN PLAY IT. In order to simulate having to go to the store like in the 1970's.

 

Or simply not download it myself, make the wife download it onto SD card and then bring it home later or something - another version of "going to the store" or waiting for mommmy or grandma to bring home new games.

 

Yeh baby! Woot! Woot!

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

But isn't the ARM also bus stuffing during the display?

 

I'm not sure if Space Rocks is using it, but I don't think I'm using the bus stuffing technique in Scramble - I'm pretty sure the Harmony team is still working on that.

 

I am using the data fetchers and FASTFETCH which allows you to update a register in 5 cycles using an 'immediate mode' that automatically gets the next byte, but I don't think that's referred to as 'bus stuffing' (Darrell can correct me on that one). I think bus stuffing is when the ARM is actually changing the data going into the registers with only a 'store' (e.g. sty GRP0), meaning you don't actually load the data in your kernel and then store it to a register. That will allow you to update a register in 3 cycles which I'm sure will allow even more advanced games to be developed. :)

 

Anyway - back to Scramble. Yes we are working on finishing this up *very* soon, including packaging, and an announcement should be forthcoming!

 

Thanks,

John

  • Like 5
Link to comment
Share on other sites

But isn't the ARM also bus stuffing during the display?

Nope, the BUS Driver is still under development. The only thing using it so far are some demos to test it out. I've released a couple of the demos for people to try on their Harmony carts - one's in "Bus stuffing" like The Graduate., the other's in A Programming CHALLENGE. I don't expect us to have the BUS Driver finished until sometime next year as we're investigating ways to make the audio support better. I suspect the first games to use it will be Draconian and Frantic, which will both be reboot to use BUS.

 

 

Scramble, Space Rocks, and Stay Frosty 2 all use DPC+, which features data fetchers for faster data retrieval. These are like the ones found in the DPC coprocessor, used back in the day for Pitfall 2. DPC fetched data from ROM, DPC+ fetches data from RAM so it's much more flexible.

 

We also added a fast-fetch feature to DPC+ which decreases access to the datafetchers from 4 cycles to 2. For what that means, here's a comparison of the code that must run on every scanline if you want to display just 1 multicolored sprite.

 

Traditional code - 26 cycles per scanline:

   lda #SPRITEHEIGHT
   dcp SpriteTemp
   bcs DoDraw
   lda #0
   .byte $2C
DoDraw
   lda (GfxPtr),Y
   sta GRP0  ;+18 cycles
   lda (ColorPtr),y
   sta COLUP0 

Activision's DPC - 14 cycles per scanline:

   LDA DF0DATAW ; 4
   STA GRP0     ; 3
   LDA DF1DATA  ; 4
   STA COLUP0   ; 3

Harmony/Melody DPC+ - 10 cycles per scanline:

   LDA #<DF0DATAW ; 2
   STA GRP0       ; 3
   LDA #<DF1DATA  ; 2
   STA COLUP0     ; 3

BUS - 6 cycles per scanline:

   STY GRP0       ; 3
   STY COLUP0     ; 3

There's only 76 cycles per scanline, reducing how long it takes to update a sprite means you can make additional graphic updates one very scanline for a better looking game.

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