SeaGtGruff

You can already do that without making a hack-- in fact, that's probably how most people played the game when they couldn't figure out the @*!$&ing puzzles!

I don't think "superset" is the right term-- I guess it would be if not for the change to the hotspots. It's my understanding that with the original version of 3F, accessing any location from $00 through $3F would switch banks-- so any 3F games that switched ROM banks by accessing $00 through $3E wouldn't be a subset of 3E. I don't know whether any 3F games actually accessed $00 through $3E to switch banks, at least deliberately-- but it could certainly happen by accident if the programmer tried to access a TIA register and forgot to use an address higher than $3F.

You might want to consider using the 3E bank-switching method-- essentially the same as 3F, but writing to $3E lets you select one of up to 256 banks of 1K expansion RAM, so the maximum is 512K ROM and 256K RAM. Also, the bank-switching hotspots are limited to just $3E and $3F-- in the original 3F scheme, writing to any address from $00 to $3F triggered a switch. And I might be mistaken, but I think the original 3F scheme didn't actually go up to 512K ROM-- although I don't see why that would have been a limitation of the scheme itself, so it might have simply been that no cartridges using the 3F scheme ever went past a certain amount of ROM for monetary reasons. And of course if you do decide to use the 3E scheme, you don't need to use 512K of ROM and 256K of RAM.

With the "fall through" technique where you're switching banks from within a switchable area-- which is the only way to do it if you're using bank-switching schemes that switch all 4K of the cartridge area-- it's usually best to put the bank-switching code at the same spot in all of the banks. That isn't as fast as switching from anywhere in the area, since-- depending on how you do it-- you must JMP or JSR or RTS to get to the where the bank-switching code is, which can also involve some preparation to set things up, and there's also the need to JMP or JSR or RTS from the bank-switching code to wherever the target routine is.

If you're writing your program in assembly, there's no switches to set-- just make sure the ROM image will be the desired size based on the ORG and RORG addresses in your code, and access the necessary bank-switching hot spots for the type of bank-switching you want to use. On an actual cart, the bank-switching is determined by the cart itself-- i.e., the ROM chip(s), the way the address lines of the cart are wired, etc.-- rather than anything to do with the program per se. Stella and other emulators will either need to be told what type of bank-switching to use with the ROM, or else will try to determine the appropriate bank-switching based on things like the ROM size and the way certain memory locations (i.e., possible bank-switching hot spots) are used/initialized. If you're programming in batari Basic, you'll need to set the romsize for the desired bank-switching, so the batari Basic compiler will know how to set the ORG/RORG addresses in the assembly code that's compiled from your batari Basic code, as well as how to declare the hot spots.

I haven't studied your code in depth, but the easiest way to solve this would be to add the following lines to your Setup code: LDA #1 STA VDELP0 This will have the result that writing to GRP0 won't change player0's graphics right away-- instead, the new graphics shape will be held "in reserve" and won't take effect until you write to GRP1, such that player0's new shape will appear at the same time that player1's new shape does. VDELP1 works similarly, but the other way around-- when you write to GRP1 the new data will be held "in reserve" and won't take effect until you write to GRP0. If you're writing a two-line kernel, you need to enable only one of these-- VDELP0 or VDELP1. But if you're using the "score trick" to display a "48-pixel sprite" then you need to enable both of them at the same time. If you enable VDELP0 (and disable VDELP1, which will be done automatically by the CLEAN_START macro), both players will be updated on the *second* line of your two-line kernel. If you instead want to update both of them on the *first* line of your kernel then you'll want to enable VDELP1 rather than VDELP0-- but this wouldn't be as simple of a solution, because then player1's sprite would be off from player0's by *2* lines instead of only 1, since the new value you write to GRP1 on the second line of your loop wouldn't take effect until you write to GRP0 during the *next* pass through the loop, if you follow me. As for positioning the sprites horizontally, you can do this once per frame during the vertical blanking period, not during your initial setup. For instance, you could put it after the vertical sync, right after you set the timer for the vertical blank interval.

Also, even if you figured out the answer yourself, it's probably still a good idea to post a description of what the problem was and what you did to fix it, since others might conceivably run into the same issue and your post might help them.

I guess he meant *legally*. I think some people have tried to sell babies on eBay or Craigslist, but that doesn't make it legal. And if it ain't legal to sell something, the "It's Not Legal To Sell That" police might come a-knockin' on your door.

This forum welcomes nooby questions!

