jwierer

Yeah I was thinking that folks could just use Tile Molester to modify the graphics, but having used that in the past I do find it a bit cumbersome and prone to unintentional error. Since I am not as familar with the 7800 video modes if you have any background information or feel comfortable sharing sprite source with me I am pretty sure I could get something working over the course of a few weekends. Thanks again, Jeff

I wasn't quite happy with how I was handling colors in the last build using drop down menus. I also didn't like being limited to a subset of colors. I'm much happier with the color palette and being able to visually see the changes as it looks a lot closer to actual game play. What's new You can edit energy dots, dot color, and outer maze color in 7800 Pac-man! I've changed the font for dots and energy dots to look more like the actual game. Colors are now implemented for the inner maze, outer maze, and dots. Colors combination's are now unlimited and you can select from a color palette. Plus button for editing the Plus options for Pac-man Collection This is what it looks like now. Known problems Can't change the outer color for the original 7800 Pac-man rom. I just haven't been able to find the location Copy/Paste is flaky. For small sections it works fine, but for larger portions the last row wraps to the top? I hate these type of bugs because it takes me stepping through every line to figure out where it breaks... Once I clear up the remaining issues, I'll start taking a look at sprite editing. I know where they are stored in the rom. I'm not sure how well I will be able to represent all the sprites though. There are good sprite hacking tools out there anyway... -Jeff

I spent a little time on an airplane over the weekend. That gave me some time to look into colors for the maze and dots. A maze is a combination of two colors an outer and inner bar color. Dots are a single color. So for example, in Ms. Pac-man collection there are 4 mazes so there are 12 different locations you can change the colors. On top of that Pac-Man Collection has 21 mazes and can run in “plus” mode which means you have 3*21*2 = 126 different colors you can set using the following 22 colors. 1. AQUA 2. BLACK 3. BLUE (Light) 4. BLUE 5. BLUE (Dark) 6. BROWN (Light) 7. BROWN 8. GOLD 9. HOTPINK 10. PINK (Light Light) 11. PINK (Light) 12. PINK 13. GREEN (Light) 14. GREEN 15. GREEN (Dark) 16. ORANGE 17. PURPLE (Light) 18. PURPLE 19. PURPLE (Dark) 20. RED 21. WHITE 22. YELLOW Next I am going to try to implement a full color palette. This was just an easier to work with until I figured out how to read/write the colors. Here is a screen shot of it in action with Ms. Pac-man.

The other day I spent a little time working on enforcing some rules for the games so that you don’t accidentally create a maze that won’t run. Ms Pac-man – has 4 levels all 31 cells tall by 29 wide. You can have horizontal tunnels, but not vertical. Pac-man – Originally based on the Ms. Pac-man code it has 2 levels (get to the second one by using the player select switch) 31 cells tall by 29 wide. You can have horizontal tunnels, but not vertical. Ms Pac-man (Bob’s Arcade Hack) – Like the original it has 4 levels, but has a height of 32 width of 29. The extra row was added to make it match the original arcade. You can have horizontal tunnels, but not vertical. Pac-man Collection – Contains 21 mazes (356 bytes a piece!). Like the Ms. Pac-man hack these match the arcade with a height of 32 and width of 29. You can have horizontal tunnels, but not vertical except on level 10 which has special logic to handle a vertical tunnel. Jr. Pac-man – Contains 8 mazes. 7 from the original Jr. Pac-man and a bonus (Easter egg?) level based on the Xbox Pac-man game (forget the name). These are all 32 cells tall by 56 wide. Jr. does support vertical tunnels, because it is required in the bonus level, but alas does not support horizontal tunnels. Because of these limitations I’ve enforced making changes to the boarder of the game.

You can certainly modify the maze to match Piranha, though from what I understand the only maze that supports vertical tunnels is maze 10 in Pac-man Collection since it was specifically added for that maze. If you put a vertical tunnel on any other maze in PMC or MS. Pacman the ghosts will get lost and Pac-man/MS. Pacman are blocked from going off screen. Interestingly enough Jr. Pacman has the logic for vertical tunnels, but not horizontal. Even if you change the mazes you would also need to change the maze colors and hack the graphics. The graphics and colors are pretty straight forward to change, but I haven't gotten around to that yet... -Jeff

