Jump to content
IGNORED

How does Dig Dug work?


Recommended Posts

I'm brainstorming an idea but am not sure if it's possible on the 2600. Dig Dug suggests it might be but I can't figure out how.

 

Does anyone know how Dig Dug is able to store dynamic map data because it looks to me that they'd need more than 128 bytes to do it, particularly when you have other data to contend with, such as sprite positional data?

Link to comment
Share on other sites

Dig Dug's cartridge contains extra RAM on a SARA chip … someone more knowledgeable may be able to provide better details, but basically the first page of what should be ROM is instead split into a write range and a read range for the on-cartridge RAM, giving 128 extra bytes to work with (at the cost of a page of ROM). In Dig Dug's case they also use F6 bank-switching to page out the ROM regions.

 

If you bring up a Dig Dug cartridge image in Stella and press Alt+L for the frame rate/details overlay you'll see its type is shown as F6SC, the F6 is the bank-switching type and the SC stands for SARA Chip

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

16 hours ago, Tickled_Pink said:

Does anyone know how Dig Dug is able to store dynamic map data because it looks to me that they'd need more than 128 bytes to do it, particularly when you have other data to contend with, such as sprite positional data?

Thanks, now I'm curious. I hadn't looked that closely at Dig-Dug before.

 

Each "chunk" looks to take 12 scanlines (horizontally) and there are 11 vertical tunnel options. Wouldn't that account for 132 bits or ~17 bytes of RAM? That would leave, neglecting the stack, 111 bytes of the stock 128 bytes of RAM. That seems like enough left over RAM for game variables. I must be missing something. Anyone look closer into this to see why they used a SARA chip? Maybe my observation is off.

Link to comment
Share on other sites

35 minutes ago, DEBRO said:

Thanks, now I'm curious. I hadn't looked that closely at Dig-Dug before.

 

Each "chunk" looks to take 12 scanlines (horizontally) and there are 11 vertical tunnel options. Wouldn't that account for 132 bits or ~17 bytes of RAM? That would leave, neglecting the stack, 111 bytes of the stock 128 bytes of RAM. That seems like enough left over RAM for game variables. I must be missing something. Anyone look closer into this to see why they used a SARA chip? Maybe my observation is off.

Hmmm ... I never thought of doing things that way. Typically, you'd use an entire byte, much like an array in, say, BASIC. Bytes are easier and quicker to manipulate than bits, so I imagine that if you use bits, you're causing an additional overhead for yourself that you don't need when trying to draw the 2600 display.

Just refreshing my memory on how the Playfield works, it does look like it would make more sense to use bits rather than bytes.

Edited by Tickled_Pink
Link to comment
Share on other sites

@DEBRO
 

Just had a look at a video of the game in slo-mo. The map looks deceptive. It does look to me, however, that it's far higher resolution in terms of what can be dug out on-screen than it looks at first. It looks like each visible scan line is a line in memory. And it's the full 40 pixels across (minus the side borders).

 

So, each line is six bytes and the digging area is 40 lines deep, if you assume the bottom line is included in the map. That's 240 bytes. Even if the bottom line is just statically drawn, it's 234 bytes.

 

But you've given me a solution for my idea.

Edited by Tickled_Pink
Link to comment
Share on other sites

It looks like (at a quick glance) Dig Dug uses $f09d-$f0ec (= $f01d-$f06c write addresses) for the "bitmap" of the board. At least some of the remaining SARA RAM seems to be used for tracking the status or location of the various monsters, each of which may have a location, a facing/rotation, a "getting blown up" status, etc.

 

Looks like there's a partial disassembly here —

 

Screenshot from 2021-07-29 09-09-10.png

Link to comment
Share on other sites

On 7/28/2021 at 3:53 PM, Tickled_Pink said:

Bytes are easier and quicker to manipulate than bits, so I imagine that if you use bits, you're causing an additional overhead for yourself that you don't need when trying to draw the 2600 display.

Yup, more RAM means easier coding and faster code. To still get along with low RAM is part of the original challenge.

Link to comment
Share on other sites

On 7/29/2021 at 9:21 AM, brpocock@star-hope.org said:

It looks like (at a quick glance) Dig Dug uses $f09d-$f0ec (= $f01d-$f06c write addresses) for the "bitmap" of the board. At least some of the remaining SARA RAM seems to be used for tracking the status or location of the various monsters, each of which may have a location, a facing/rotation, a "getting blown up" status, etc.

 

Looks like there's a partial disassembly here —

 

Screenshot from 2021-07-29 09-09-10.png

 

Nows thats a blast from the past.

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