(1) The simulation of gravity has to be programmed, so if you want only player0 to be affected by the simulated gravity then don't include the other sprites' movements in the program logic for the gravity. As far as how to program simulated gravity, I think there are some threads that discuss this, along with some source code. (2) You'll want to use collision detection to identify when player0 and player1 are colliding, then branch to a "game won" routine when they've collided. You might also want to detect when player0 and the playfield are colliding, then branch to a "game lost" or "spare life lost" routine when they've collided. (3) I'm not sure about this one, but if I remember correctly you need to be sure you're using the right version of the music utility software for the version of Visual Batari Basic that you're using.

Sometimes I double post, and sometimes I use multi-quote. I think there's something to be said for both practices, depending on the situation. If you're responding to two or three people and everything's pretty much related, then it makes sense to multi-quote. But if person A said one thing, person B said another thing unrelated to person A's comment (but still related to the thread), and person C said something unrelated to A or B, then multi-quoting seems a bit like standing in the middle of a party and spinning around in circles participating in three or more conversations simultaneously. What, if person A wants to respond to your reply to their post then they have to quote everything you quoted and commented on from B and C as well? A lot of people don't pare down whatever quoted post they're replying to, they just quote the entire thing-- no matter how small a portion of it they want to respond to-- then add a line of text as their response. Multi-quoting just makes you have to do more work chopping out the parts you don't want to respond to, and can also make it harder to follow the flow of a specific sub-conversation within a thread, because two-thirds of a post might be related to different sub-conversations.

Guys who propose to their girlfriends this way prefer it to have some sort of surprise factor, so ideally you wouldn't want it to just say "I love you, Jill! Will you marry me?" right off the bat. Instead, you'd want it to start out with something else, then suddenly pop up with the proposal. And if it's going to be done on the Atari 2600, it's got to have the obligatory rainbow screen. So you write the program, get a cart made, and arrange to have it delivered to the house while your girlfriend is there. You show her the cart-- which has your name on the label, of course-- excitedly tell her how you finally fulfilled your lifelong dream of creating an Atari game, and ask her to play it. The game itself is really lame-o-- maybe it's a standard shoot-the-aliens game but the alien ships are so slow and ginormous that there's no way you can miss them, or something like that. And the game graphics and sound are really crude, like something a 5-year-old kid might come up with. So you've convinced your girlfriend to play the game you wrote, and she's silently thinking to herself that it's got to be the most pathetic video game she's ever seen, while you're gushing on and on about how hard it was to make and isn't it the coolest game she's ever played, yadda yadda-- then after she's destroyed a certain number of alien ships or earned a certain score, the screen suddenly changes to the Atari rainbow display and the letters "I love you, Jill! Will you marry me?" scroll across the screen.

It sounds like there's a video game idea in there somewhere!

Yes, you can create your mazes by storing the appropriate byte values in the playfield's graphics memory. Note that you don't need to use a high-resolution mode for your mazes-- GRAPHICS 6 (ANTIC mode B) should work well for your mazes if there's only two colors in the playfield (foreground and background). And if you create a custom display list then you can mix graphics modes (e.g., so you can have a text bar for displaying a score), as well as repeat playfield rows such that those rows are "stretched" vertically (so you don't have as many bytes to fill when you need to draw the playfield).

It isn't just having to learn a given programming language-- the harder part is learning the technical details (graphics, sound, etc.) for each machine.

If Atari doesn't like you using the "SwordQuest" title, you could always call it "ScimitarSearch" or whatever.

Here's a link to Kevin Horton's updated document on bankswitching: http://blog.kevtris.org/blogfiles/Atari%202600%20Mappers.txt And here's a link to version 6 of his older document: http://stella.sourceforge.net/bankswitching-methods.pdf

