Jump to content
IGNORED

Boulder Dash®


Recommended Posts

The addition of RAM has made a complex display engine possible.

 

Forgive me if this is answered elsewhere, but what are the requirements for RAM/ROM? It would seem really neat to have a level-based game using the SuperCharger, with messages to "Load track 13" [for people with the "levels" on CD]. Unfortunately, I don't think Boulderdash would likely fit on that; unless the currently-active level is packed two characters per byte (I think there may be fewer than 17 character types, making this possible) I would think that the holding the current level alone would nearly fill up the SuperCharger, and that's before you start putting in other annoying things like code...

 

I know there are some cartridge platforms that add really huge amounts of memory to the Atari, but somehow that seems a little anachronistic. Yeah, it would be possible to design a game to use 128K of flash and 32K of RAM, but that wouldn't really seem like an "Atari" game.

 

OTOH, I've sometimes thought it would be amusing to build a "cartridge" which included a FIFO, a CPLD, and a modern embedded PC. The PC would generate instruction sequences in real-time for the 2600 to execute and the FIFO would feed them to the 2600. The 6507 wouldn't be doing a whole lot of processing--the only instructions would be LDA, LDX, and LDY (immediate), STA, STX, and STY (both zp and abs versions) TSX, TXS, NOP, and BIT (abs). The CPLD would include special logic for the latter instruction to capture the operand fetch when it appears on the bus. Conceptually, this would be somewhat like the way Pitfall II works, but in more extreme fashion.

Link to comment
Share on other sites

Hmmm... I smell a new overclocking project coming up...  ;)

866261[/snapback]

 

My 6507 is smoking, as it is. Any hotter and it would melt. Here is the same level, but with a few tweaks and using the alternate scroll system. As you can see, the shearing effect is dramatically reduced (4MB). So, deciding the scrolling method to use is not a simple one. On a level like this, the original scroll has clear advantages.

 

Cheers

A

866381[/snapback]

When you say "the alternate scroll system" do you mean the old or the new system? I do agree that the "notbd3jun2005pushlimit2.mpg" looks better than "notbd2jun2005pushedtolimit.mpg" in this case. Even if the latter is not a catastrophe as a worst case... remember that the original had delayed scrolling built-in as a feature! :)

 

Do you have an example of when the two engines perform the other way around? Which is the most common situation?

 

Regards,

Moderntimes99

Link to comment
Share on other sites

The addition of RAM has made a complex display engine possible.

 

I know there are some cartridge platforms that add really huge amounts of memory to the Atari, but somehow that seems a little anachronistic. Yeah, it would be possible to design a game to use 128K of flash and 32K of RAM, but that wouldn't really seem like an "Atari" game.

866890[/snapback]

Hmm... I can't really see why having 32K of RAM in the cartridge would disqualify it from being an Atari game...

 

Regards,

Moderntimes99

Link to comment
Share on other sites

OTOH, I've sometimes thought it would be amusing to build a "cartridge" which included a FIFO, a CPLD, and a modern embedded PC.  The PC would generate instruction sequences in real-time for the 2600 to execute and the FIFO would feed them to the 2600.  The 6507 wouldn't be doing a whole lot of processing--the only instructions would be LDA, LDX, and LDY (immediate), STA, STX, and STY (both zp and abs versions) TSX, TXS, NOP, and BIT (abs).

866890[/snapback]

Perhaps this could be taken a step further. With a embedded CPU, you can hijack the 6507's data bus. IIRC, the 6507's data bus is open collector, meaning that individual data lines can be driven low by an external device and the 6507 happily allows this. Therefore if the accumulator is set to $FF, you could write a kernel consisting entirely of STA's to TIA registers, and drive the appropriate bits low at just the right time, thus doing a separate store every three cycles. Think about it - 25 distinct TIA writes per scanline...though the timing might be hard to get right.

Link to comment
Share on other sites

Well, I'm going to display my complete and utter ignorance of programming here.

 