I am done working on a Jr. Pac-man Construction Set and have moved onto a Pac-man Construction Set. So far this is working with Jr. Pac-man, Pac-man Collection, Ms. Pac-man, and Bob’s recent Ms. Pac-man Arcade hack. On top of supporting additional games and fixing some bugs, the controls are a bit different. You can still select and enter dots, mazes, or energy dots, but now there is a Maze and Dot mode where you can draw freely with the let mouse button and erase with the right mouse button. BTW did anybody realize that Pac-man Collection Set had 21 different mazes? Poor Bob had to create all of those by hand! Anyway here are a few screenshots of the latest in action.

In Jan 2008 I saw this thread about 2600 IDE not supporting .bas files > 64K. That got me thinking about developing an integrated development environment for batariBasic. So I guess Atar2600land should get credit for inspiring VisualbB because if I hadn’t read that post I would have never thought about it. Anyway I figured that it was a limitation of the COM control being used. I vaguely remember that being a limitation in Visual Studio 6. Since I was getting into writing some games using bB I thought it would be nice to create an IDE without limitation. I also liked the idea of visually editing sprites and playfields so late on a Sunday night I set out to recreate 2600IDE using Visual Basic 2008. It took about 2 days to create sprite and playfield editors like 2600IDE. One I got the basics working though I decided it needed to be a bit more sophisticated. I noticed that game authors were creating a lot of different games and that reuse of sprites and playfields might be convenient. I also like Visual Studio (using it since VS5) so I wanted to create a complete development environment for batari Basic. Why should bB users be limited to notepad like environments? I spent another 2 weeks coding at night to mimic a Visual Studio-like experience. At that point everything was done except for compilation. I figured I could just call the same set of executables in 2600.bat and capture standard output into a message window. Unfortunately the way the bB compiler works that doesn’t work for errors!! I spent a good week trying to find a way to do it, but in the end if there is a compilation error I call the batch file, write to a temp file and parse the temp file. It’s ugly but it gives the illusion of being compiled in the IDE. Probably about a month or so in I gave a copy to Random Terrain. A great number of features were direct feedback from RT, too many to even list. Redo/Undo was a pretty big one, because there are so many actions that can be completed in the sprite/playfield editors that it probably took 2 weeks to implement that. The color coding was probably the single biggest RT feature request to implement. That required building a comprehensive dictionary of bB terms along with keeping track of user defined variables, functions, labels, etc… Because I am just using a standard Rich Text Box Control I have to detect a term, select it, and color code it appropriately. Because code files can be relatively big, remember the inspiration was to support > 64K (I believe vBB is limited to 1M characters), I do the color coding in a background thread. For multi-core systems this allows one of the CPUs to do the text searching while allowing the user to also use vbB. Ever open multiple .bas files at once? You’ll notice the CPU usage spike and shorter codes will load faster. Yes that load time is all color coding. Disable color coding and files should open instantaneously. Once color coding was done it was logical to develop a runtime code checking and intellisense. It seemed simple enough. Another month later that was done… One feature I started at the very begging, but never finished, allowed you to change a sprite/playfield then automatically update all the code files using that sprite/playfield. In the end it was a dumb idea as it was impossible to detect if a sprite changed so I ditched it, even though a majority of the code is still there. If sprites/playfields had a naming scheme it would be possible! vbB has so many features that unless you read RT’s manual you probably one of them. One of the coolest is generate items from code. Let’s say you like an author’s playfield or sprite and all you have is their .bas file. You can right click on the .bas file in vBB and choose generate code. It will parse the code and create the corresponding sprites, playfields, or data blocks. It’s not perfect, but there is a ton of logic in there looking for code patterns. For the most part it will allow you to generate these items. It’s also really nice if you wrote your code prior to using vbB and you don’t want to recreate items by hand. I still have some improvements I’d like to make, but for the most part it’s complete. You can download the latest here.