The -f3 option creates a raw binary file without headers, as you've determined. According to the DASM help document, the -f1 option adds a 2-byte header to indicate the lo/hi address of the origin, followed by the data. The -f2 option will put one or more chunks of data in the output file, depending on the ORGs in the assembly code. Each chunk has two headers-- the first is the 2-byte lo/hi origin address and the second is a 2-byte lo/hi length-- followed by the data; then followed by the next chunk (address/length/data), then the next chunk, etc. The chunks don't need to be in order-- i.e., the ORG addresses don't need to be in ascending numerical order. As far as I know, there are no Atari 2600 emulators that can load and run ROM files that were created with the -f1 or -f2 options, and I don't know that there would be any advantage to doing so, since the ROM data would need to be expanded out to be the proper size (4K or a multiple of 4K) and (if pertinent) rearranged so the banks are in the proper order. The 2600's cartridge slot is fixed in the address space at $1000. However, since the 2600 uses a 6507 CPU, which has a reduced number of address pins (13 instead of 16), only 8K of memory can be addressed, and anything over 8K is seen as a "mirror" of the first 8K-- i.e., you can still use 16-bit addresses, but there are no address lines for the upper 3 bits of the address, so $2000-$3FFF is a mirror of $0000-$1FFF, $4000-$5FFF is a mirror, and so on. If you look at ROM file dumps of actual 2600 carts, you'll see that some programmers used $1000 for the cart's address, while others used $F000, or even other start addresses-- it can be $1000, $3000, $5000, $7000, $9000, $B000, $D000, or $F000. When bankswitching is used, it's common to give each 4K a different ORG address so it's easier for the programmer to tell from the address which bank is being addressed (although simply using a given address range doesn't cause bankswitching to occur). Since the 6502 has three jump vectors at $FFFA-$FFFB, $FFFC-$FFFD, and $FFFE-$FFFF, and since the last 6 bytes of a 2600's game ROM must contain those vectors (or at least the RESET vector), this implies that the 6507 sees the vectors as being at $FFFA-$FFFF, regardless of what the ORG address in the assembly file was, which is why some (or most) programmers like to use $F000 as the ORG address. When a cart is bankswitched, the banks must be organized in the correct order in the ROM-- assuming the bankswitching uses 4K banks, each 4K block in the ROM will be assumed to be the first bank, second bank, etc. Each bank can use whatever address range the programmer feels like-- i.e., the addresses that appear in the code (for the JMPs and JSRs, or in the three 6502 vectors) will get "rendered down" to the $1000-$1FFF range anyway, since the three highest address bits don't have any corresponding address lines on the 6507. The 2600 powers up in a random state, so normally there's no way to be sure which bank will be in memory at power up, hence each 4K bank has its own set of vectors at the end which tell the 6507 where to start executing the ROM from-- if the bank doesn't contain the program's "real" start-up code, then that bank's start-up code must switch banks to where the "real" start-up code is. Note that some bankswitching methods use banks that are smaller than 4K (usually 1K or 2K), in which case the last bank is usually frozen (not bankable) such that it's always located at $1800-$1FFF (if 2K banks are used), or at $1C00-$1FFF (if 1K banks are used), etc.-- it depends on how many bank areas the method uses. In that case the program still needs to specifically switch to the desired bank in the bankable area(s), but only one set of vectors are needed (in the frozen bank) and only one start-up routine. With a 2K cart, one of the cart's address pins is hardwired so that the 2K is seen as being at $F800-$FFFF (or $1800-$1FFF, $3800-$3FFF, etc.). In this case the uniquely-identifiable portion of the cart's address space is really $1000-$17FF and that address space is mirrored at $1800-$1FFF, $3000-$37FF, $3800-$3FFF, $5000-$57FF, $5800-$5FFF, etc.-- i.e., each 4K mirror is split into two 2K mirrors. If you search for Kevin Horton, you can find some documentation he put together to describe almost all of the known bankswitching methods-- he had an older document, but within the last year or so he created a newer one to add information about most of the newer bankswitching methods. Edit: Minor correction-- the 6502 LOOKS FOR three vectors at $FFFA-$FFFF (i.e., the vectors are of course in the program code, not in the 6502 itself).

There might still be some work left to do on improving or rewriting the TIA emulation in Stella. I'm sure Stephen would be ecstatic to get some help with that. I'm not a C/C+/C++/C# programmer, otherwise I'd help-- I've looked at the existing source and got lost pretty quickly, although that often happens when I look at other people's programs (or at my own from several years ago ).

Interesting. According to the DPCplus.h file, the DPC+ kernel uses a 32-bit LFSR for random numbers, so I guess the DPC+ version of rand could be called rand32.

No, rand never returns 0-- unless you set it to 0, which breaks it (i.e., it will always return 0). You can get a value of 0 in your results if you're using & or / with rand, because of the way the bits are being masked (by &) or shifted (by /)-- but rand itself won't be 0 (unless you 've broken it). On the other hand, rand16 can return 0. Edit: You can also get 0 if you're using other mathematical operations with rand. For example: rand - 1 will return 0 through 254. rand + 1 will return 0 through 255 except that 1 will be skipped rand * 2 will return 0 through 254 except the odd numbers will be skipped.

Yeah, I noticed that, although I didn't know what kind of cartridge it was.

That's right-- anything over 4K would require bankswitching.

That's a way to simplify the format of the data, but by itself it doesn't reduce the ROM space needed. If you want to know the most compact format you could use for the data within the source code, that would be with the HEX statement rather than the BYTE statement: HEX 005AFF7E3C ; no spaces or dollar signs needed, just nibbles of hex data HEX 00 5A FF 7E 3C ; although it's easier to read/understand if you space it out But with graphics data I think it makes more sense to put the data in binary form-- at least, if the graphics use 2 colors (foreground/background, or on/off)-- so I'd personally leave it in binary format.

Pics, or it didn't happen! Hmm, I wonder what game they're playing?