SeaGtGruff

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

No, the chopper can be facing any direction when it lands. 995150[/snapback] 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

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. 994753[/snapback] 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

Thanks. I don't understand this. What do you mean by "top"? ~$BFFF or ~$B000/$A000/$8000? 994557[/snapback] "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. Cartridge A (the left cartridge slot on an Atari 800) uses $A000 through $BFFF. The vectors and such are as follows: $BFFA and $BFFB -- 2-byte (lo/hi) pointer to start address of cartridge A. $BFFC -- 1-byte flag to indicate if cartridge A is present (0 = no, <>0 = yes). $BFFD -- 1-byte "option" flags: Bit 0 = boot from disk? (0 = no, 1 = yes). Bit 2 = start the cartridge? (0 = no, 1 = yes). Bit 7 = diagnostic cartridge? (0 = no, 1 = yes). $BFFE, $BFFF -- 2-byte (lo/hi) pointer to powerup/reset JMP address of cartridge A. Cartridge B (the right cartridge slot on an Atari 800) uses $8000 through $9FFF. The vectors and such are as follows: $9FFA and $9FFB -- 2-byte (lo/hi) pointer to start address of cartridge B. $9FFC -- 1-byte flag to indicate if cartridge B is present (0 = no, <>0 = yes). $9FFD -- 1-byte "option" flags: Bit 0 = boot from disk? (0 = no, 1 = yes). Bit 2 = start the cartridge? (0 = no, 1 = yes). Bit 7 = diagnostic cartridge? (0 = no, 1 = yes). $9FFE, $9FFF -- 2-byte (lo/hi) pointer to powerup/reset JMP address of cartridge B. On an Atari 800, if both cartridge slots contain cartridges, the right slot is checked first. On later machines with only one slot, a 16K cartridge will use $8000 through $BFFF, with the vectors and such being at $BFFA through $BFFF, as shown above for cartridge A. I think I maybe disagree with Rybags comment about a 7K program. I would put the start of the program at $A000 as usual, and just leave the 1K at the end of the cartridge blank, except of course for the vectors and such. But it's entirely up to how you want to organize things. For example, some programmers might want to put the subroutines first, and have the actual starting address of the program be somewhere else, like using $A000 through $A7FF for subroutines, and having the actual "powerup/reset" starting address of the program be located at $A800. Would you mind elaborating a little bit, please? Why would that be easier? Are you referring to development on actual hardware? I was planning to do most of the development with an emulator (Atari800win) and do some testing on actual hardware as required and near the end of development. Good idea? Bad idea? What do you guys do? 994557[/snapback] Sounds good to me! Michael Rideout

Very nice, thank you, Carsten! Michael Rideout

The Assembler Editor might not have it, or it might be called something else (I've never used that cartridge/program, so I don't know). In assemblers like DASM, "include" is a command that lets you include the text from other files inside of the assembly source code you're working on, something like this: include "D1:header.asm" include "D1:equates.asm" include "D1:iostuff.asm" include "D1:graphics.asm" include "D1:footer.asm" where the files named after the "include" keyword are text files on drive "D1" that each contain bits of code that you've saved because you want to be able to reuse them in your assembly programs. I have no idea if Assembler Editor has anything like that, but I would hope that it at least gives you a way to append or continue working on a program that you'd previously begun and had to save before you finished it. Michael Rideout

Some ideas: Use masking tape to combine two joysticks into a single hand-held input device that has two sticks and two buttons! Or, tape a keypad controller to a joystick, or a paddle to a joystick, etc. (You get the drift.) If you don't want to tape your controllers together (I sure wouldn't), then someone could design some special "frames" that the different controllers could be popped into to hold them in place beside each other, then pop them out when you don't need them to be combined into "super controllers." Hmm, I said they were ideas, not *good* ideas. Although frankly, I'd sure love to have a frame or whatever to hold two joysticks together while playing Raiders of the Lost Ark. Michael Rideout

Did you get rid of it yet? I bought a CC2 last year, and just recently bought a new refurbished computer that came with an SD card reader. (MMC cards will work in SD readers?) So now all I need is an MMC card, and a replacement power supply for my 7800 (hopefully that's all that's wrong with it). BTW, do all SD card readers accept MMC cards? I'm currently rather clueless when it comes to these card readers, or most hardware in general, but now I need to learn about these things. I'm not a complete idiot, just an incomplete idiot! Michael Rideout

Well, it isn't too complicated (it is a 2600 game, after all) - but it was an 8K 2600 game, so probably 8K won't be enough for the 8bit port. 993463[/snapback] Not necessarily. You have to remember that while the two machines are similar in some respects, they are extremely dissimilar in others. The 800 has lots of RAM, plus character modes, etc. Things that you had to use ROM for on the 2600, you can use RAM for on the 800, so you might need *less* than 8K ROM on the 800, rather than more. Michael Rideout

