Jump to content

Karl G

+AtariAge Subscriber
  • Content Count

  • Joined

  • Last visited

Community Reputation

2,809 Excellent


About Karl G

  • Rank
    River Patroller
  • Birthday 09/17/1973

Profile Information

  • Gender
  • Location
    Indianapolis, IN

Recent Profile Visitors

10,531 profile views
  1. I made a small correction to the last part. My "alphadata" lines did not specify the characterset, so this has been corrected in the post and the attached file. There may be more of these that I discover later when I get to the point where I can compile and test. At this point, the compiler segfaults when I attempt to compile, presumably because it's not designed to parse the bB code still present in the WIP conversion.
  2. That's definitely great news. I'll definitely want to pick one up for testing purposes when they are available. One question - how much will they add to the cost per-cart if one releases a homebrew that uses them?
  3. Playfield Conversion The playfield in batari Basic is 32 characters wide, and usually 11 rows. I can convert the playfield to character data in 7800Basic. Playfield pixels in batari Basic are solid blocks that are 4 pixels wide and 16 scanlines in height. Since I am using the 160A graphics mode, a zoneheight of 16, and am not using the the doublewide parameter, characters are also 4x16. The difference is that characters can be any shape we want, can have 3 different colors, and can use the whole screen width. For now though, for this first phase of the conversion process, I will display the playfield data as is for simplicity, and make it look nicer in the next phase. pfcolors: There is no equivalent in 7800Basic to set the colors of characters on a per-row basis. This isn't really needed, since characters on the 7800 can display multiple colors. For now in the first phase of the porting process, I simply delete all instances of pfcolors. COLUBK This is an easy one to convert. I simply did a search and replace changing COLUBK to BACKGRND, which functions in the same manner. Creating Character Data In order to use characters in lieu of playfield data, I first have to create the image that will be used for the characters. For purposes of this first phase of conversion, this will just be a blank character, and a solid-color block. Graphics used in 7800Basic need to be in indexed PNG format, and 3-colors for our chosen graphics mode. This can easily be created in the sprite editor in Atari Dev Studio. Click the "Sprite Editor" icon at the bottom of the window to launch the editor, choose "new project", "Atari 7800" as the Console, size of 4x16, NTSC, and "3 colors + 1 transparent". Since the first character will be blank, I don't put anything in the editor, and click the "New" icon in the sprite window. This will take me to the second sprite image. I fill this image with a single solid color. I then click the "export" icon, then the "export all" button at the top to export both sprites to a single image. I name the image "bgchars", and place it in the gfx subdirectory I created earlier. To use the image, I need to import it into the game. Right before the "gosub introscreen" line in the source, I added the following lines: incgraphic bgchars.png 0 1 2 3 characterset bgchars alphachars '.X' P0C1=$0F P0C2=$0F P0C3=$0F incgraphic: This tells 7800Basic where to find the newly-created image that will be used for characters. The first 4 numbers after the filename are to map color indexes in our image to palette entry numbers on the 7800. The last number corresponds to the palette number (not needed yet, but will be used in a later phase). characterset: This is used to point the 7800 to the correct graphics to be used for characters. alphachars: I use alphachars to define the text characters I use to refer to each character graphic I have defined. I have only defined a blank character and a solid block so far, and for ease of porting, I use the same text characters as are used in batari Basic to define the playfield. "." represents a blank character, and "X" represents a solid character. P0C1, P0C2, and P0C3: For now, my character graphics will use palette 0, so the colors of this palette need to be defined. For now, I am setting all 3 entries to the same color. playfield: At this point, I can convert playfield definitions to character definitions with only a few changes. Specifically, playfield definitions are changed to alphadata definitions, and then they are drawn to the screen with plotmap. For example, here is the playfield definition for the first room: playfield: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX X..............................X X..............................X X..............................X X..............................X X..............................X X..............................X XXXXXXXXXXXXXX....XXXXXXXXXXXXXX end The late will remain the same, with each line of playfield enclosed in single quotes. In place of "playfield:" I put "alphachars" followed by a name. Here's how it looks after these changes: alphadata r00_background bgchars 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' 'X..............................X' 'X..............................X' 'X..............................X' 'X..............................X' 'X..............................X' 'X..............................X' 'XXXXXXXXXXXXXX....XXXXXXXXXXXXXX' end To draw the character on the screen, I use plotmap. For the character data above, the command would be: plotmap r00_background 0 16 0 32 11 r00_background is the unique name I gave the character data. The first number is the palette number I am using, in this case zero. The second number is the X pixel coordinate where the characters start. This matches where the playfield data starts on the screen using batari Basic. The third number is the Y line coordinate where the character data starts. 32 is the number of characters per row, which matches the number of playfield pixels in each row using bB. 11 is the number of rows to display, which also matches bB playfield display. clearscreen and savescreen To save CPU cycles, savescreen is used to preserve graphical elements on the screen that do not change every frame, such as the background for each screen. When the screen changes, clearscreen is used to remove what was previously saved in order to build a new saved display. I add a clearscreen at the beginning of the room_draw routine, and a savescreen in the room_draw_end routine to accomplish this. ature.78b Image file for playfield characters Edit: Corrected alphadata syntax to specify the characterset
  4. That's great to hear! It will also help when using ImageMagick to batch convert images.
  5. I'm not sure how this is relevant? It's an existing prototype, and figuring out how it was coded is certainly a worthwhile topic, IMO.
  6. If it is affecting gameplay as well, then it is almost certainly a hardware issue rather than an issue with the multicart. Once the game is loaded, the Concerto isn't a factor anymore. I'm wondering if there's a loose wire for that joystick port or somesuch. A hardware person might have more ideas.
  7. Gotcha. In the source I sent you, the offending line is this one: if !ShipEatenBit5{5} then playsfx sfx_thrust
  8. Are you referring to my issue? I couldn't find a case of me using a multi-line statement as part of an if...then. Do you mean the playsfx command?
  9. Thanks! The sprites are single-line instead of double-line, so a direct conversion will have them appear to be a bit squashed. That's fine for the first phase to get everything working. After that, they can be recreated with double the vertical resolution, and using up to 3 colors when at the point of making things look nicer.
  10. Initial Conversion The first step is to copy ature.bas to ature.78b, and then make the modifications to the latter. I then create a gfx subdirectory under the directory where this source file lives (explained later). I will be using Atari Dev Studio for the conversion process. Process The plan is to do an initial conversion to get the game working as quickly as possible, test that version, then redo some parts to improve the look and feel, and take advantage of some of the 7800's features. Compiler Directives The first step will be to remove batari Basic compiler directives, and add in 7800Basic-specific options. The following lines in the original should be removed: set kernel_options pfcolors set romsize 32k set smartbranching on set kernel_options pfcolors We will add in the following 7800Basic options: set zoneheight 16 set basepath gfx set romsize 48k displaymode 160A zoneheight: The zone height is the height of sprite and character graphics in 7800Basic. The character graphics will correspond to the playfield graphics from the original. Setting this to 16 will allow for 12 rows of characters, which will accommodate the 11 playfield rows of the original game with room to spare. basepath: This is the location of other files such as graphics needed by the game, relative to the location of the source file. I will put any such files in the gfx subdirectory I created earlier. romsize: The original 2600 game is 32K. 48k is the largest romsize without bankswitching, so I choose this. It should be plenty of room for the game, including additional graphics. displaymode: This sets the displaymode for the 7800 game. We will use the default of 160A mode, as it matches the horizontal resolution of the 2600, and has less restrictions on colors. Banks The original game is 32K, bankswitched. The 7800Basic version will be 48k without the need for any bankswitching. Due to this, I will modify the source to remove all banks, and references to banks. Specifically, all "bank X" lines will be removed, bank targets will be removed from gosub and goto statements, and "thisbank" and "otherbank" qualifiers will be removed from return statements. Minikernel This game uses the 6lives_statusbar minikernel to display game information. There is no concept of "minikernels" in 7800Basic, so I will comment out that line from the source. We will have an extra line of space when we convert the playfield screens, and I will show how to make use of this space to provide the same information later. I also comment out any references to "lives", "lifecolor", and "statusbarlength" derived from this minikernel. Next Steps The modified source after completing these steps is attached below. Note that it is nowhere nearly ready to compile with 7800Basic by this point. In the next part, I will show how to convert playfield data from batari Basic for screen backgrounds in 7800Basic. ature.78b
  11. I'm out of my depth on this one as a Mac user. @mksmith Any ideas on this one?
  12. Introduction The game "Ature" for the Atari 2600 was made with batari Basic, and the source was released under an open-source license. I thought that this game could be a good base to demonstrate how to port a bB project to 7800Basic. In addition to the license allowing for modification and redistribution, I have also contacted the author @beoran and received his blessing for this project as well. Purpose My goal is to demonstrate the process for porting a game created with batari Basic to the 7800 via 7800Basic. This also serves as an alternate way to learn 7800Basic for those who are already comfortable with batari Basic. The process will show the differences between the two languages/environments. Original Source and Copyright The source file for Ature contains the following copyright notice: rem ' Ature Adventure rem ' Copyright [email protected] 2009, 2010. rem ' May be distributed under the Zlib License. No warranty, use at your own risk. Basically, the zlib license says that the source can be modified and redistributed, but the original copyright notice needs to remain, and the original authorship of the game should not be misrepresented. So, to be clear, this isn't my game, it's @beoran's. The original source zip is attached to this post. The original source won't compile cleanly with modern versions of batari Basic (it's over 10 years old!), so I am also attaching a modernized version of the source that will compile without the need for bB source modifications or a C preprocessor like the original. Original source: ature_20100708.zip Modified for modern bB: ature.bas
  13. In this case, the initial list will be in ROM, and the shuffled list would go in RAM. Edit: I did end up doing in-place shuffling after copying to RAM.
  14. No need to remove your question just because you got an answer. Topics like this can sometimes be useful to people later when they are doing a search, and having the original question is handy for reference.
  15. Are you compiling using a Makefile? In this case, you launch the emulator yourself from the Makefile. If not, are you seeing any errors in the compile output? It might not be getting to the part where it runs the emulator. Did this work before? Have there been any changes on your system since you were developing previously?
  • Create New...