SeaGtGruff
-
Content Count
5,587 -
Joined
-
Last visited
-
Days Won
2
Posts posted by SeaGtGruff
-
-
I have a small program I wrote for the 2600 that displays all 128 colors at once, which I've previously posted in other forums/threads at AtariAge. And I now have a working 7800 again, with a Cuttle Cart 2, so I've taken several digital photos of my 7800 running the 128-palette display. Unfortunately, I couldn't seem to get a decent photo, so I didn't post any of them yet, but I'm going to try again tonight when I get home, and post a good one in this thread "for the record." Then we can compare the actual 7800 palette in the photo to the palette in the emulator.
Michael Rideout
Excellent. I would appreciate that Michael.
I can't seem to get a decent photo. I'm attaching one of the better ones, but it's too dark; on the TV screen, the colors were brighter. I tried to apply various types of adjustments to the photo (brightness/contrast, gamma correction, etc.), but none of them worked very well, so I'm just attaching the unmodified photo.
Michael Rideout
-
By the way, can anyone recommend a good disassembler? I'm using dis6502 1.9, but it doesn't seem to have all the features (menus and options) that are shown in the documentation for an earlier version. Part of my problem was getting the file into a format that would disassemble, since it's a raw binary file without headers, so I had to hack it to add the headers so it would even load into the disassembler. And the "dump" window doesn't show anything, so I can't tell the disassembler which bytes are data, and it tries to disassemble them. I've saved the listing and am now editing it in an IDE, but it would be nice if dis6502 would load raw binaries that have no headers, and let me edit the disassembly listing.I'm curious why you can't load raw files - this has been supported since 1.7. Also, what menu items/options are missing? Feel free to send me what you're trying to disassemble if you're still having this issue so I can see what it does in 2.0.
thanks
James
It may have been either an installation or operating system issue. The computer I was using at that time died a few months ago, and I'm now using a totally different computer. The older one was still running Windows 95 (!), and over the years I had installed several different versions of dis6502 on top of each other in the same directory. The computer I'm using now is running Windows XP, and I've installed dis6502 version 1.9-- and now version 2.0-- in their own directories. I just tried to load the same raw file that failed to load back in October, and it's working fine now (on this computer). I notice that the raw file opens in a pop-up window, so maybe Windows 95 had a problem with that, because I never got a pop-up window when I tried to load the raw file on my old Windows 95 computer.
As for the differences between the documentation and the actual menu options in the program, the documentation I'm looking at is for version 1.4, because I can't find any newer documentation. In the version 1.4 documentation, the menu bar has the following menus on it:
File - Select - Labels - Tools - Options - Help
In the version 1.9 program, the menus are as follows:
File - Labels - Tools - Options - Help
As you can see, the "Select" menu seems to have been done away with at some point between version 1.4 and version 1.9. And there are also some differences between the menus in these two versions-- in general, version 1.9 has additional selections, but in some cases it has fewer selections. So it would be great if the documentation were brought up to date by someone.
But my biggest problem was that I was having trouble getting things to work-- like loading a raw file, or telling dis6502 that a certain section of bytes are data rather than code so it wouldn't try to disassemble them. Those things seem to be working on this computer, so I'll try disassembling my USR routines again.
I'm looking forward to version 2.1, since version 2.0 is giving me the missing DLL message that's already been described in another thread.
By the way, I think it would be great to be able to disassemble Atari 2600 ROM images with dis6502. I suppose it already can, as long as the ROM image is loaded as a raw file, and the proper equates are used. I'll have to give that a try, too!
Michael Rideout
-
In respects to your above post, the Atari 800(5200) and the 2600 use the same palette, I would presume then the palette would also be valid for the 7800 (?)I have a small program I wrote for the 2600 that displays all 128 colors at once, which I've previously posted in other forums/threads at AtariAge. And I now have a working 7800 again, with a Cuttle Cart 2, so I've taken several digital photos of my 7800 running the 128-palette display. Unfortunately, I couldn't seem to get a decent photo, so I didn't post any of them yet, but I'm going to try again tonight when I get home, and post a good one in this thread "for the record." Then we can compare the actual 7800 palette in the photo to the palette in the emulator.
Michael Rideout
-
Okay, here's an updated version. All I did was add some more text to the help guide, and add some output messages. I did confirm that including spaces in the directory path or file name is okay, as long as you put quotes around it so the program understands that it's all one parameter. The new help guide, and an example of the new output messages, are shown below.
Michael Rideout
C:\Atari\2600\Distella>splitfileNothing to do!
Usage: SPLITFILE [<path>]<filename> [<size>]
Where: [<path>] is optional path (e.g., C:\Atari\2600\ROMs\)
<filename> is name of file to split (required)
[<size>] is optional size of output files (e.g., 4K)
Notes: <size> may be 1K, 2K, or 4K (case insensitive)
1K may be typed as 1, 1K, 1KB, 1024, or 1024B
2K may be typed as 2, 2K, 2KB, 2048, or 2048B
Anything else (including no size) will be read as 4096
Output files will be named file_#.ext
where 'file' is original filename,
'#' is number of output file,
and '.ext' is original extension
If path or filename contains spaces,
'\path\filename' must be in quotes
C:\Atari\2600\Distella>splitfile "..\ROMs\M-Network Burgertime.bin" 2Reading 16384 bytes in ..\ROMs\M-Network Burgertime.bin
Writing 2048 bytes to ..\ROMs\M-Network Burgertime_1.bin
Writing 2048 bytes to ..\ROMs\M-Network Burgertime_2.bin
Writing 2048 bytes to ..\ROMs\M-Network Burgertime_3.bin
Writing 2048 bytes to ..\ROMs\M-Network Burgertime_4.bin
Writing 2048 bytes to ..\ROMs\M-Network Burgertime_5.bin
Writing 2048 bytes to ..\ROMs\M-Network Burgertime_6.bin
Writing 2048 bytes to ..\ROMs\M-Network Burgertime_7.bin
Writing 2048 bytes to ..\ROMs\M-Network Burgertime_8.bin
All done!
C:\Atari\2600\ROMs>dir M-N*Volume in drive C has no label.
Volume Serial Number is xxxx-xxxx
Directory of C:\Atari\2600\ROMs
12/18/1999 05:23 PM 16,384 M-Network Burgertime.bin
02/15/2006 06:14 PM 2,048 M-Network Burgertime_1.bin
02/15/2006 06:14 PM 2,048 M-Network Burgertime_2.bin
02/15/2006 06:14 PM 2,048 M-Network Burgertime_3.bin
02/15/2006 06:14 PM 2,048 M-Network Burgertime_4.bin
02/15/2006 06:14 PM 2,048 M-Network Burgertime_5.bin
02/15/2006 06:14 PM 2,048 M-Network Burgertime_6.bin
02/15/2006 06:14 PM 2,048 M-Network Burgertime_7.bin
02/15/2006 06:14 PM 2,048 M-Network Burgertime_8.bin
9 File(s) 32,768 bytes
-
I had to totally rewrite it to be a true "command line" utility program, which is called "SplitFile." If you need help with it, you can just type "splitfile" at the command prompt and it will display a brief help guide, as so:Nothing to do!Usage: SPLITFILE [<path>]<filename> [<size>]
Where: [<path>] is optional path (e.g., C:\Atari\2600\ROMs\)
<filename> is name of file to split (required)
[<size>] is optional size of output files (e.g., 4K)
Notes: <size> may be 1K, 2K, or 4K (case insensitive)
1K may be typed as 1K, 1KB, 1024, or 1024B
2K may be typed as 2K, 2KB, 2048, or 2048B
Anything else (including no size) is 4096
Output files will be named file_#.ext
where # is number of file, and .ext is original extension
Actually, I forgot that you can also just type "1," "2," or "4" for the size. And right now it might not like directory paths or file names that contain spaces-- I haven't tested that yet, it may work. I probably need to tinker it with it a bit more anyway, to add some kind of output messages, like trap error conditions and display some appropriate error messages, and especially output some kind of message when the program runs correctly, like showing a list of the output files that it wrote.
Michael Rideout
-
I wrote a simple little QuickBASIC program to split 8K (or larger) ROMS into two (or more) 4K segments. If you have Windows or MS-DOS (i.e., if you can run QuickBASIC executables), I'd be happy to spruce it up a little and share it.
Michael Rideout
I have an XP upgrade. Pretty please, with sugar on top? I'd really like to see some of the code for these games without having to ask someone to disassemble a bunch of games for me. I'm gone for the weekend, but you can be sure it'll have a download early next week if it's ready.
Thanks,
-JD
Sorry for the delay! The original program was a QAD ("quick and dirty") hack that had the input and output filenames hardcoded (!) into the program, and I would just change the names and then run the program directly in QuickBASIC without even bothering to compile it. I had to totally rewrite it to be a true "command line" utility program, which is called "SplitFile." If you need help with it, you can just type "splitfile" at the command prompt and it will display a brief help guide, as so:
Nothing to do!Usage: SPLITFILE [<path>]<filename> [<size>]
Where: [<path>] is optional path (e.g., C:\Atari\2600\ROMs\)
<filename> is name of file to split (required)
[<size>] is optional size of output files (e.g., 4K)
Notes: <size> may be 1K, 2K, or 4K (case insensitive)
1K may be typed as 1K, 1KB, 1024, or 1024B
2K may be typed as 2K, 2KB, 2048, or 2048B
Anything else (including no size) is 4096
Output files will be named file_#.ext
where # is number of file, and .ext is original extension
As the preceding help guide states, the original input file can be split into one or more output files which are 1K, 2K, or 4K in size-- the reason being that (according to the bankswitching documentation by Kevin Horton) the various Atari 2600 bankswitching schemes can be grouped into three categories: (1) those that use banks which are 4K in size, (2) those that use banks which are 2K in size, and (3) those that use banks which are 1K in size. If no size is specified, then 4K will be assumed. Thus, if you know the bankswitching method used by a game, you can split the ROM into the individual banks, whether they are 1K, 2K, or 4K in size.
The output files will be placed in the same directory as the input file, and will have numbers appended to their names, preceded by an underline character (e.g., "_1," "_2," "_3," etc.). The original extension will be kept. If the input file is less than or equal to the stated bank size, then only one file will be output. And if the input file is not an integer multiple of the stated bank size, then the last output file will be however many bytes were left over.
For example, let's suppose that the SplitFile.exe program has been placed into the directory named C:\Atari\2600\Distella, and that a Burgertime.bin ROM file is in the directory named C:\Atari\2600\ROMs. The Burgertime ROM uses M-Network's bankswitching method ("E7"), which uses 2K bank sizes. So to split the Burgertime ROM into the appropriate 2K banks, you could type any of the following commands at the command prompt:
c:cd \atari\2600\distella
splitfile ..\roms\burgertime.bin 2k
or
c:\atari\2600\distella\splitfile c:\atari\2600\roms\burgertime.bin 2048or
c:cd \atari\2600\roms
..\distella\splitfile burgertime.bin 2kb
and so forth. In each of these examples, the output files would be as follows:
c:\atari\2600\roms\burgertime_1.binc:\atari\2600\roms\burgertime_2.bin
c:\atari\2600\roms\burgertime_3.bin
c:\atari\2600\roms\burgertime_4.bin
c:\atari\2600\roms\burgertime_5.bin
c:\atari\2600\roms\burgertime_6.bin
c:\atari\2600\roms\burgertime_7.bin
c:\atari\2600\roms\burgertime_8.bin
The program is written in FreeBASIC, which is a free BASIC compiler that uses a BASIC language which is mostly compatible with QuickBASIC (except FreeBASIC has some additional commands, plus a few of the commands have been modified somewhat from their QuickBASIC counterparts). The source code is included, in case anyone wants to peruse it, modify it, or port it to some other language.
Michael Rideout
-
That is so true! Sometimes I wonder why that is...
1982: "Hurry up and finish that game, or you're fired! We unveiled the mock-up at the Consumer Electronics Show yesterday and promised the press that it would be ready for Christmas this coming weekend!"
2006: "Think I'll do some more work on the game today, I've got the first three screens looking good, but I still need to tweak the joystick routine a bit, and then next week I need to rewrite the audio, because right now it sounds like a couple of dueling chainsaws."
1982: "Hurry up and finish that game, or you're fired! We want to put you to work on "Return of the Teen-Aged Killer Mutant Pac-Men from Outer Space," plus "Snore Quest Phase 6: World of Bubbles," both of which we told all of the magazines we would have ready for Christmas tomorrow!"
2006: "I'm having a great time working on this game! I wonder what I'll work on when I'm through with this one? Oh, no need to worry about that yet, I'll just stay focused on this game for now."
1982: "What? Haven't you finished that game yet? You're fired! Oh, and on your way out the door, you can stop by the Payroll Department and pick up your frozen turkey Christmas bonus in thanks for the multi-billion-dollar game you created last month! And don't forget, no one must ever know that it was you who wrote that game; you signed a non-disclosure agreement, and the company gets all the credit (plus all the profit) from every game you created!"
2006: "You know, I might not make any money from writing this game, and I'll actually have to shell out some money of my own to get the cartridges made, but it sure does give me a super-cool natural high to hold a finished game cartridge in my hands, smell that new game smell, and see my name printed on the label."
Hmm... on second thought, never mind!
Michael Rideout
-
1
-
-
http://www.atari2600.org/DASM/2600SDK.zip The link doesnt work...If anyone knows where I can grab a copy then let me know. thnx.
Yes, I noticed a few weeks ago that the link no longer works. Not that I needed to download it (I already have it), but I was including it in a list of available IDEs for Atari 2600 development, and I wanted to be sure it was still available.
I no longer have the original zip file, but I'll zip up and send you what I have, if I can figure out everything that went with it. But I'd like to point out a few things:
(1) The editor that the 2600SDK uses is a DOS-based program, so it doesn't look very pretty in Windows. You can actually get a more full-featured Windows-based IDE by downloading the free Crimson Editor program. That's all the 2600SDK editor is-- a DOS-based IDE that you set up to call DASM to compile with, and to call an emulator to play the compiled ROMs with. You can do the same thing with Crimson Editor. For that matter, you can do the same thing with the 2600IDE editor, which has a built-in playfield and player editor (although its text editor features are very simplistic compared to IDEs that have been under development for several years). So there's nothing special about the 2600SDK editor.
(2) The 2600SDK package also included the DASM assembler, along with the VCS.H and MACRO.H include files that are used with it, for compiling programs. However, the version that was included was old-- that is, there have been several newer realeases of DASM since then.
(3) As I recall, the 2600SDK package also included the Stella emulator-- or it may have been z26. But again, newer versions of Stella have been released since then.
(4) Finally, the 2600SDK package included the "Stella Programming Guide" PDF document, which is available from several web sites.
So there's no particular reason why you need the 2600SDK package. I do happen to be a little fond of, myself, but mostly for sentimental reasons-- it was what I used about a year and a half ago to get started with Atari 2600 programming!
Michael Rideout
-
In the meantime, if any one wants one go hereThanks, I found the same link earlier tonight by searching the forums archive for "MemCard." I can't believe how cheap they are ($10, right?)! I haven't ordered one yet, but I figure I'll buy at least 2-- one for my 2600, and one for my 7800!
This is a great time to be an Atarian-- batari BASIC, Cuttle Cart (1 and 2), Krokodile Cartridge, AtariVox, MemCard... what's next?
(Maybe supercat's bankswitched cartridge with oodles of executable RAM?) 
Michael Rideout
-
The X's were put into the disassembly file by Distella for all of the addresses that were specified as "GFX" in the config files.I've seen this, and finally stumbled back into it re-reading all of my old posts. Is there a free web-based program that will split the file in half for you? The one Thomas refers to way back when no longer exists in it's old form. And if not, has anyone written their own they would be willing to share? Also, while I'm at it, how do you specify an address as GFX?
-JD
I wrote a simple little QuickBASIC program to split 8K (or larger) ROMS into two (or more) 4K segments. If you have Windows or MS-DOS (i.e., if you can run QuickBASIC executables), I'd be happy to spruce it up a little and share it.
Michael Rideout
-
Hi! Thanks for the feedback...This looks great! I have only two gripes:First, it's hard to turn; you have to be lined up precisely right. Even if you think you're lined up just right, you might still be a tad off. Maybe you could add a small fudge factor, like if you're trying to turn, and are within a color clock either way, then you will automatically line up as needed so you can turn (if that makes sense).
Yes - that makes sense. One thing to note is that I made turning much easier by allowing you to press diagnol prior to getting to an intersection to make your next move. For example, if you're moving up and want to take the next left, you should press up and to the left (diagnol) before you get to the intersection. When you reach the intersection, your ladybug will turn left (no need to line things up). This of course works in all directions. I can easily move around the maze, opening doors with no mistakes, but if people still think it's too difficult I will work on implementing the "fudge factor" as you described.
Yes, I tried doing the diagonal move to turn more easily, and it did help a lot, but it was still kind of tricky to turn at times, especially when doing a "360" in certain areas of the maze. I figured that turning corners would get easier with practice, but in my opinion, anything you can do to make it easier for the player to move around will improve his or her enjoyment of the game. It's aggravating to get a game that you were really looking forward to, only to discover that moving around is difficult for one reason or other. Also, when movement is more difficult to do, it's my experience that I end up pushing harder on the joystick, which can shorten the lifespan of the joystick.
So with a game that's as great-looking as Ladybug is, you want to do anything you can to keep the gamer's experience enjoyable (yet keeping the game challenging, of course).
Michael Rideout
-
I still need to try it on a TV with my 7800, but when I tried it on an LCD monitor with the Stella emulator (with both the monitor and Stella set to 60 Hz), the flickering didn't seem to be any worse. I know from experience that flickering is usually more noticeable when switching between two luminances that are farther apart (e.g., lum $0 and lum $E). But then again, $4C isn't as bright as $0E, due to the difference in the hues.
I thought about trying to take a digital photograph of my TV screen, with my 7800 running a demo to show the difference, but I'm not sure how I could capture the blending effect of the flickering-- unless I make a short video capture? Anyone have any ideas? If I were using a film camera, I could just make sure that the shutter stays open long enough to get both frames so the blending can be seen. Is something similar possible with digital cameras? (I'm not an experienced digital camera user-- in fact, I only just bought a digital camera tonight after work!)
Michael Rideout
-
Second, the flickering when the ladybug overlaps another bug's scan lines makes both of them much darker (which is the nature of the flicker beast, of course). I wonder if making the colors brighter on those scan lines would help, since flickered colors get combined? That is, on scan lines where there's no flickering, just use the normal colors. But on scan lines where flickering is needed, if the colors are made brighter, then flickering them against the black background might result in a less noticeable loss of color, like this:Normal scan line (no flickering):
Frame 1: Ladybug color = $44 (or whatever).
Frame 2: Ladybug color = $44 (or whatever).
Combined result: color = $44.
Scan line with flickering:
Frame 1: Ladybug color = $48 (i.e., twice as bright as normal).
Frame 2: color = $00 (background).
Combined result: color = $44? (not really, since hue 4 and hue 0 doesn't give hue 4; but lum 0 and lum 8 = lum 4?).
I don't know if anyone's ever tried something like that, but it seems like it might possibly help.
I did a quick test of this in batari BASIC, and it does help, although of course the flickered red ends up having a grayish washed-out look. Also, the brighter color had to be about 3 times brighter than the normal color to get roughly the same effective luminance-- at least, using an emulator and an LCD monitor. I haven't tried my test on a TV yet, but the TV's phosphorescent effect might help.
So, if it's possible to work that sort of color change into the kernel, on the scan lines where flickering must be used, it would be worth a try.
Michael Rideout
-
Whilst there are comments which say what each line does, I'm interested to learn from a master list what each command does.For instance, these three lines:
PF0Array = $80 ; PF0 array, 18 Bytes ScoreshapeLow01 = $92 ; Shape of player 1 lower score digit PHP ; En/Disable bullet 1
where could i find out that the PHP command enables/disables bullets? and what the PF0Array command actually does.
The "PF0Array = $80" line isn't a "command" per se, it's an equate. It has two basic purposes: it tells the assembler that wherever "PF0Array" is seen in the program code, it is to be replaced (during the assembly process) with "$80"; and it helps make it easier for people to read or write the program code, since the programmer can just refer to "PF0Array" instead of having to write "$80" (which isn't self-explanatory the way that "PF0Array" is).
Same with "ScoreshapeLow01 = $92".
"PHP", on the other hand, is a 6502 assembly command which means "PusH the Processor status onto the stack." By itself, that doesn't mean "enable or disable bullet 1," although that is apparently what it's being used to do in this game.
Michael Rideout
-
Hello all,Just thought I'd post the latest "stable build" from Ladybug. Here are the major changes:
- all graphics are single-line resolution now
- new ladybug and bug graphics (thanks Nathan!) with animation
- ladybug can eat dots
- score is semi-working
- letters/hearts rotate color
- ladybug can eat hearts (increases multiplier indicator - score doesn't multiply yet)
- ladybug can eat letters (correctly indicates letters in SPECIAL and EXTRA)
- bugs can be displayed on the screen (don't move yet)
- removed pesky door in the middle of PF1 and PF2 (saves lots o' ROM)
- ladybug can revolve all doors
- semi-intelligent flicker between ladybug and enemies
Still plenty to go - any feedback is welcome!
Thanks,
This looks great! I have only two gripes:
First, it's hard to turn; you have to be lined up precisely right. Even if you think you're lined up just right, you might still be a tad off. Maybe you could add a small fudge factor, like if you're trying to turn, and are within a color clock either way, then you will automatically line up as needed so you can turn (if that makes sense).
Second, the flickering when the ladybug overlaps another bug's scan lines makes both of them much darker (which is the nature of the flicker beast, of course). I wonder if making the colors brighter on those scan lines would help, since flickered colors get combined? That is, on scan lines where there's no flickering, just use the normal colors. But on scan lines where flickering is needed, if the colors are made brighter, then flickering them against the black background might result in a less noticeable loss of color, like this:
Normal scan line (no flickering):
Frame 1: Ladybug color = $44 (or whatever).
Frame 2: Ladybug color = $44 (or whatever).
Combined result: color = $44.
Scan line with flickering:
Frame 1: Ladybug color = $48 (i.e., twice as bright as normal).
Frame 2: color = $00 (background).
Combined result: color = $44? (not really, since hue 4 and hue 0 doesn't give hue 4; but lum 0 and lum 8 = lum 4?).
I don't know if anyone's ever tried something like that, but it seems like it might possibly help.
Michael Rideout
-
-
Come again? You have a box of what that you need to get rid of? I thought they were temporarily sold out or whatever until another batch gets made, or am I getting them confoozled with something else? Because if you've got something for sale, I'd like to know the details!
Michael Rideout
-
On second thought, maybe I should clarify something.
Yes, there is a way to convert the binary source of a game into batari BASIC-- but not automatically, and the resulting bB program will not compile into 6502 code that's the same as the original code.
In other words, you could disassemble the binary source, analyze the disassembly manually, and do your best to replace sections of 6502 code with bB code that accomplishes essentially the same thing, or as nearly the same thing as you can manage. But this might require totally redesigning or replacing bB's include files, along with using inline assembly code for things that can't be adequately replaced with bB code.
In short, the process would be very labor-intensive, and the results might not be good enough (fast enough or condensed enough) to justify the effort.
On the other hand, such an exercise could be extremely educational, if it helped you figure out ways to accomplish similar results using batari BASIC (e.g., the original game is drawing a particular player shape and moving it around, so how can we draw the same player shape and move it around using bB statements).
So no, there's no way to do a conversion automatically, but you can do your best to manually convert a non-bB game into a bB game that recreates the "look and feel" of the original game as much as bB is capable of. And there's no way to get the equivalent bB code to compile into an exact replica of the original game.
Michael Rideout
-
I'd like to take a stab at this, too!
There's another issue in addition to the ones already mentioned. Basically (no pun intended), bB code isn't going to be as optimized as pure 6502 code could be, due to the manner in which the bB code is converted into 6502 code. For example, consider a simple custom display kernel, written entirely in bB code:
COLUBK = $94 : rem * Set the background to blue loop VBLANK = 2 : rem * Turn on the video blanking for x = 1 to 30 : rem * Draw 30 blanked scan lines WSYNC = 0 next VSYNC = 2 : rem * Turn on the vertical sync pulse for x = 1 to 3 : rem * Draw 3 blanked scan lines WSYNC = 0 next VSYNC = 0 : rem * Turn off the vertical sync pulse for x = 1 to 37 : rem * Draw 37 blanked scan lines WSYNC = 0 next VBLANK = 0 : rem * Turn off the video blanking for x = 1 to 192 : rem * Draw 192 blue scan lines WSYNC = 0 next goto loop
When this bB code is compiled, the resulting 6502 code is something like this (I've edited it to look more like "normal" 6502 code):
LDA #$94 STA COLUBK .loop LDA #2 STA VBLANK LDA #1 STA x .L03forx LDA #0 STA WSYNC .L05 LDA x CMP #30 INC x bcc .L03forx .L06 LDA #2 STA VSYNC .L07 LDA #1 STA x .L07forx .L08 LDA #0 STA WSYNC .L09 LDA x CMP #3 INC x bcc .L07forx .L010 LDA #0 STA VSYNC .L011 LDA #1 STA x .L011forx .L012 LDA #0 STA WSYNC .L013 LDA x CMP #37 INC x bcc .L011forx .L014 LDA #0 STA VBLANK .L015 LDA #1 STA x .L015forx .L016 LDA #0 STA WSYNC .L017 LDA x CMP #192 INC x bcc .L015forx .L018 JMP .loop
On the other hand, a more optimized version written in 6502 code might be:
LDA #$94 STA COLUBK LDA #2 .loop STA VBLANK LDX #30 .front_porch STA WSYNC DEX BNE .front_porch STA VSYNC STA WSYNC STA WSYNC STA WSYNC STX VSYNC LDX #37 .back_porch STA WSYNC DEX BNE .back_porch STX VBLANK LDX #192 .raster STA WSYNC DEX BNE .raster JMP .loop
Note how much more condensed the pure optimized 6502 code is. The bB code is probably easier for many people to understand, but it ends up producing lengthier 6502 code when it's compiled. And if you want to use bB's default kernel, the bB code is even easier to understand:
COLUBK = $94 loop drawscreen goto loop
However, bB's default kernel does a lot more than what the custom bB kernel did in the first example, because bB's default kernel includes code to automatically draw the playfield pixels, players, missiles, and ball on each scan line, which the custom kernel in the first example didn't bother to do.
When programmers write Atari 2600 games, they usually go to great pains to squeeze the instructions into the smallest number of bytes and fastest execution time. Simply put, even if you could create a conversion utility that's smart enough to be able to examine 6502 code, figure out exactly what it's doing, and generate bB code that does essentially the same things, the equivalent bB code will compile into much lengthier 6502 code, which will take up more bytes and execute in more machine cycles.
Additionally, bB uses a lot of the Atari's 128 bytes of RAM for bB's own "system variables" (e.g., the array for the playfield pixels, the variables for storing the x and y positions of the players, temporary variables that are used with bB's default kernel, etc.). So if we tried to convert a typical Atari game into an equivalent bB game, we probably won't have enough free RAM to use for all of the game's own variables.
So even if somebody could create such a conversion utility (and it would certainly be very cool if someone could), there wouldn't really be much point in using it. But that doesn't mean we can't create bB games which are very similar to existing Atari games.
Michael Rideout
-
Well, all you really need (absolute essentials) to develop games for the Atari 2600 are (1) a computer, (2) a text editor, (3) a 6502 assembler, and (4) an Atari 2600 emulator. Obviously, (2), (3), and (4) should work on (1). It could be argued that (4) isn't essential, since you can run your games on an actual Atari 2600 or 7800 if you have the right tools for doing that-- e.g., a Supercharger, Cuttle Cart, Cuttle Cart 2, or Krokodile Cartridge, and anything else required to load the game into said devices. But for the average person, an Atari 2600 emulator is probably more easily obtained and more convenient to use.
As far as (3) is concerned, the DASM assembler is available for Mac OS X, so you can/should download DASM (http://www.atari2600.org/DASM/).
As far as (4) is concerned, the Stella emulator is available for Mac OS X, so you can/should download Stella (http://stella.sourceforge.net/).
That leaves (2). If you want to make the programming process easier, you'll want to use an IDE ("integrated development environment"), because you can set up any decent IDE to compile your programs, and to run your compiled programs, all from within the IDE. I read that there is a free IDE for Mac OS X called Xcode, but I don't know anything about it. If you've never used an IDE before, be aware that you generally need to set it up to work with any language that doesn't have built-in support, so you'll most likely need to set up the IDE to call DASM to compile your programs, and to call Stella to run your programs.
An alternative to programming in pure 6502 assembly is to use batari BASIC. As far as I know, you'll need to "make" or build/compile batari BASIC to run on OS X, since an executable for OS X isn't already provided the way that an executable for Windows is. Compiling batari BASIC program code is a two-step process-- first you must compile the batari BASIC code into 6502 assembly code using the batari BASIC compiler, then you must assemble the 6502 assembly code into a binary file or "ROM image" using the DASM assembler-- so you still need to get DASM. And you'll need to set up your IDE so it calls a batch file that in turn calls the batari BASIC compiler and the DASM assembler. You can download the source for the latest "official" release of batari BASIC (http://www.alienbill.com/2600/basic/), or you might prefer to download the "bleeding-edge pre-release" of the next version (http://www.atariage.com/forums/index.php?showtopic=82011).
It also goes without saying that you'll need good references on the Atari 2600 (its features, its memory map, and how its memory locations control its features), and on the 6502 assembly language. These are available here on the internet:
Michael Rideout
-
-
Here's a proof-of-concept demo for a brick-busting game with an unusually generous number of brick colors per row (FIFTEEN!). The kernel would require self-modifying code to allow a changing brick field and thus for all practical purposes would require something like a SuperCharger or M-Network cart, but would support three bouncing balls in a one-line kernel.The colors aren't really solid colors, but consist of two colors blended on alternate scan lines. On even scan lines, the colors are black, gray, red, and cyan; on odd scan lines they are black, gray, purple, and gold.
You forgot the 16th color-- black!
Or if you prefer, black plus 15 colors.You could try blending the colors more by alternating the colors on frames-- odd frames having black/gray/red/cyan (even lines) and black/gray/purple/gold (odd lines), and then even frames having the odd/even line colors swapped. I'd like to see what that looks like!
Michael Rideout
-
batari BASIC lets you use inline assembly in your programs, so in theory there is nothing that assembly can do that batari BASIC can't do-- but you might have to write your own kernels, compile without any bB include files, etc., to get "full assembly" capabilities.
Michael Rideout
-
There is a fully commented disassembly of Donkey Kong available here.Thanks! I knew that some games have been disassembled and commented, but I had lost the bookmark to that page.
Michael Rideout
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Does anyone have the Batari basic Front end?
in batari Basic
Posted
You can download the latest version from this very forum:
http://www.atariage.com/forums/index.php?a...e=post&id=40558
I also recommend Crimson Editor, a free IDE that can be easily set up to work with batari BASIC and/or 6502 assembly programming.
To answer your private message to me (because other people probably want to know the answer as well), no, I haven't launched my tutorial yet. I kept trying to revise it, and then I got sidetracked by other things. But I'm going to start posting it tonight or tomorrow night. And it won't be formatted in HTML like I'd intended, it will just be posts to this forum. Once it gets well under way, I plan to go back and start redoing it as a spiffy HTML version.
Be warned, though, that I don't plan to get into any actual programming right away, because I intend to cover some preliminaries first, such as getting things set up on the computer-- downloading and installing the necessary tools, configuring Crimson Editor to work with batari BASIC and 6502 assembly, modifying the compile batches to allow the use of subdirectories, etc.
Also, my intention is to cover the Atari's basic features one by one, therefore you may not be able to start working on a game until several sessions into the actual programming sessions.
Michael Rideout