About once a year I get some external motivation to code. In 2007 I started looking at some of the bit hacking tools bit-hacker, hack-o-matic & HOM ][. They were better than using a hex editor for hacking up 2600 graphics, but lacked some of the flexibility I was used too in other applications. For me bit hacking needed to be a lot more like Microsoft Excel. I actually started by creating an add-on for Excel, but eventually I figured not everybody would have Excel and I wanted to really customize the experience. I did start by looking at the HOM][ source. One of the things I noticed was that it was directly drawing to the form to create the grid. While incredibly fast, it did seem somewhat limiting. The whole idea was to create a much more flexible environment that felt like Excel so I opted to design it around the datagridview control. (DGVC) While this was meant for really data entry it's very convenient and powerful. Also after using it for my graphics editor in my Beef Drop Construction Set I was very familiar with it. Unfortunately when I got started I writing the code quickly and not worrying too much about optimization. The result was in my first few public releases it could take up to minutes to load a binary of 16-32k. A bit part of the problem is how the DGVC adds rows. If you added them 1 by 1 it's ridiculously slow as it appears to redraw every time it's added. The first optimization was to figure out the number of rows, based on total bytes, re-size the matrix, load it and then visualize. Also because I introduced color coding, pinning, comments there is a bunch of logic that occurs in every row. Think about it, even though you may only be editing a 32K file, small by modern standards, it results in what is essentially a 32,768 rows by 18 columns. Excel 2003 and earlier only supported 256 columns by 64K rows so it's actually and impressive size grid if you think about it! The other major optimization was to move the row logic into separate threads if you have multiple cores. This way the load is spread across all the cores in modern PCs. Problem is that the DGVC is still updated in a single thread so you can't maximize performance. Anyway, on my laptop I think a 32K rom loads in ~3.1 seconds so it's a vast improvement over my earlier attempts When I started this, I had just upgraded to Visual Studio 2005 so this was written entirely in the .NET 2.0 Framework. If you've never tried HOM3, since it's incredibly difficult to find, you can download the latest published version here.

Ok made some more progress on this project today. First I added some of the basics such as the ability to cut, copy, paste and delete. Build 3 was mainly fixes I found while playing with Build 2. You can place items on the board by selecting one or more cells and pressing one of the following keys on the keyboard • SPACE - places a maze part • D - places a Dot • E - places and Energy Dot • Delete - clears a dot If you hold down the left mouse button while pressing any button it will clear the cell. As I was playing with it I found myself wanting to toggle and this is a quick way to place and replace an item. When you place a game piece on the maze it will automatically enforce the rules I described in my previous blog entry. This is just one thing that is counter intuitive, but once again it's really a limitation of the level implementation and trying to use a single design surface. The other is copy/paste, but moore on that later. I also added context menu (right click on maze) with some additional time savers. I figure most people will create the outline of the maze first and then add dots. While there is menu item "Auto-fill dots" it will fill every available empty space. Alternatively you can select a region, right click and add dots to selected. Just as easily you can select a range and clear dots selected. Once I created those two adding/clearing maze selections was just the inverse of the logic. Copying and Pasting... I've done this with all my other tools so you would think I could just lift the code and work with it. Sure enough all those were just binary on/off. Since a cell in Pac-man can have a piece of the maze, dot, energy dot, or empty I had to create a new copy mechanism. That actually isn't the hard part, it's the paste! Since Jr. Pac-man stores half the maze and just reflects it in the game paste needs to be reflected. So the tough part is if you’re pasting on the right side of the maze in cells greater than 28 and you are pasting you need to think in reverse! As a hint if you copy from the right side it will select the region on the left that is the equivalent. At least this somewhat helps you from pasting a mistake. Even if you do make a mistake there is now Undo! Undo and Redo is another one of those things that gives me a hard time to implement. Basically I use two queues. In vbB I would have to keep track of all sorts of possible changes, resizing, rotations, colors, as well as pixel placements. With Jr. Pac-man I realized with a fixed 57x31 grid I just need to create snapshots. This is probably a bit of a memory hog, but ram is free nowadays. Anyway it will keep track of the last 100 changes and allow you to undo them. Undoing, just moves it to the redo queue in case you have a change of heart. Anyway here is the latest screen shot

Thanks Bob! This is coming along nicely. I hope to have another update today. -Jeff

Now that the Memorial Day holiday is over I took a fresh look at this again. To understand this blog post you need some basic grasp of how mazes, dots, and energy dots are stored. Mazes To begin, the 8 mazes are stored as a series of 8 bit codes. Decoded into binary, from lowest to highest bit they are read horizontally. Since the maze is symmetric only half of the maze is stored in the binary. In the editor you will see both sides for ease of development, but placing dots is mirrored so a change on the left half will automatically be reflected on the right side. It is also important to understand that there are 5 empty bits on the left and right side of the maze that are outside of the bounds of the viewable range. For that reason I made the editor to only show the bits that can be modified. If you were to examine the viewable portion of the first maze in binary, within the actual rom, it would look like this. 01111111111111111111111111111 01000000000000001000000000001 01000000000000001000000000001 01001001111001001001001111001 01001000000001000001000001001 01001000000001000001000001001 01001001111001001111001001001 01000000000001001000001000000 01000000000001001000001000000 01001001111001001001111001111 01001000001000000000000000000 01001000001000000000000000000 01001001001001001111001001111 01000001000001000000001001111 01000001000001000000001001111 01001111111001001111001001111 01000000000001000000000000000 01000000000001000000000000000 01001001111001001001111001111 01001000001001001000000000001 01001000001001001000000000001 01001111001001001111001111001 01000000000000000000000000000 01000000000000000000000000000 01001001111001111001001001111 01001001000000000001001000001 01001001000000000001001000001 01001001001111001001001001001 01000000000000001000000001000 01000000000000001000000001000 01111111111111111111111111111 01111111111111111111111111111 Dots While dots are also stored as a series of 8 bit codes, decoded from lowest to highest bits, they are decoded horizontally, from left to right. Additionally, while Pac-man dots are symmetrical, all the dots are stored, not half like mazes. Technically speaking this would allow you to create a different dot pattern on the left and right hand sides of the maze. For Build 2 I’ve changed the editor so the user can enable/disable mirror, or reflecting, dots. For 99% of the cases I would guess reflection is the desired effect? If you were to decode the first maze into binary it would look like this. 011111111111110011111111110011111111110011111111111110 010010000010010010000000010010000000010010010000010010 010010000010010010000000010010000000010010010000010010 010011111110011110011110010010011110011110011111110010 010010000010010000010010010010010010000010010000010010 010010000010010000010010010010010010000010010000010010 010011111110010011110011111111110011110010011111110010 010010000010010010000000000000000000010010010000010010 010010000010010010000000000000000000010010010000010010 010011110010011111110000000000000011111110010011110010 010010010010010000010000000000000010000010010010010010 010010010010010000010000000000000010000010010010010010 011110011110011111110000000000000011111110011110011110 010000000010010000010000000000000010000010010000000010 010000000010010000010000000000000010000010010000000010 010011111110011111110000000000000011111110011111110010 010010000010010000000000000000000000000010010000010010 010010000010010000000000000000000000000010010000010010 010011110010010000011111110011111110000010010011110010 010000010010010000010000010010000010000010010010000010 010000010010010000010000010010000010000010010010000010 011111111111111111111111110011111111111111111111111110 010010000000000010010000000000000010010000000000010010 010010000000000010010000000000000010010000000000010010 010010011111110010010011110011110010010011111110010010 010010010000010010010010010010010010010010000010010010 010010010000010010010010010010010010010010000010010010 011111111111110011111110011110011111110011111111111110 Energy Dots Energy Dots are stored using a row and column designation that follows the row and column settings of the dots. Because these items are stored separately my first attempt had the mazes and dots on separate screens. While this worked I found myself constantly toggling between the maze and dot editor trying to align the correctly. Then I would keep emulating it to see if I got it right. It worked a lot better than using Hack-o-matic III, but still a bit cumbersome. Yesterday was a slow day so I started playing with putting them on the same screen and creating an editor mechanism that would display them side by side. Because of the length that these are stored it’s not possible to have maze and dot parts side by side in a grid, therefore there needs to be an empty cell to the right and below maze pieces, though maze pieces can be side-by side, same with energy dots. Anyway after a few hours I now have a single interface for modifying the maze. When you place a game piece on the maze it will automatically enforce the rules just described. I also added some additional functionality for clearing all dots and automatically filling the maze with dots based on valid placements. I found this dramatically decreases design time!

Ever since I saw Pacman Plus’s original 5200 hack of Pac-man I wanted to create a graphic editor for manipulating Pac-man mazes. I’ve looked at the mazes using HOM3 and other text editors, but the exact format always confused me. Creating a graphical tool is pretty easy, but decoding the maze is another thing! Unlike Beef Drop (aka Burger Time), the mazes are not as straight forward. Last week Bob shared with me some partial source to Jr. Pac-man. It was just enough for me to finally figure out how the 7800 mazes are stored for Jr. Pac-man. Probably also works for any of the 7800 variants since they are all based on Ms. Pac-man, but I haven’t bothered to check if I can find the maze locations. Anyway my in-laws were in town over Memorial Day weekend so I found myself a reason to sit in front of my computer for a few hours. Here is a screen shot of the first couple days of work. I can already modify mazes, dot and energy pill locations. Editing is still pretty primitive, but it works! Perhaps once I am done I will go back and create a single application that can be used to hack any of the 5200/7800 variants of Pac-man. I am sure I will need a project to work on in 2010

I actually own a full size Burger Time so I was really excited when Ken Siders started posting Beef Drop(actually Burger Time) roms to the 5200 forum. I had played it for almost a year before I noticed that there were a couple errors in level 3 in the 5200 version. So I started looking at BD using a hex editor to make the changes and also discovered hidden levels available in the AtariAge cartridge release. Ken created mazes that were incredibly easy to view in a text editor, but it was a bit tedious to manipulate by hand because a slight typo might result in a piece of a burger that looked ok, but since it was off by a bit it wouldn't work. Also there are drop areas that need to be set and if you just change the maze it won't work. Ken posted the source and also sent me several very crucial personal messages about how the game engine worked that allowed me to create this editor. Although I never publicly shared it until now, I did share it with a couple AA users to test it. Christmas day 2006 I used BDCS to create the levels for my xmas-time hack available here. You can't use BDCS to hack the graphics though, I used tile molester (terrible name) for that. Once I finished editing the 5200 version I figured I would add support for 7800. I figured Ken used the same mechanism for describing mazes – yes and no. He did use the code encoding scheme, but since he wanted to save space for additional logic (proper arcade regeneration of falling bad guys) he used compression to store the mazes – doh! Luckily he shared his Perl script for compressing the mazes and assembly used to decompress it. All I had to do was recreate that code in visual basic – not easy especially when decoding 6502 assembly –oh which I am not an expert. It took about 2 weeks to create a reliable compression/decompression library (bdzip.dll). This was written entirely in Visual Basic.NET using Visual Studio 2003 if I recall? It was my first Visual Basic.NET 2003 applications at the time. I've since upgraded the code to VS2005, VS2008 and will probably move it to 2010 when it comes out. After Visual batariBasic this is probably the most involved application I've publicly shared. In the end I did post a corrected 5200 binary here. I wonder if the cartridges in the Atari Age store still have this bug? This was caught in time before the final 7800 binary/cartridge was released. Anyway I finally shared it here.

I’ve been a member of Atari Age since 2004 during which I’ve written several applications for the Atari community. I’ve never bothered with a blog, but I figured this would be a good time to start documenting some of those projects and sharing my thoughts on them.

BTW for any Visual bB users there is an "Enable peephole optimizer -O" option in the settings tab so you can turn this on/off. -Jeff

I actually wrote this a couple years ago, but never got around to sharing. I'm on to a new project now and I re-discovered it and figured it's time to share it with the rest of the world. I actually wrote some detailed documentation and it's probably worth a read before getting started. This is what I used to create my xmas hack of Beef Drop back in 2006. What’s Possible The Beef Drop Construction Set is a graphical user interface for creating custom Atari Beef Drop roms, or binaries, and levels, or maps. The Design surface will allow you to modify existing Beef Drop rom images or create entirely new ones from scratch. The Beef Drop Construction Set can also be used to create standalone levels that can be used when compiling Ken Siders original Beef Drop source code. With the Beef Drop Construction Set you will be able to perform actions such as creating custom maps, setting enemy locations and a bunch of other settings. The following table summarizes the features of this release along with a brief explanation Features Load Beef Drop Roms - Allow you to open an existing Beef Drop 32K Binary. Save Beef Drop Roms - Allow you to save a Beef Drop 32K Binary. Load Levels - Allow you to open a Normal, Compressed, or Extended map level (see file formats). Save Levels - Allow you to save a Normal, Compressed, or Extended map level (see file formats). Set Pepper Bonus Locations - Determine where the pepper bonus will appear per level. Set Pepper Bonus Triggers - Determine when pepper bonuses will appear per level. Set Chef Start Locations - Determine starting location of the chef per level. Set End of Level locations - Determine when all the burger parts have fallen ending the level. Set the Enemy Settings - Determine which enemies and their start locations per level. Number of Levels per game - By default Beef Drop has 6 levels per round. This can be custom set to be 1 to 10 levels. Number of starting Lives - Increase or decrease the number of lives granted at the beginning of the game Number of starting peppers - Increase or decrease the number of peppers granted at the beginning of the game Screen shots Prerequisites If you are not running Vista then you'll need to make sure the .NET Framework 2.0 is installed If you are running Vista you may need to RunAs Administrator. If you are logged in with admin privledges or have turned off UAC then it should just work Downloads BDCS_Setup.zip BDCS_Help.zip Thanks for Ken Siders for creating Beef Drop, sharing the source code, and providing additional technical support to help me create this. -Jeff

Can you post the contents of the message window? If you are seeing a blank output.txt then that means the batch file 2600bas.bat is not returning anything. the two most common reasons for that I have seen is that 2600bas.bat is in a file directory tree with a space in the name or the source file .bas is in a directory tree with a space. VisualbB does encapsulate names in quotes to handle this, but I am not sure the batch file you are using will do the same so the safest is to try with directory names without spaces. -Jeff

Would it be okay for someone else to put together an installer, then? I mean, are there any known issues about including DASM, or Stella, or Visual batari Basic, all in one installation package? Or maybe the installation package wouldn't actually include Stella, or Visual batari Basic, but would prompt the user to select, download, and install an emulator and editor as part of the overall batari Basic installation process, and then configure everything to work together. Michael Redistributing VisualbB in a setup package would be fine with me. I just ask that if somebody does it, the thread gets pinned so it's easy for everybody to find. -Jeff

What build of VbB are you using? In older builds sometimes the bin was there just not in the \bin folder. -Jeff

You installed DASM as well? -Jeff

Just got done playing the latest binary. Appears to work great now! Thanks for making this happen -Jeff

Close. Crashes during the first intermission, whether playing 1 or 2 player game. Assuming you get this working without ram, Jinks carts can hold the 128K necessary for say a Pacman Collection Revisited including Super Pacman and Jr. Pacman -Jeff

Ok so I went and tested a 120, 150, 200, and 300 same result Frustrated I tore apart another Jinks cart. It appears to be the RAM. With different RAM all those EPROMs worked, with the other one extra dots or garbage on the screen. Oddly it works fine if I put the Jinks PROM back, so apparently some of the RAM in the Jinks carts are temperamental. So to be clear, with the right memory, the latest binary works with any EPROM I tried. -Jeff

I guess I could have taken a better photo to demonstrate what is happening. The left hand side always as a stream of garbage. That "garbage" is ever changing though it looks like a continuous set of pacman and ghost sprites. This happens even on the attract screen. The right hand side of the maze is just slightly distorted, you can't tell very well from the photo. It doesn't affect gameplay at all since it is outside of the playfield. I tried several EPROMs all had the same result. Wiping them out and going back to the older binary doesn't exhibit this behavior. -Jeff

Dots are all there, but you can see there is distortion on the right and left sides of the board. -Jeff