SeaGtGruff
-
Content Count
5,587 -
Joined
-
Last visited
-
Days Won
2
Posts posted by SeaGtGruff
-
-
There are multiple copies of the Atari System Reference Manual (BobDuHamel, 1987) around in the internet, and all have some text missing in
Chapter 15 Displaylist:
CHAPTER 15
DISPLAY LISTS
[some of this file was lost...]
chip also has a memory scan counter. This register scans the display
buffer for data to be interpreted and displayed. Once loaded, the
memory scan counter's 4 most significant bits are fixed. The result
is that the memory scan counter cannot cross a 4K memory boundary
(i.e. $AFFF to $B000) without being reloaded.
DISPLAY LIST INSTRUCTIONS
--------------
I have found the original text on some disks:
--------------
CHAPTER 15
DISPLAY LISTS
The program which runs the ANTIC chip is called the display list. Much
like a microprocessor, the ANTIC chip has a program counter, called the
display list counter.
The display list counter is a 16 bit register. However, the six most
significant bits are semi-fixed. These bits can only be changed with a
jump instruction. The result of this is that the display list counter
cannot cross a 1K memory boundary (i.e. $A3FF to $A400) without using a
jump instruction.
The ANTIC chip finds the address of the display list in DLISTL [$D402
(54274)] and DLISTH [$D403 (54275)]. SDLSTL [$0230 (560)] and SDLSTH
[$0231 (561)] are the shadow registers for DLISTL and DLISTH.
The ANTIC chip also has a memory scan counter. This register scans the
display buffer for data to be interpreted and displayed. Once loaded, the
memory scan counter's 4 most significant bits are fixed. The result is
that the memory scan counter cannot cross a 4K memory boundary (i.e. $AFFF
to $B000) without being reloaded.
--------------
If you host some version of this manual, please update your version
Best regards
Carsten Strotmann
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
-
Well that sucks. Pretty darn short-sighted of Atari, when they could just as easily have wired it up as if each button were a paddle.Hmmm, or maybe that would have required an extra chip. Those controllers are wired up rather oddly, so that each 7800 button feeds into the paddle lines AND the trigger line.
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
-
I just got a new digital camera, and it came with a 16MB MMC card. I replaced it right away with a 512MB SD card, so I would like to offer the MMC for free for a CC2 user, preferrably one who doesn't have one yet. If you are not an established AA member, I may require confirmation that you actually own a CC2.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
-
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.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.
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.
2. Are there any very simple code samples floating around that can be compiled and run? I'm thinking something like K Israel's "thin red line" demo.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
-
It's a console app...If you're running it from the commandline, your current directory probably isn't in your Path variable (this is A Good Thing.) so you'll have to point your shell to the current directory.
cd /Applications/atari ./dasm file.s -f3 -ofile.a26
something like that. Just make sure you put a ./ in front of dasm.
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
-
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
-
-
*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
-
I found in www.atariarchives.org very interesting documents about Atari assembler. A lot of usefull appendices, but I need a table of cycles used per ASM 6502 command.In this way I could know exactly how much jiffies use every assembler command, very usefull for design critic routines.
Anyone could give me a help?
Thanks
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
-
I didn't actually use the driver pack, since I had already written a serial driver for the 2600 for the cart dumper utility. Though if I support the serial EEPROM, I will need it.The code that says "batari basic" was written totally in bB and could easily be adapted to say other things. The final version will probably be a little easier than this (maybe something that will translate the escape codes for you, and maybe talk automatically without needing to set up data tables and send them one char at a time.)
I did not, and probably won't need to spend much time on this, so people needn't worry that I will leave out "more important" features in favor of this. As you can see, there's really nothing to it.
But with one caveat: a branch that crosses a page boundary can cause the speech to become all garbled.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:
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
-
The AtariVox driver pack should tell you everything you need to know.But with one caveat: a branch that crosses a page boundary can cause the speech to become all garbled.
Thanks, supercat, I'll make a note of that; these sorts of things are good to know.
Michael Rideout
-
or can anyone point me to some documentation and/or examples for using the Atarivox with the 2600?The AtariVox driver pack should tell you everything you need to know.
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 = vertical sync linesVSYNC 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.
VBLANK = vertical blank linesAgain, 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
-
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
-
With so many posts lately with people looking for a 7800 I figured someone namely me should post the link on where to find one at a reasonable price $15. The source Best Electronics as any long time member can tell you is a very honest firm.sometimes.True, but you can pick up a 7800 + PS + games for near that price
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
-
Copying and pasting the results would be fine with me. I just hope we'll be able to do the reverse. Paste some sprite code into the sprite editor and it will read it, flip it, and display it so you can edit it.
To be honest, I don't especially like the playfield editor that's in 2600IDE-- not because of the way it works, but because of the code it generates. It creates a series of pfpixel statements, and drawing a playfield by turning the individual pixels on or off with a series of pfpixel statements takes a lot of machine cycles and ROM. It would be better if the playfield editor created data statements for the playfield, similar to the way I drew the castle in the sample program I posted in another thread-- although that would also require the user to call a routine for moving the resulting data into the playfield's RAM locations, flipping the bytes that need to be flipped, as in my sample program. Depending on the screen (i.e., how many pixels are to be turned on, and how they're positioned relative to each other), moving 48 bytes into playfield RAM can be a much quicker way to draw the playfield, and might require less ROM as well. But for some playfields, it might be quicker to use pfpixel, pfhline, and pfvline to draw the screen-- assuming that the playfield is already cleared. If the playfield needs to be cleared each time anyway, then the bytes approach is probably better anyway as far as speed, but might take up more ROM than using just a few pfpixel, pfhline, and pfvline statements.If we could have a smarter playfield editor, that would also be great. Maybe the user could select between the two types of results. One option would use data statements and the other would use pfpixel, pfhline, and pfvline. The user could determine which one is best for each task.
I played around with Crimson Editor last night, and it works great-- very easy to use, and easy to add user-defined tools to the menu.
I had the terminology wrong. The user-defined macros are for recording and replaying a series of keystrokes-- which is also useful; e.g., you could create a macro for something like "if joy0fire then", and you could use the macro to type that out for you everytime you needed to check the fire button in your program.
It's easy to customize Crimson Editor as far as adding new languages or changing the user preferences. I set up batari BASIC for the ".bB" extension, since ".bas" is already defined for Visual Basic, but the users can easily change the extension to something else, like ".26b", or even redefine the ".bas" extension to be used for batari BASIC if they won't ever use Crimson Editor for Visual Basic programming.
I added "batari BASIC Files" to the file types, and defined the known extensions for it as "*.bB;*.26b;*.bas", so if you're browsing a directory for bB files, any programs with those three extensions will show up in the files listing-- but again, the user can change that if desired.
In fact, you don't need to define a language at all, you can just write bB programs without setting anything up. The main advantage of defining a new language is that it allows Crimson Editor to highlight all the keywords for that language in different colors, plus the ability to display just the files of that language type in a file listing.
I set up two user-defined tools-- "Compile bB Program" (it just calls the compile batch and shows the results of the compile in an output window), and "Run bB Program in z26" (it just invokes z26 with the name of the compiled program). The user can change that to use Stella or some other emulator instead. And it's easy to modify the command to use any switches desired, so there could be multiple tools for running a program-- e.g., one to run a standard 2k or 4k ROM, another to run a 16k ROM that uses M-Network bankswitching, another to run ROMs that use Atari bankswitching, etc.
Since the text output from a program can be captured and displayed in the output window, if someone were to write a program for creating or editing playfields, and output the necessary statements (data, pfpixel, pfhline, or pfvline), then the output could be shown in Crimson Editor's output window, and could be cut and pasted into the bB program. I'm not up to writing a tool like that right now, but if no one else can do it, then I might be able to write something in Visual Basic for playfield editing, player editing, or even color selection (i.e., click on a color in the palette display, and it returns the appropriate hexadecimal or decimal value to the output window). However, my first priority is to work on the tutorial and finally launch it, so I won't be attempting to write any tools like that until sometime in the future.
Michael Rideout
-
Does this mean we would lose the sprite and playfield editors? I like how we can save and load images. I just wish we could highlight sprite code in our program, click a button and have it appear in the editor. Not being able to do that means that once you create something, you can never edit it. You have to redraw it. That's a waste of time and energy when a tool could instantly put the image in the editor for you. All the tool would have to do is read the highlighted numbers and flip the image so it's not upside-down in the editor.Later on, it would also be nice to have a tool that helps you create animations. You see all of the frames including the live result and you can also copy and paste from frame to frame. Kind of like the following page except it would be made for batari Basic and would include the features I mentioned:
http://alienbill.com/2600/playerpalnext.html
If Crimson Editor can have sprite and playfield editors, do you think it could turn the squares black or white as long as the mouse button is held down instead of requiring an actual click for each square? That would save a little time cut down on unnecessary repetitive stress on your hand and arm too.
Thanks.
I hadn't thought about that! The only potentially negative thing I'd seen so far about Crimson Editor is that it doesn't seem to have hex viewer/editor capabilities, which can be useful for viewing and hacking non-disassembled binary files, but which shouldn't be very much needed for actual bB and 6502 programming.
Crimson Editor is a general-purpose IDE (not specific to any target computer or game console or programming language), so it doesn't have built-in tools for creating and editing player and playfield graphics for the Atari 2600. It should be possible to create such editors as separate programs and call them with macros, but the resulting code would have to be cut-and-pasted into the bB program.
That's what's nice about an IDE like 2600IDE-- since it's tailor-made for a given language and machine, it can include only those menu functions which are needed, and can contain built-in tools that are fully-integrated into the IDE. On the other hand, a general-purpose IDE can have so many menu functions that the user is apt to be bewildered and intimidated, plus there are no built-in tools for doing specific things (like playfield editing) that are specific to a given machine.
To be honest, I don't especially like the playfield editor that's in 2600IDE-- not because of the way it works, but because of the code it generates. It creates a series of pfpixel statements, and drawing a playfield by turning the individual pixels on or off with a series of pfpixel statements takes a lot of machine cycles and ROM. It would be better if the playfield editor created data statements for the playfield, similar to the way I drew the castle in the sample program I posted in another thread-- although that would also require the user to call a routine for moving the resulting data into the playfield's RAM locations, flipping the bytes that need to be flipped, as in my sample program. Depending on the screen (i.e., how many pixels are to be turned on, and how they're positioned relative to each other), moving 48 bytes into playfield RAM can be a much quicker way to draw the playfield, and might require less ROM as well. But for some playfields, it might be quicker to use pfpixel, pfhline, and pfvline to draw the screen-- assuming that the playfield is already cleared. If the playfield needs to be cleared each time anyway, then the bytes approach is probably better anyway as far as speed, but might take up more ROM than using just a few pfpixel, pfhline, and pfvline statements.
I guess I could include information on both-- 2600IDE and Crimson Editor. But it would be simpler to cover just one editor in the tutorial, since I'd like to include screenshots where appropriate. I'll play around with Crimson Editor this weekend to see how well it works-- after all, I might want to use it myself whether or not it's the IDE that I end up covering in my tutorial. Actually, I prefer to use Multi-Edit, since it's what we use at work (so I'm very familiar with it), and I bought a copy for myself earlier this year. But Multi-Edit is probably way too expensive for most of the people who'll be reading my tutorial, whereas Crimson Editor is free.
Michael Rideout
-
I have the week off between Christmas and New Year's, so I plan to work on my bB tutorial and finally launch it. Since it's aimed at beginners, I'm including some instructions on how to use an IDE. I'd originally planned to use 2600IDE, but now I'm thinking about using a free full-featured IDE. After doing a brief search, I just downloaded Crimson Editor. I'm sure there are many other free IDEs to choose from, but this was one of the first ones I saw that looks fairly robust. Of course, now I have to build some custom files so Crimson Editor will recognize and be able to highlight the bB keywords, 6502 opcodes, and 2600 register names, as well as macros for compiling and running bB programs. This brings me to two questions before I invest much time in setting up the custom files for Crimson Editor:
(1) Does Crimson Editor meet with most everyone's approval? What I mean is, do any of you who are already programming in bB, or who are thinking of starting to program in bB, have any other free IDEs that you want to suggest I use instead of Crimson Editor? The main features I'm looking for are (a) color highlighting of the keywords and the ability to customize the keyword list for a new language; (b) full editing features, e.g., search and replace; © automatic backups and the ability to configure the backup feature; and (d) the ability to create macros for compiling programs and running programs. Anyone with strong feelings in favor of another IDE, or against Crimson Editor, should please speak up now. I just downloaded it and haven't really tested it yet (I can't very well try it out with bB until I customize it for bB, which I haven't done yet), so if anyone having familiarity with Crimson Editor knows of any glaring glitches or annoying shortcomings, please let me know.
(2) The file extensions I've been using with bB and 2600IDE-- .bas and .asm-- are already used for other languages. Of course, I could just trash the syntax files for those extensions, but it might be a good idea for us to come up with file extensions that are more unique to bB and 6502 assembly. I know that 2600IDE uses .26b as one of the recognized file extensions for bB source files, so I could set up custom files under that extension, or I could use something else, like .2600bas, .bB, etc. And .asm is a popular file extension among 6502 assembly programmers, but it's also used with other assembly languages, so we could come up with an extension for 6502 assembly source files in general, or even for Atari 2600 assembly source files in particular-- like .26a, .2600asm, etc. Does anyone want to offer comments or suggestions about this issue? Of course, people could create their own custom syntax files and macros, etc., but I'd like to set things up in advance as much as possible for the readers.
Thank you,
Michael Rideout
-
To create small playfield pixels, you can write a custom kernel, but it depends on where you want to store the data-- RAM or ROM. The neat thing about the existing bB kernel is that the playfield data is stored in RAM, so it makes it easier for a beginner to create a simple playfield display-- and that's adequate enough for games like Adventure and Superman, which used big blocks (many scan lines tall) for the playfield (castles, city skylines, mazes, etc.). If you want to get the data from a ROM table yourself as you're drawing the playfield, you can create a simple custom kernel in your program.
Ditto with multicolor sprites, you can store the shape and color data for each scan line (or pair of scan lines, whatever your vertical resolution is going to be) and move the data into the registers yourself in the kernel.
If you use the M-Network bankswitching ability that I made custom includes for a while back, you can store the data in the expanded RAM areas.
I didn't mean to sound bitchy or whatever, and my original lengthy post was not so much a rant (well, OK, it was sort of a rant) as an urging for everyone to get creative and try to do things with bB as it is, much the same way you would with assembly-- which, after all, doesn't have multicolor sprite commands and such, you have to write the code yourself. First off, bB's original documentation states that it's intended in part to be a stepping-stone to learning assembly programming. And as I see it, the most spectacular thing about bB isn't how easy it makes it to do certain things (like put a player on the screen), but rather its sheer flexibility and ability to be customized via user-written include files. My point is that we really aren't limited to bB's builtin commands or canned kernel, we can use it as a tool for writing fancy stuff of our own. That is, just because bB has a canned kernel doesn't mean we can't write kernels of our own.
Also, creative ideas are fine for coming up with cool solutions, but a big part of programming success (for me, at least, because I'm not a great programmer) is to be too stupid to know your own limits (so you aren't afraid to try something that everybody smarter than you insists is impossible), and to be too stubborn to know when to quit (so you keep trying until you either succeed, or accomplish something different from what you intended, but that's pretty cool in its own right)!
I know that bB is a wonderful programming platform in its own right, but a big part of what makes it so incredibly powerful is not any of the canned stuff that it gives us to work with, but rather the ability to build nifty tools (routines) of our own. The only way we'll ever be able to unlock the full potential of bB is to write our own kernels or routines with it, otherwise we're stuck with whatever canned kernels or routines batari is able to add to it.
Not that I mind batari's efforts to add new canned features and stuff-- I think he's doing a super spectacular job, and bB is pretty awesome even as it is now.
By the way, a while back I was trying to compare bB with BASIC (for my tutorial which I want to do), and my point was that bB isn't really BASIC, because it has only a few of BASIC's commands, it has many of its own commands that aren't in BASIC, some of its operators (logical operators) are more like C than BASIC, etc. (my real point being that since bB isn't BASIC, we can't expect to be able to type in a BASIC program listing and compile it with bB). But the other night I was searching for information on the original BASIC, and I discovered that BASIC originally had only 15 commands-- almost all of which are already available in bB (although a couple of them behave very differently)! So I guess bB really is a dialect of BASIC!
BASIC's original 15 commands, and whether or not bB has them:
LET yes
READ no
DATA yes (but behaves differently)
PRINT no (not yet, but maybe soon)
GOTO yes
IF-THEN yes
FOR yes
NEXT yes
END yes (but behaves differently)
STOP no
DEF no
GOSUB yes
RETURN yes
DIM yes (but behaves differently)
REM yes
Michael Rideout
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Newbie 8-bit assembly questions
in Atari 5200 / 8-bit Programming
Posted
"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.
Sounds good to me!
Michael Rideout