Dark Chambers Source Code assembly help

[Ringman]

I'm trying to assemble this source code for Dark Chambers:

http://www.romhacking.net/documents/498/

 

Yet I'm a bit clueless on how the heck to assemble the files. I've tried using dasm, but I'm having no luck. I'm a total noob to 6502 assembly and dasm. The only assembly language I've had any real experience with up to this point has been MIPS, (noob assembly code, amiright?). The info on romhacking.net states: "Unknown what this code compiles with." So this may be a lost cause. Can anyone help me out here?

[SeaGtGruff]

Interesting. It looks like this will need to be converted to DASM or similar format before you try to assemble it. I think I *might* be able to create a DASM-compatible version, but no promises-- I won't know until I try.

[Ringman]

That would be extremely awesome, thanks. I'm just trying to modify the speed of the player. It looks like it will also modify the speed of the enemy judging by the code. This is is to finally finish an extremely old project I had started back years ago.

[SeaGtGruff]

That would be extremely awesome, thanks. I'm just trying to modify the speed of the player. It looks like it will also modify the speed of the enemy judging by the code. This is is to finally finish an extremely old project I had started back years ago.

I copied the five parts from the "disk 2" folder together-- the equates and the source for the four banks-- and I started going through the code to make it DASM-ready, but it will likely take a few days to finish it.

[Thomas Jentzsch]

Maybe I have such code on my hard disk already. I will check tonight.

[Ringman]

Awesome! Again, thanks guys. I'm slowly making my way through it and trying to figure out each component. It looks like there's lots of promise here.

[+Mitch]

I assume this is the same one Curt released a few years ago? http://atariage.com/forums/topic/121012-dark-chambers-source-code/

If so you can compile it with madmac. I used an Atari ST emulator to run madmac since I was too lazy to dig out my ST. Plus it compiles much faster on the emu.

 

Mitch

[SeaGtGruff]

I assume this is the same one Curt released a few years ago? http://atariage.com/...rs-source-code/

Yes, it's the same one. I'm working on making a DASM-ready version. It's interesting, because two of the banks are "out of order"-- they have the bank-switching code and vectors at the top, followed by the actual code (i.e., the ORGs are bass-ackwards). I've got the five source files combined into a single file, and rearranged those two banks in the proper order. Among other things, I'm planning to convert the graphics data to binary format so you can see the sprite graphics (I've already made some progress on that). I've also adjusted the ORGs and added RORGs so the code for the four banks will have unique addresses ($1000, $3000, $5000, and $7000), and change the hi/lo address tables to use #< and #> instead of /256 and &$FF. I did notice that the colors appear to be PAL. I'm actually learning a couple of things as I go-- for instance, I now understand the benefit of using SUBROUTINE so you can reuse a whole bunch of "temp" labels like .1, .2, .3, etc. Anyway, I hope to be done with it later this week.

Edited August 14, 2013 by SeaGtGruff

[Ringman]

Thanks for posting the older topic. I just read through that. So, as far as I understand this won't work on a 2600? Is that right? If that's the case, that's a real downer. I guess the only thing from there would be to disassemble the original binary. Then I could probably use Stella's debugger to figure things out from there. Thanks for the help so far, though.

 

I noticed the subroutines too. It acts somewhat like a switch statement, right?

 

I'm a little confused at how the SARA chip works, and how its being used here. It looks like its jumping to positions within the SARA chips memory to extract certain variable information. The player movement routines is of particular interest to me, and it looks like it uses a preset offset in the SARA chip + an offset for the player's vertical and horizontal positions, and loads that into the accumulator, does some addition and subtraction, then does it write that back to the SARA chip again?

 

My best guess so far, is that the player position is simply incremented or decremented by 1. To make the player move faster, I should just increment it by an arbitrary value? Or should I be hunting down the main game loop and look for some form of refresh rate?

 

If you don't know, that's cool too. This is my project after all, and I'll figure it out eventually even if I have to try messing with random stuff to do it.

 

Thanks again.

Edited August 14, 2013 by Ringman

[SeaGtGruff]

Thanks for posting the older topic. I just read through that. So, as far as I understand this won't work on a 2600? Is that right?

No, that's wrong. I think what it said in the earlier thread is that the 2600 version was programmed on the 7800. It's not unlike what we do today when we develop 2600 games on a Unix, Windows, or Mac computer. As I understand it, Atari had a development kit that ran on the 7800 and let their programmers write and compile games for the 2600.

 

I noticed the subroutines too. It acts somewhat like a switch statement, right?

DASM's SUBROUTINE directive defines a boundary within the assembly program. It clears any temporary labels so you can reuse them. That's my understanding, anyway. But I assume that any references to "SUBROUTINE" in the original source code are talking about actual subroutines.

 

I'm a little confused at how the SARA chip works, and how its being used here.

The SARA chip-- or Superchip-- contains an additional 128 bytes of RAM mapped into the first 256 bytes of the 4K cartridge memory space. Since the cartridge slot doesn't have a connection for the R/W line, the SARA chip uses the A7 line as a sort of R/W flag-- the A0-to-A6 lines select which of the 128 bytes of expansion RAM you want to access, and the A7 line tells the SARA chip whether you want to read from that byte or write to it. For example, you can write to the expansion RAM at $F000, but to read from that same byte you must read $F080 ($F000+$80). So the SARA chip is used just like the internal 128 bytes of RAM, but you must write to one set of addresses and read from another set.

 

My best guess so far, is that the player position is simply incremented or decremented by 1. To make the player move faster, I should just increment it by an arbitrary value? Or should I be hunting down the main game loop and look for some form of refresh rate?

I haven't tried to follow the game's logic yet; at the moment I'm just "converting" the code so you can assemble it with DASM, changing the sprite data to binary so you can see the shapes, etc. I'll take a closer look at the logic later to see if I can answer your question.

[Thomas Jentzsch]

Checked my HD. I only have the PAL version. But converting to NTSC should be no big problem.

DCPal.zip

[Ringman]

Thanks! I'll try to play around with it soon.

@SeaGtGruff: Do you still plan on finishing your version, or would you rather me just work with the PAL version Thomas posted?

[SeaGtGruff]

Thanks! I'll try to play around with it soon.

@SeaGtGruff: Do you still plan on finishing your version, or would you rather me just work with the PAL version Thomas posted?

I'm still going to finish my version. However, I decided to disassemble the NTSC version instead, and add in the comments and labels from the original source code. Plus, I had to take a break from it for several nights last week, so I didn't get it finished yet. Note, I could go ahead and post a preliminary disassembly without all the comments and labels, so you can get started on your hack.

[Ringman]

No rush at the moment. Take your time.

[Ringman]

Any word on this. I haven't really played around with this in a while, I've been really busy. However curiosity struck so I'm checking in.