SeaGtGruff
-
Content Count
5,587 -
Joined
-
Last visited
-
Days Won
2
Posts posted by SeaGtGruff
-
-
most of the new homebrew games are not included in the Menu generator files of the Cuttle Card, so I thought it would be a good idea for programmers and players to put in a specific topic the technical infos (bankswitching configurations , startup code files, etc)I am talking about games like
aztec challenge
bounce
crazy balloon
incoming
ladybug
laserease
reflex
robot city
and 7800 games
frogger
q+bert
senso
tubes
and other ones
if anybody has found how to make them work with the cuttle card, it would help
I will do my share of attempts and post here any positive results
Great idea! I finally got my 7800 working again, and fired up my Cuttle Cart 2 for the first time last night, so I'll see how much I can contribute. (I presume that the Cuttle Cart and Cuttle Cart 2 work the same way as far as the menu files go.)
Michael Rideout
-
First you need to find the code where the joystick is being read for that purpose (moving the man), and then just change the value it's checking for. Alternately, you could swap the addresses for the subroutines it's branching to, but swapping the values it's checking for would probably be easiest. I don't know how to say it any simpler without seeing the actual code you're trying to change, since the way the code is written will determine what you'll need to do to change it.I just uses Distella on the dk.bin for Donkey Kong and looked for the joystick movement codes but couldn't locate them.
I disassembled Donkey Kong last night to look for the movement routines, but I didn't have time to unravel what's going on. I'll give it another stab this evening.
Michael Rideout
-
anyway, with regards to going through the breakout code to find out what each line does, where would i be best to look to find out what lines like these do:HMOVE = $2A
HMCLR = $2B
CXCLR = $2C
CXP0FB = $32
and
LF005: STY WSYNC
LDA ($D0),Y
AND #$0F
AND $EE
STA PF1
thanks in advance
The first group of lines are "equates" that define what and where specific memory locations are. This is really optional, as you can write assembly code that gives the memory address rather than using an equate, *BUT* equates make it a *LOT* easier to understand the code. The locations of those particular memory addresses are fixed, they never change (although they do have "mirrored" locations at other memory addresses that can also be used), and the names used (e.g., "HMOVE") have been agreed upon through long usage and convention, plus whatever they were called by the original designers and in the original documents about what the locations are and how they're used. If you want to know more about those lines, refer to the "Stella Programming Guide":
http://www.atarihq.com/danb/a2600.shtml
- then scroll down to "Technical Files" and it's the third link.
The second group of lines is more difficult to understand. First, you need to know about 6502 assembly code, you can start here:
http://www.6502.org/tutorials/6502opcodes.html
But it isn't as simple as just looking up what a given memory location and 6502 opcode does, because when you do a disassembly of a ROM image, Distella can convert some of the memory addresses to "English" using the standard equates, but it can't convert the memory addresses for subroutines and variables. You have to study the code carefully to see how specific memory addresses (variables) are being used-- for example, maybe one particular memory address is being used to store the vertical position of a given sprite-- and to figure out what the various subroutines are doing, and either add more equates and disassemble again using the additional equates, or edit the disassembly to add labels and comments, etc.
Note that there are already some commented disassemblies for some games.
I can make some intelligent guesses about the specific code lines you posted:
LF005: STY WSYNC LDA ($D0),Y AND #$0F AND $EE STA PF1
The first line starts with an address ("LF005", which is a label created by Distella to indicate that this line starts at address $F005), then a 6502 opcode ("STY", which means "store the value of the Y register"), and a memory address ("WSYNC", the equate name for the TIA register that tells the Atari 2600 to "wait for horizontal sync"). So what it's doing is storing the value of the Y register in the location that makes the Atari twiddle its thumbs until the RGB raster beams have reached the right edge of the playfield and need to be swept back to the left edge of the screen to begin drawing the next scan line. This is done to keep the graphics drawing for each scan line all lined up nice and neat.
The second line starts with an opcode ("LDA", meaning "load the accumulator"), then an indexed address ("($D0),Y", meaning "the address that's being pointed to by addresses $D0 and $D1, offset by the value in the Y register"). Based on what the fifth line says, this line is loading the graphics data that will be used for part of the playfield, and the Y index is probably holding either the scan line number or some similar value (e.g., a row number, where each row actually consists of several scan lines).
The third line starts with an opcode ("AND", meaning "perform a logical 'and' with the bits of the value in the accumulator"), then an immediate value ("#$0F", which is the hexadecimal value of the number 15). What this is doing is taking the value in the accumulator-- which is the playfield graphics data that was just loaded in the second line-- and ignoring or "zeroing" the left half of it.
The fourth line starts with an opcode ("AND" again), then an address ("$EE", which is a zero-page address located in the 128 bytes of RAM). What this is doing is taking the value in the accumulator-- the playfield graphics data that just had the left half "wiped out"-- and doing another logical 'and' with the value that's in address $EE.
The fifth line starts with an opcode ("STA", meaning "store the value of the accumulator"), then a memory address ("PF1", the equate name for the "playfield 1" register, which holds part of the playfield data). So this is taking the graphics data that was just processed in the preceding lines, and storing it in one of the playfield registers so that it appears on the screen.
Michael Rideout
-
Also, I've updated the HTML document by John Pickens to include the color clock counts for the Atari 2600. I hope that's okay with the powers that be (that HTML document has been reproduced on many web sites, so I figured it was probably okay). I'm attaching my slightly updated version to this post. The Atari 2600's color clock counts are in the column labeled "CLKS."
Michael Rideout
Looks good,
Aside from the very minor changes that I made-- mostly just adding the Atari 2600 color clock counts, and "fixing" the links so they still work even if the page is saved to your computer-- the entire document is by John Pickens, although the copy that's posted on the 6502.org web site says "Updated by Bruce Clark":
http://www.6502.org/tutorials/6502opcodes.html
Michael Rideout
-
To use your example, if the game checks to see if the joystick is pushed left, and if it is, then moves the man left, then you can change the code so the game is checking to see if the joystick is pushed right, and if it is, then move the man left.How would I accomplish this?
Thanks Tim
First you need to find the code where the joystick is being read for that purpose (moving the man), and then just change the value it's checking for. Alternately, you could swap the addresses for the subroutines it's branching to, but swapping the values it's checking for would probably be easiest. I don't know how to say it any simpler without seeing the actual code you're trying to change, since the way the code is written will determine what you'll need to do to change it.
Michael Rideout
-
You should get a copy of the Stella Programmer's Guide, which is available on the internet as a PDF document:
- bookmark this page
- go to Atari 2600
- go to Tech files
- go to Stella Programming Guide (PDF)
This document is also available from other web sites, and one web site even has a very nice, updated (spelling-error-corrected) HTML version of it. Just go to Google and search for "stella programmer's guide" (in quotes).
Anyway, the short answers to your questions are that SWCHA is stored at (or read from) address $0280, and no, the values cannot be "hacked" per se. Or rather, it depends on what you mean by "hacked" (see below).
You cannot "hack" an Atari game so that pushing the joystick in a given direction causes SWCHA to read differently than usual. However, you can certainly change the way the game responds to the different values. To use your example, if the game checks to see if the joystick is pushed left, and if it is, then moves the man left, then you can change the code so the game is checking to see if the joystick is pushed right, and if it is, then move the man left.
Actually, I'm glad you brought this up, because it reminds me of something I was thinking about the other week, namely right-handed and left-handed joysticks. As we all know, joysticks (and everything else in this world) are designed for people who are right-handed. Since I'm right-handed, I don't usually give this a second thought. I think I remember that some left-handed joysticks were made-- the fire button is on the other side of the stick-- but I don't know if they're still made or still available. I was thinking it might be interesting to add a setting in a game to let the player specify that he/she is left-handed, and then respond to the joystick differently. In other words, the player could rotate the joystick so that the button is in the upper right corner, and then the game would treat left as up, down as left, right as down, and up as right. The only problem is, the cable or wire would then be coming out of the "right" side of the joystick instead of out the back, so it would get in the way of the player's right hand.
Michael Rideout
-
I'm scrapping the code that I had for Thought Police (search the posts here or its in the [stella] archives) and going back to the drawing board. Originally it was supposed to be a game based on Logan's Run, or something similar, and the overwhelming consensus was that Logan's Run would be a better Adventure/Superman style game.How would it work? Just plot the game around the storyline of the book, and have a really large world map?
I'm interested in reviving the Logan's Run game, although I think I may end up going back to something similar to the first Thought Police mockup.
I was thinking that a good way to approach "Logan's Run" might be sort of like an adventure game, but not quite-- something along the lines of "Krull," in the sense of being a series of scenes or mini-games that you must get through to progress to the end of the story, perhaps picking up necessary items along the way.
I went out and bought "Logan's Run" on DVD to refresh my memory, but I haven't watched it yet. However, I would start by listing the key scenes that tell the story or move it along in a necessary fashion, and try to see which ones could be made into mini-games, or could otherwise be fit into a type of adventure scenario. But some scenes could be more to lend atmosphere than to contribute to attaining the end goal. For example, there could be a mini-game involving "riding the Carousel," or however they referred to it, where you play a person who must "swim" or climb through the air and reach the top, earning points based on how well you do (i.e., how fast you reach the top and explode as compared to the other people).
I might also throw in some humor. For example, when Logan and Jessica(?) are trying to escape the robot, and he tells them that he freezes people because he used to freeze the fish for food (to feed the city), but the fish stopped coming, I'd like to have a man go running across the screen yelling "Soylent Green is people! Soylent Green is people! Um, isn't this soundstage 5? Oh, sorry, wrong movie!"
Using that sort of approach, your "Thought Police" game could be included as one of the mini-games.
However, I believe the author of "Logan's Run" has been working to get the movie remade, and I have a feeling that he wouldn't approve of an unlicensed "Logan's Run" game being made.
Michael Rideout
-
I recently bought a "heavy sixer," serial number 74606G, made in Sunnyvale. The sticker is the original white one. Sorry, I don't have a scan or picture of it, and I'm not inclined to open it up unless something goes bad and I have to!
Michael Rideout
-
I don't know how hard it is to get a "heavy sixer," unless price is a factor. I just bought one online the other week, but it was a little pricey ($425 after shipping) because it was a "collector's special" that came with 51 boxed games.
This sucker seems heavier than I remember our old 2600 as being, which makes me wonder if we'd had a "light sixer." I always assumed it was a "heavy sixer." But come to think of it, based on the year we got it (I think it was at Christmas in 1980), I guess it must have been a "light sixer"! Too bad I let my older brother talk me into letting his kids borrow it, and someone (presumably one of the kids in their neighborhood) broke into their house and stole it!
Michael Rideout
-
Interesting! I actually started knocking around with a somewhat-similar game over the holidays, a bB conversion of the old "Blitz" game. I was inspired to do so by a version of "Blitz" that I saw someone else working on for the 2600, and I wanted to see what could be done using bB. However, I stopped working on "bB Blitz" (as I was calling it) out of deference to the other programmer.
My version was also partly influenced by "Blitz World Tour," a Flash game that I found and played on the internet. In "Blitz World Tour," there are bonus rounds where you have to bomb famous landmarks (e.g., the Statue of Liberty and the Taj Mahal). In "bB Blitz," I planned to have bonus rounds where you have to bomb Atari-related landmarks, like the "Fuji Towers" and the Yellow Castle.
Michael Rideout
-
Don't worry, you didn't see how stinky mine were, because I didn't post them!
I was going to use the font that was originally used for Atari cartridges-- it was ITC Bauhaus-- but when I looked for somewhere I could download it from, I found out that it's a commercial font and must be purchased/licensed, so I didn't mess with it.
Michael Rideout
-
Oh, I didn't realize that. "BASIC" is an acronym, or a word that's sort of like an abbreviation, made up of the first (or first few) letters in the (primary) individual words-- in this case, "Beginner's All-purpose Symbolic Instruction Code." Technically speaking, I believe acronyms are written with all letters capitalized-- like USA, NATO, TV, DNA, BASIC, COBOL, etc. However, I have been seeing BASIC spelled as "Basic" for many years now, as well as COBOL spelled as "Cobol." But I don't think that's proper, just as we don't write "Usa," or "Nato," or "Tv," etc. On the other hand, I see that "LASER" is also an acronym, yet I don't think I've ever seen it spelled that way; I always see it spelled "laser"! So I guess it's just a question of whichever is the most common form of usage.
Michael Rideout
-
-
If for some reason you can't reach John, or he no longer has it, he had sent me both the source and executable files, and I can email them to you if need be. I think John also sent them to other people who had PM-ed him, so *someone* may already have it up on the web. But it certainly wouldn't hurt for you to host it as well, especially since I don't think any future updates will ever be made for it (at least not by John).
Michael Rideout
-
Hello!I started working on a website last week as a place to put all of my Atari 2600 hacks - and expanded it to include all of the Atari 2600 related stuff I've downloaded since I joined AtariAge in 2002. There's still more I can add - but it's pretty complete now. It's very similar to Paul's MiniDig (and does include some of the same content), however I've expanded the content a bit - there are almost 100 disassemblies to download, and lots of other applications, documents, utilities, and programming info. As an aspiring programmer, it's been a lot of fun reading through everything as I was adding it to the site.
All of the content on the site was downloaded from here at AA, the stella archives, the original Dig or the MiniDig, but if you're the author of something that's posted on the site and you don't want it to be there, let me know and I'll remove it immediately. I've attempted to put links to the original locations of everything when possible.
The site link is www.bjars.com. It's on a free webhost that allows 1GB of transfer per month, hopefully that will be sufficient. BTW, Bjars is just the first initial of everyone in my family, I couldn't think of a good .com name that wasn't already registered
Enjoy!
Steve
Just a thought...
A "new" version of PCAE was just recently released, but it hasn't exactly been posted anywhere that I know of, so maybe you could host that latest PCAE release on your site?
Michael Rideout
-
-
That's true, of course.
But as I pointed out before, the effect actually looks very good, since the men look like they're climbing into the chopper on whichever side they're running from.Michael Rideout
-
-
I'm been working on a small project in bB and as part of it I need to randomly place some playfield pixels. The problem is instead of producing a more of less random placement of pixels a small number of pixels are being set repeatedly.I've produced a small sample program that demonstrates the problem. I guess one of two things are happening, either I've missed something obvious (quite possible) or the random number generator isn't well suited to this task. It seems like a replacement random number generator could be dropped into std_routines.asm if the random number generator is the problem but I'd like some feedback before I hunt around for a different generator.
I've attached the sample program with source and a screen shot.
dim frame_count=a frame_count=0 COLUBK = 0 : COLUPF = 90 rand = 44 game_loop drawscreen frame_count=frame_count+1 if frame_count=10 || frame_count=40 then gosub test_pf if frame_count=20 || frame_count=50 then AUDV0=0 if frame_count=60 then frame_count=0 goto game_loop test_pf AUDV0 = 2 : AUDC0 = 12 : AUDF0 = 4 x = rand : y = rand rem Limit X to Range 0 - 31 actually 1 - 31 as rand never returns 0 x = x & %00011111 rem Limit Y to Range 0 - 7 actually 1 - 17 as rand never returns 0 y = y & %00000111 pfpixel x y on return
I haven't analyzed your program listing, but you're correct-- the random number generator isn't really random, it always produces the same sequence of numbers, although the sequence can start with any number between 1 and 255. If you seed the random number generator with the same number every time (as you're doing with the statement "rand = 44"), you'll always get the same numbers in the same order. (By the way, I think this is how other BASICs work, too.) To get different results each time you run your program, you need to either not seed the random number generator at all, or else seed it with a random value ("rand = rand"). Note that seeding it with 0 will break it, but "rand" never returns a 0 anyway (unless you break it by seeding it with 0), so "rand = rand" will never seed it with 0.
Also, you might want to try using a different method for reducing the result to an acceptable value, because I don't think that masking the bits is the best way. The method I like to use it to subtract a given value until the result falls within the desired range. For example, to get a random value between 0 and 31:
x = rand : rem * x will be between 1 and 255 inclusive x = x - 1 : rem * now x is between 0 and 254 inclusive reduce_x if x > 31 then x = x - 32 : goto reduce_x rem * after exiting the loop, x will be between 0 and 31 inclusive
To understand why I think this is a better method for reducing x, consider what will happen if you want x to be between 0 and 3 inclusive. Masking x with %00000011 will produce 0 an inordinate number of times, because if you start with an x that has 0 in bit 0 and in bit 1, it will always reduce to 0. But if you keep subtracting until you get a value in the desired range (i.e., reducing x with a "mod" function), you won't get 0 an inordinate number of times, if you see what I mean.
We can even define a "mod" function in bB, as in the following example:
rem * test of a mod function rand = rand COLUBK = $04 scorecolor = $1A rand_loop x = rand : rem * x will be from 1 to 255 x = x - 1 : rem * now x is from 0 to 254 x = mod(x,32) : rem * now x should be from 0 to 31 score = 0 if x > 0 then for t = 1 to x : score = score + 1 : next display_loop drawscreen if joy0fire then goto rand_loop goto display_loop function mod rem * the second parameter should be > 0 temp3 = temp2 - 1 mod_loop if temp1 > temp3 then temp1 = temp1 - temp2 : goto mod_loop return temp1 end
In this example, the "mod" function will return a value in the desired range, as long as the second parameter is greater than 0. For example, "a = mod(b,16)" will return the mod 16 value of b, and store it in a:
If b = 0, a will be = 0.
If b = 1, a will be = 1.
If b = 2, a will be = 2.
If b = 3, a will be = 3.
If b = 4, a will be = 4.
If b = 5, a will be = 5.
If b = 6, a will be = 6.
If b = 7, a will be = 7.
If b = 8, a will be = 8.
If b = 9, a will be = 9.
If b = 10, a will be = 10.
If b = 11, a will be = 11.
If b = 12, a will be = 12.
If b = 13, a will be = 13.
If b = 14, a will be = 14.
If b = 15, a will be = 15.
If b = 16, a will be = 0.
If b = 17, a will be = 1.
If b = 18, a will be = 2.
If b = 19, a will be = 3.
If b = 20, a will be = 4.
etc.
Michael Rideout
-
But getting it this far was much harder than I thought it would be, so I don't know how much further I will be able to take this before release, which I want to do soon.That said, the next release will be designated 0.99 beta. I expect that there may be nasty bugs (as there were with 0.30) that will need fixing quickly. So what I hope people will do is play with 0.99b and see what they can do with it, while some brave soul improves the flicker engine for me. Or looks into the source and suggests a good algorithm that will work with the kernel.
That sounds like a plan!
Michael Rideout
-
If I remember correctly, it did the same thing in z26. I didn't report the behavior, because batari had said up front that there was still some work he needed to do on it, mostly cleanup, and that bad things could happen in certain situations. Anyway, it isn't an emulator-related problem, the kernel was still a little buggy when batari posted that demo.
Michael Rideout
-
I had never played Choplifter before yesterday, but last night I downloaded an Apple IIe emulator and the original Apple version of Choplifter, because I tend to think of the original versions of games as the "most authentic" versions.
Whenever I landed the chopper to pick up men, the chopper faced the viewer, no matter which way it was facing just before it landed. I don't know how any other versions of Choplifter are programmed, and I haven't played the Apple IIe version umpteen zillion times yet to see how it behaves in every conceivable situation, but that's the behavior I saw last night while I was playing it.
I thought it was very cool, actually, because if there were men running to the chopper from either side, it made it look like they were climbing into either side of the chopper. I figured the original programmer had made it do that by design.
Michael Rideout
-
Re: Choplifter--
I think you could do the chopper using 1 player and its missile, by changing the player's and/or missile's size and/or position from one scan line to the next. Here is a mockup of what one frame of the chopper could look like by doing that:
Obviously, this would mean having one table for the player graphics data, another table for the player size, another table for the player movement value, plus similar tables for the missile. And there would have to be different tables for just about every frame (tilt of the chopper, not to mention the rotation of the blades). But I think it could be doable, at least while the chopper is in the air. When the chopper lands to pick up men, it's facing toward the viewer and isn't as wide, so probably only one player would be needed there.
The tanks could be done in a similar fashion, possibly using just one player per tank, double-size pixels, just moving the shape one clock left or right from one scan line to the next to simulate a finer resolution and a wider sprite.
Michael Rideout
-
"Top" means the top of the cartridge ROM ($BFFF). I heartily recommend that you obtain "Mapping the Atari," or bookmark the online version (at atariarchives.com), to help you with these sorts of questions.I have it bookmarked; I don't have questions with the specific vectors, I just didn't know what he meant by "top." It seems rather arbitrary which end of the address space is the "top" and, since I'm not a pro programmer or anything, I didn't know which end is, by convention, the "top."
So thanks for answering that question.
In programming, "top" in this sense refers to the highest address, so "bottom" would be the lowest address (of the cartridge). And while that has nothing to do with programming style, two of the many styles of programming are "top-down" and "bottom-up" programming. Personally, I prefer "bottoms up" programming (not to be confused with "bottom-up"), which of course requires an open brewski.
Michael Rideout
But what's the thing in front of "bB" that looks like a cross between an "S" and an "l"? 
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
NTSC v. PAL detection?
in Atari 2600 Programming
Posted
I've also been planning a game (shelved for about a year now) that will be NTSC, PAL, and SECAM compatible. But I plan to use the difficulty switches for this. The left difficulty switch would control the number of scan lines (262 or 312), and the right difficulty switch would control the color palette (PAL vs. SECAM when there are 312 scan lines, and possibly NTSC color vs. black-and-white when there are 262 scan lines). The reason I chose the difficulty switches is because some 2600 models put them on the back of the unit, in which case they aren't easy to change in a hurry during a game-- and once they're set a certain way, the player wouldn't need or want to change them mid-game.
I plan to use the color/black-and-white switch for pausing/unpausing the game. It's really the only reasonable choice for a pause switch, since the other switches are either potentially on the back of the unit (i.e., difficulty switches), aren't designed to be flipped one way or the other (i.e., select and reset), or are hardwired for a specific purpose (i.e., power on/off).
SECAM 2600s have the color/black-and-white switch permanently "wired shut" in the black-and-white position? Bummer, that means anyone playing my game on a SECAM 2600 wouldn't be able to pause it.
Michael Rideout