I've done a little bit of assembly on the 800, but mostly just small stuff (USR subroutines called from Atari BASIC, VBI/DLI routines, etc.) Certainly you can use DASM if that's what you already know best. I used to use LADS on my real Atari XE, but these days I would use DASM since that's what I use for the 2600. I don't know, but I'd be surprised if there aren't. Don't know if it's the sort of thing you're interested in, but I know I found some old "Boot Camp" columns online while searching for Atari-related information. And as far as graphics, you can try the online books at the Atari Archives. Yes, Mapping The Atari or a similar book should tell you what they're typically called. I recommend looking for an Atari 800 disassembler, it will have a file with all the addresses defined for you. The disassembler I just downloaded calls it "ATARI.EQU", but you can rename it to "ATARI.H", "ATARI800.H", or whatever. And you can certainly use it with DASM-- although depending on its original format, you might need to edit it to put it into the format that DASM likes. Here are links for a couple of Atari 800 disassemblers: http://members.aol.com/MacFalkner/atari/dassi/index_e.htm http://ourworld.compuserve.com/homepages/ebacher/ The AtariAge store sells 8K and 16K circuit boards, but I think you can go bigger than that if you need to? And "standard" depends on what you're trying to do. If you're doing something simple, 8K may be sufficient. Michael Rideout

What about adding the directory where DASM lives to the PATH variable? Or better yet, does OS X have desktop shortcuts that you can modify the properties for, like in Windows? (I've never used OS X, but I would assume that it does.) If so, you could edit the shortcut properties for DASM so it starts in the correct directory. Michael Rideout

I have ordered new PCBs and I think that I can start building new devices mid of January 992689[/snapback] Are you making just enough to fill the existing backorders, or do I have time to get on the list? Should we order it from the AtariAge store and pay now so we'll be sent one once they're ready, or how does that work? Michael Rideout

Crimson Editor is a free IDE ("integrated development environment"). IDEs are basically fancy text editors that can highlight the keywords of a programming language, can call a compiler to compile the source code you're working on, and can either run the compiled program (if it's an executable file) or open/run it with another program (e.g., an emulator). You can program in an IDE without having any syntax files for the language you're programming in, but the keywords won't be color-coded. Having a syntax file lets you benefit from the color-coding feature. If you're a programmer and are looking for a free IDE, you can check out Crimson Editor at http://www.crimsoneditor.com. I've only just discovered it myself-- I normally use Multi-Edit, which unfortunately is pretty expensive, but I wanted to get a good free IDE so I could document how to use it with batari BASIC. Right now I'm writing/compiling/running my bB programs using Crimson Editor, and I've made the syntax and "tool" files for working with bB in Crimson Editor. So, if you use Crimson Editor, and program in TurboBasic, you can use the syntax files that MrFish posted. But if you don't use Crimson Editor, or don't program in TurboBasic, then the files that MrFish posted won't do you any good. Michael Rideout

Thank you! That makes better sense now. Michael Rideout

*15* color registers? Which Atari 8-bit is that? I want one! Mine has only 9! A trick I use to help speed things up is to use immediate addressing for loading the colors (LDA #$xx, STA $xxxx, etc.). I use the VBI to get the colors for the first DLI from the table and move them into the DLI itself, at the appropriate memory addresses for each LDA instruction. Then each time the DLI executes it gets the colors for the next line and stores them in the DLI (after it's already updated the color registers of course), and increment the table index for the next DLI. This assumes that you're using a single DLI routine. If you're using many individual DLIs, you can store the colors in the DLIs rather than using a table per se-- that is, the color tables are spread out across the DLIs, as it were. Then you can use the VBI to change the colors in the "tables" whenever you need to. This type of self-modifying code lets you change the color registers a little quicker by using immediate addressing, but of course there's still a limit on how much you can get done per scan line. Michael Rideout

Check http://www.6502.org, they have an HTML document that shows the opcodes and how many cycles they use. Michael Rideout

Does anyone know what operating systems bB is available for? I mean, I know it's available for Windows, and the C source can be compiled for Unix and Linux. And if I remember correctly, a while back someone posted that they had ported it to the Mac OS (although I don't know if that port has been kept up to date). Are there any other ports that anyone knows about? Michael Rideout