So you may not want young children in the room.

 

Have they left yet? Okay.

 

Anyway... as I said, I don't know anything about programming, although I've been reading the homebrew forums trying to understand the 2600 better. However, I do understand moving graphics around, having worked in the animation biz for the last decade.

 

So I was thinking about the scrolling, and had an idea on how to make it smoother. Of course, it may not be doable at all, but I figured I'd throw it out here anyway.

 

In the illustration below, let's say we're moving the background in figure "A" one tile to the left (which has the onscreen effect of panning to the right). The blue borders represent a fictitious "screen" just to show how things are moving. We're using tiles "1" and "2" for the background. Once we move, we end up at "B".

 

The way the engine works, as I understand it, is to move over that one tile, we have to jump the distance of one tile. So that inherently will make the scrolling somewhat jumpy. This is known in animation as strobing. Moving a background too great a distance in a given frame (although usually I'm dealing with video, but the principle is the same).

 

Since the engine must work that way, could there be an intermediate set of tiles used to give the illusion that the background isn't moving as far as it actually is?

 

The idea, is that tiles "3", "4" and "5" could be switched out during frame "C" (which would go between "A" and "B"). They're still full tiles, so you're not moving half-distances or half-tiles. They're just tiles made up of different halves of the other tiles. (If I remember correctly, the tiles can look like pretty much anything within their size limitations.) The big drawback of this, is that there would have to be a lot more tiles to make up the game, since you'd have to create both horizontal and vertical versions of all of the various halves of tiles. Either that, or come up with some way for the game to make the tiles out of smaller quarter or half-tiles as it needed them.

 

Again, this may be entirely unprogrammable, but I figured I'd throw it at the wall to see if it would stick. :)

 

bdscroll.jpg

Link to comment
Share on other sites

Hi there!

 

Again, this may be entirely unprogrammable, but I figured I'd throw it at the wall to see if it would stick. :)

867062[/snapback]

 

I think it would be programmable like that. (That's actually precisely how I think better scrolling should work for the Colecovision somehow...)

 

Well, there's a big problem with that though. Having only 8 different tiles for example, you can have 64 different combinations of pairs already, each requiring an extra "middle" tile. The # of required tiles will grow dramatically by the power of two here.

 

Also, IIRC, the scrolling in BD is just like that, so the mechanism is faithful to the original.

 

Greetings,

Manuel

Link to comment
Share on other sites

Well, there's a big problem with that though. Having only 8 different tiles for example, you can have 64 different combinations of pairs already, each requiring an extra "middle" tile. The # of required tiles will grow dramatically by the power of two here.

Actually that would be even far more tiles!

 

Imagine only two tiles which can be combined in both directions (vertical and horziontal). This gives 2^2=4 additonal patterns. PLUS both directions combined, which adds another 2^3=8 patterns. Total: 14 patterns

 

With just 8 tiles we would have: 8 + 8^2 + 8^3 = 584(!) patterns.

 

And another problem is, that that kind of scrolling would require way more CPU time than the current one, because now we can "recycle" patterns from the previous frame, which haven't been changed.

Link to comment
Share on other sites

And another problem is, that that kind of scrolling would require way more CPU time than the current one, because now we can "recycle" patterns from the previous frame, which haven't been changed.

867173[/snapback]

Is that right? I thought that at first, also, but I don't think it changes much - you still (only) have to change the tiles at the boundaries.

 

I'll attach some images...one is the initial position, the other two show that image scrolled to the right, with the changed tiles marked with a red 'X'.

 

One scrolled image is scrolled by a complete tile, the other is scrolled by half a tile. In both images, the number of changed tiles is the same - all the other tiles can be reused.

 

Does this make sense? Am I wrong?

post-6060-1117820017_thumb.jpg

post-6060-1117820104_thumb.jpg

post-6060-1117820111_thumb.jpg

Edited by vdub_bobby
Link to comment
Share on other sites

Is that right?  I thought that at first, also, but I don't think it changes much - you still (only) have to change the tiles at the boundaries.

Nope.

 

There are no solid blocks inside the boundaries. E.g when scrolling 10 boulders in a row, *each* boulder has to be moved 50%..

 

Now, if somebody finds a hardware trick how to move the playfield graphics, that would be cool. :)

Link to comment
Share on other sites

Is that right?  I thought that at first, also, but I don't think it changes much - you still (only) have to change the tiles at the boundaries.

Nope.

 

There are no solid blocks inside the boundaries. E.g when scrolling 10 boulders in a row, *each* boulder has to be moved 50%..

 

Now, if somebody finds a hardware trick how to move the playfield graphics, that would be cool. :)