That's a good point - I'll need to be careful where I locate the driver code. Anyway, here's the avox.bas source code: 989903[/snapback] Wow, I didn't realize you'd already written a routine yourself! So it shouldn't be difficult to put it into an "include" file. However, I do have a question about one thing... dim atarivox=a SWACNT=1 data speak 0, 170, 138, 192, 152, 128, 5, 170, 154, 187, 129, 7, 22, 4, 197, 255 end talkloop if speak[b]=255 then b=0 if joy0fire then b=1 if b<>0 then atarivox=speak[b]:b=b+1:gosub talk In the above snippet of code, you don't initialize b before you drop into the loop. I know that bB initializes page zero anyway, but it made me do a doubletake, and after looking at the code I'm wondering if it might be better to swap the first two lines of talkloop around: if joy0fire then b=1 if speak[b]=255 then b=0 if b<>0 then atarivox=speak[b]:b=b+1:gosub talk For example, I think that might work better in the following situation: data speak 0, 255 end Are there any situations in which swapping those two lines as shown above would cause a problem? Michael Rideout

But with one caveat: a branch that crosses a page boundary can cause the speech to become all garbled. 989825[/snapback] Thanks, supercat, I'll make a note of that; these sorts of things are good to know. Michael Rideout

The AtariVox driver pack should tell you everything you need to know. 989789[/snapback] Thank you! I don't know if I'll be able to do anything with it anytime soon-- which would be kind of tough to do, anyway, since I don't have an Atarivox, my 2600 was stolen many years ago, and my 7800 hasn't been able to turn on in years. I'm thinking of buying another 2600 (but I don't have a Cuttle Cart or Krokodile Kart), and/or buying a replacement power supply for the 7800 (which I do have a Cuttle Cart 2 for), so maybe one day soon I'll be able to buy an Atarivox and use it. Anyway, as I tried to say in another thread, some of the things that people are asking batari to add into bB can already be done in bB, by using inline assembly code or by writing custom "include" files. I mean, if it can be done in assembly, then it can be done in bB. So it would be a big help to batari if we would either learn how to do certain things ourselves with inline assembly or custom "include" files (which I realize is hard for some people, because assembly coding can be a bit mindblowing or intimidating to people who are used to BASIC), or if some of us could create custom "include" files that could be posted in this forum for everyone to use. That wouldn't be quite the same as having a simple bB command-- e.g., we'd have to say "gosub avox" or something like that-- but if someone could make an "include" file with the necessary routines, then it would be a lot easier for batari to add a new command into the bB compiler that calls those routines and passes them the necessary information, or however it works (I haven't read up on it yet). So, if someone who knows how could write an "include" for the Atarivox in a hurry, test it, make sure it works, and then send it to batari with explicit instructions and examples on how the routines are to be called, then he might be able to add it into bB for this next release-- or if not that soon, then maybe the one after that. After all (and I'm not trying to be pessimistic, just realistic), major update releases can tend to be a bit buggy, so version 1.1 may be coming out very soon after 1.0 as any bugs get fixed. I'm not trying to pressure batari or anyone into adding Atarivox support to bB, as I currently have no way to benefit from such support right now, anyway. I'm just trying to suggest a possible way that Atarivox support might be able to get added to bB more quickly, for those who would like to use the Atarivox in bB games. It sounds pretty cool (no pun intended), and someday I'd like to own one, be able to use it on a working 2600 or 7800, and program for it in any games that I write. Michael Rideout

VSYNC doesn't output any lines. You can call this "vertical sync pulse," but I think it's usually called just "vertical sync." When you turn this on (move a 2 to it), the Atari starts to send a vertical sync pulse to the TV or monitor. You leave it on for 3 scan lines (i.e., strobe WSYNC 3 times, or count cycles, or use the timer), then you turn it off (move a 0 to it). If you're crunched for time and need every cycle you can scrape up, you can perform other instructions while you're waiting for the 3 scan lines to finish. Again, VBLANK doesn't output any lines. I think this is usually called just "vertical blank," or "vertical blanking," but I prefer to call it "video blanking," because you can turn it on and off anywhere and anytime, even in the middle of a scan line, so I think "video blanking" is a more accurate description, whereas "vertical blanking" implies that it's used exclusively during the vertical blanking interval. It's true that that's the way most 2600 programmers use it (for the VBI only), since the 2600 handles the horizontal blanking interval automatically, but VBLANK can be used to lengthen the HBI, or even to draw on the screen in black (but the timing issues prevent that from being a very useful thing to do, except perhaps in static screen displays such as a title screen). Brief descriptions for the rest of the register names and opcodes are as follows: WSYNC - wait for horizontal sync By the way, I like to think of this in terms of a "carriage return/line feed" or "end of line" when I'm counting scan lines in a program. If you count cycles exactly, you can perform instructions all the way across the scan line and you won't need to use WSYNC-- like typing a paragraph and letting the words wraparound to the next lines automatically. But due to the timing differences that are caused by using branch instructions or crossing page boundaries, it's frequently necessary to use WSYNC to ensure that the instructions for the next line will line up exactly. NUSIZ0 - number and size of player 0 and missile 0 NUSIZ1 - number and size of player 1 and missile 1 COLUP0 - color (or hue) and luminance of player 0 and missile 0 COLUP1 - color (hue) and luminance of player 1 and missile 1 COLUPF - color (hue) and luminance of the playfield and the ball COLUBK - color (hue) and luminance of the background CTRLPF - control settings for the playfield, ball, and object priorities PF0 - the graphics register for playfield 0 PF1 - the graphics register for playfield 1 PF2 - the graphics register for playfield 2 RESP0 - reset the horizontal position of player 0 RESP1 - reset the horizontal position of player 1 RESM1 - reset the horizontal position of missile 1 AUDC0 - audio control 0 AUDC1 - audio control 1 AUDF0 - audio frequency 0 AUDF1 - audio frequency 1 AUDV0 - audio volume 0 AUDV1 - audio volume 1 GRP0 - the graphics register for player 0 GRP1 - the graphics register for player 1 ENAM1 - enable control for missile 1 HMP0 - horizontal movement register for player 0 HMP1 - horizontal movement register for player 1 HMM1 - horizontal movement register for missile 1 VDELP0 - vertical delay for player 0 Actually, it might be more correct to call this "video delay for player 0," because it doesn't delay player 0 for a scan line, it really delays player 0 until player 1 gets updated. VDELP1 - vertical delay for player 1 Again, it might be more correct to call this "video delay for player 1," because it really delays player 1 until player 0 gets updated. HMOVE - horizontal movement command HMCLR - horizontal movement registers clear CXCLR - collision registers clear CXM1P - collision detection between missile 1 and player 0 or player 1 CXP1FB - collision detection between player 1 and the playfield or ball CXM1FB - collision detection between missile 1 and the playfield or ball CXPPMM - collision detection between the players or the missiles INPT4 - input port 4 SWCHA - switches for port A SWCHB - switches for port B INTIM - inspect or interrogate (?) the timer (check the value in the timer) TIM8T - set the timer to 8 times the number of indicated cycles TIM64T - set the timer to 64 times the number of indicated cycles The preceding list of registers is incomplete, and the descriptions I've given them may be kind of funky (I tried to expand the abbreviations, e.g., "INspect TIMer," but I don't think I've ever seen a clear explanation of what some the abbreviations stand for). For detailed information about the various registers, see the "Stella Programmer's Guide," found here: http://atarihq.com/danb/files/stella.pdf Most of the following are 6502 opcodes: ADC - add with carry AND - logical and ASL - arithmetic shift left BCC - branch on carry clear BCS - branch on carry set BEQ - branch on equal BIT - test bits BMI - branch on minus BNE - branch on not equal BPL - branch on plus .byte - define a byte of data (an assembler instruction, not a 6502 opcode) CLC - clear carry flag CLD - clear decimal flag CMP - compare accumulator CPY - compare Y register DEC - decrement DEX - decrement X register EOR - exclusive or INC - increment INX - increment X register JMP - jump LDA - load accumulator LDX - load X register LDY - load Y register LSR - logical shift right NOP - no operation ORA - logical or accumulator ORG - origin (an assembler instruction, not a 6502 opcode) ROL - rotate left SBC - subtract with carry SEC - set carry flag SED - set decimal flag STA - store accumulator STX - store X register TAY - transfer accumulator to Y register TXA - transfer X register to accumulator You can find information on the 6502 opcodes here: http://www.6502.org/tutorials/ 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 6502_Opcodes.htm

What exactly is needed to add Atarivox support to a game? What programming does it require? I'm talking about in an assembly program, not in a bB program. Because if it can be done in assembly, then it can already be done in bB right now, just not with a simple bB command or two. What I'm wondering is if we could write an Avox routine and put it in a custom include file? How does Avox work? Can you point me to some documentation about how to program for it? I found the PDF for the SpeakJet, and I found an Atari 800 driver that someone wrote and posted, is that all I need to look at, or can anyone point me to some documentation and/or examples for using the Atarivox with the 2600? Thanks in advance. Michael Rideout

I'm wondering what we all think batari should call the next version of bB-- version 0.4, or version 1.0? Of course, the decision is his to make. But it sounds like this is going to be a major upgrade of bB, so maybe a jump to 1.0 would be more fitting? Michael Rideout

sometimes.True, but you can pick up a 7800 + PS + games for near that price 989393[/snapback] Actually, doesn't it say that "the power pack is no good"? So you'd still need to buy a replacement power supply for it. Michael Rideout