867246[/snapback]

D'oh!

 

Me == :dunce:

 

 

:D

Link to comment
Share on other sites

as more often i watch the mpegs i realise that this is one of the best ever 2600 games... and even more if you know how hard it is to know that you dont have a vram or a tile system or fonts by hardware... and all done with 1,77 mhz minus display kernel...

 

ihmo it's easier to code a vic-20 version of boulderdash than this...

Link to comment
Share on other sites

oh... just a suggestion... what about putting below the playfield the amount of lives left? just simply because on the mpegs there is a kind of big border...so you don't know where the playfield ends... (i remember that someone mentioned that this is the capture card but on tv screen and real hardware it's nearly fullscreen?`)

 

oh...and another question...will it work in PAL? as you have less free CPU poweR?

Link to comment
Share on other sites

oh... just a suggestion... what about putting below the playfield the amount of lives left? just simply because on the mpegs there is a kind of big border...so you don't know where the playfield ends...

The problem is, everything that is displayed on screen costs a lot valuable CPU time.

 

oh...and another question...will it work in PAL? as you have less free CPU poweR?

It will work even better on PAL, since PAL games run at a lower framerate. If we e.g. display 200 lines on NTSC, we have 62 lines for calculations. If we display the same 200 lines on PAL, we have 112 lines for calculations.

Link to comment
Share on other sites

ok... so why not putting a simple "lda #15, sta wsync, sta colbk" at the end of the kernel? (ok...atari800 dli code...just putting a white rasterline at athe end... ;))

Since we have to disable that white background again, add:

  lda #0
 sta WSYNC
 sta COLUBK

So it would cost us about 1 scanline.

 

BTW: The C64 worked well without any screenborders.

Link to comment
Share on other sites

Hi Thomas!

 

Actually that would be even far more tiles!

 

Imagine only two tiles which can be combined in both directions (vertical and horziontal). This gives 2^2=4 additonal patterns. PLUS both directions combined, which adds another 2^3=8 patterns. Total: 14 patterns

 

With just 8 tiles we would have: 8 + 8^2 + 8^3 = 584(!) patterns.

867173[/snapback]

 

Sorry, I can't follow you here. You'd never do that for the vertical axxis, as the VCS has no scrolling problem here at all, not even with single scanline precission, no?

 

Greetings,

Manuel

Link to comment
Share on other sites

Sorry, I can't follow you here. You'd never do that for the vertical axxis, as the VCS has no scrolling problem here at all, not even with single scanline precission, no?

Of course you are right. Though currently the code isn't prepared for any smooth scrolling.

Link to comment
Share on other sites

Hi there!

 

Sorry, I can't follow you here. You'd never do that for the vertical axxis, as the VCS has no scrolling problem here at all, not even with single scanline precission, no?

Of course you are right. Though currently the code isn't prepared for any smooth scrolling.

867426[/snapback]

 

You'd need to add one more row of tiles. Then the first and the last rows line counters would need to be made adjustable. You'd then need to do the "hard" scrolling you do now only every "tileheigth"th frame and for the rest you'd just shift the display by tweaking the line counters accordingly.

 

Might feel weird though, If you'd mix huge horizontal jumps with vertical softscroll.

 

Greetings,

Manuel

Link to comment
Share on other sites

Hmm... I can't really see why having 32K of RAM in the cartridge would disqualify it from being an Atari game...

867029[/snapback]

 

Well, getting a 2600 to do cool stuff by ANY means is nothing to sneeze at, but the way I see it, if someone took one of today's better homebrew 4K or 8K carts back in time to 1984 and went to Atari or Activision with it, they'd be extremely interested. By contrast, if you went back in time with a game that required 128K of ROM and 32K of RAM, they'd wonder what you were smoking.

 

I'm sure different people have different goals, but to my mind part of the fun of 2600 coding is thinking about what would have been possible in 1984. Even if a game with 128K of code and 32K of data storage would have been theoretically possible back then, from a practical standpoint it would have been unmarketable.

Link to comment
Share on other sites

Hmm... I can't really see why having 32K of RAM in the cartridge would disqualify it from being an Atari game...

867029[/snapback]

 

Well, getting a 2600 to do cool stuff by ANY means is nothing to sneeze at, but the way I see it, if someone took one of today's better homebrew 4K or 8K carts back in time to 1984 and went to Atari or Activision with it, they'd be extremely interested. By contrast, if you went back in time with a game that required 128K of ROM and 32K of RAM, they'd wonder what you were smoking.

 

I'm sure different people have different goals, but to my mind part of the fun of 2600 coding is thinking about what would have been possible in 1984. Even if a game with 128K of code and 32K of data storage would have been theoretically possible back then, from a practical standpoint it would have been unmarketable.

867441[/snapback]

 

I have, to the best of my capabilities, already explored the 4K envelope. Qb was pretty good, and add to that the very interesting experiments in Chronocolour and the GreetingCart and you see that I have pushed the '2600 to do things in 4K that hadn't been done before.

 

By relaxing some of the constraints I am able to explore what else can be done with the '2600 hardware. Yes, programmers back then didn't have lots of ROM and lots of RAM. But that was then, and this is now. This is not about a 1984 commercial product -- and if you want to stick with what was possible then, feel free to do so. It is a challenging envelope -- but so much has already been done within it, that doing something dramatically new and exciting is unlikely.

 

Allowing myself the luxury of a bit of extra ROM and/or RAM (as the Supercharger did) opens up the field to development of interesting new techniques and games. Just because there are extra resources doesn't make the difficulties and challenge of programming any less difficult. In fact, the bankswitching scheme in some ways makes things more complicated (for example, you CANNOT access extra RAM from a switched-in ROM bank). Pitfall II added an entire separate sound processor chip -- was that cheating? It was certainly a commercial product and would have cost a fortune to develop. Does Thrust also meet with your disapproval because it would not have been commercially viable in 1984 -- as it needs 16K? Should we restrict ourselves to only 4K just because that's what most games published in the day used? Or is 6K or RAM via the Supercharger OK?

 

The bottom line is that the *consumer* neither knew nor cared what hardware was in the cartridge. You plug it into your Atari and it plays the game, and that game is compared 1:1 against the other games that you own. It is either fun or not. I believe that today's collectors don't care if it is a 4K game, or a 16K game, or even a 512K game.

 

If you think that I'm cheating, fine... you shouldn't be interested in what is happening in this forum and you clearly don't have anything constructive to add. Nitpicking about if this could be a commercial product 20 years ago is neither here nor there.

 

I am sharing the development of a game that I really like, on a platform that I really like. A game that has been discussed for years and considered pretty much impossible, at the very least extremely difficult, even with extra RAM and ROM. As such I am *really* pushing the capabilities of the machine as ultimately it is all done through the same TIA display chip/hardware with the same cycles/line. For me, that is what it is all about -- the challenge and fun. And development of this effort has been very interesting, and of course lots of fun.

 

The current (and I expect final) resource requirements of '2600 Boulder Dash are 16K RAM and 16K ROM. I see no reason why future games using this engine couldn't push that as high as the bankswitch scheme allows.

 

Cheers

A

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