Dragnerok X

Sorry NE146, but Batari has beat you to it.

It looks like we have a winner! Combat DX compiles and runs fine, and Zombie Chase *almost* compiles, producing what appears to be a minor error, stating: > "C:\Users\Jimmy\Documents\bB\2600bas.bat" C:\Users\Jimmy\Documents\bB\samples\zombie_chase.bas batari Basic v1.01 (C)2005-2007 2600 Basic compilation complete. DASM V2.20.07, Macro Assembler (C)1988-2003 bytes of ROM space left 91 bytes of ROM space left 91 bytes of ROM space left 91 bytes of ROM space left --- Unresolved Symbol List mul8 0000 ???? (R ) Fatal assembly error: Source is not resolvable. > Process Exit Code: 0 > Time Taken: 00:01 Edit: ...which was easily resolved by placing the line "include div_mul.asm" at the beginning of the file. Indeed, it looks like we're in the clear. Thanks for your help.

Here are text files of the output. Combat_DX.txt zombie_chase.txt

Here you are. bB Assembly Files Part 2.zip

That was me. After posting, I didn't think I truly could project my hatred of Las Vegas in such a small space, so I deleted the status update.

When people post new updates, their old status disappears. Otherwise, they are deleting their status, then updating it, causing it to be removed.

Slightly different results this time. Here's where zombie chase's compilation fails: > "C:\Users\Jimmy\Documents\bB\2600bas.bat" C:\Users\Jimmy\Documents\bB\samples\zombie_chase.bas batari Basic v1.01 (C)2005-2007 (284): Error: Unknown keyword: C Compilation failed. > Process Exit Code: 0 > Time Taken: 00:00 282 rem if temp6{0} then AUDC1=3:AUDF1=0 else AUDC1=3:AUDF1=1 283 rem AUDV1=temp6&3 284 if level{3} then temp1=8 else temp1=20 285 AUDC1=temp1 286 if temp6{0} then AUDF1=temp1+4 else AUDF1=temp1+5 Interestingly enough, Combat DX fails at the same data statement mentioned before. Attached in the .zip are each game's bB.asm file. bB Assembly Files.zip

Jbs30000, you're using a 64-bit operating system, right? Is there any chance you could try out the instructions I posted above (just move your current bB folder to prevent it from getting erased) to verify that this isn't Windows 7 specific? Ignore this, Batari might be onto something.

PM sent.

If this means anything to you, I navigated to the samples directory using the command prompt and ran "preprocess<zombie_chase.bas>zombie_chase.i", which produced a file without error or objection. However, it appears that this new file is exactly identical to the zombie_chase.bas file that it processed. Here's the data line: 540 data gonextlevel 541 1,2,3,4,5,6,7,8,9,$10,$11,$12,$13,$14,$15,$99 542 end ...and so the hunt continues...

That's strange... I tried that, and it's still happening. My Process (Windows 7 Professional x64): * Drag batari Basic 1.0 files (from your website) into the empty "bB" folder. * Download "updates_for_bb_2008y_11m_04_0717t.zip", perform a copy and replace using the updated includes files and the updated 2600bas.bat into the "bB" includes folder and main "bB" directory, respectively. * Download "bB_mingw.zip", copy and replace all files into the main "bB" directory. * Drag the sed.exe file into the main "bB" directory from the sed folder in "bB". * Try compiling zombie_chase.bas in the samples folder in "bB". Environment Variables: C:\Users\Jimmy>set ALLUSERSPROFILE=C:\ProgramData APPDATA=C:\Users\Jimmy\AppData\Roaming bB=C:\Users\Jimmy\Documents\bB\ CLASSPATH=.;C:\Program Files (x86)\Java\jre6\lib\ext\QTJava.zip CommonProgramFiles=C:\Program Files\Common Files CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files CommonProgramW6432=C:\Program Files\Common Files COMPUTERNAME=JIMMY-PC ComSpec=C:\Windows\system32\cmd.exe FP_NO_HOST_CHECK=NO HOMEDRIVE=C: HOMEPATH=\Users\Jimmy LOCALAPPDATA=C:\Users\Jimmy\AppData\Local LOGONSERVER=\\JIMMY-PC MpConfig_ProductAppDataPath=C:\ProgramData\Microsoft\Microsoft Antimalware MpConfig_ProductCodeName=Salt Lake City MpConfig_ProductPath=c:\PROGRA~1\MICROS~3 MpConfig_ProductUserAppDataPath=C:\Users\Jimmy\AppData\Local\Microsoft\Microsoft Antimalware MpConfig_ReportingGUID=396D5BB0-51A2-4E75-AC1C-552010D3D984 NUMBER_OF_PROCESSORS=2 OS=Windows_NT Path=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32 \WindowsPowerShell\v1.0\;C:\Program Files (x86)\QuickTime\QTSystem\;C:\Users\Jim my\Documents\bB\ PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC PROCESSOR_ARCHITECTURE=AMD64 PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 23 Stepping 10, GenuineIntel PROCESSOR_LEVEL=6 PROCESSOR_REVISION=170a ProgramData=C:\ProgramData ProgramFiles=C:\Program Files ProgramFiles(x86)=C:\Program Files (x86) ProgramW6432=C:\Program Files PROMPT=$P$G PSModulePath=C:\Windows\system32\WindowsPowerShell\v1.0\Modules\ PUBLIC=C:\Users\Public QTJAVA=C:\Program Files (x86)\Java\jre6\lib\ext\QTJava.zip SESSIONNAME=Console SystemDrive=C: SystemRoot=C:\Windows TEMP=C:\Users\Jimmy\AppData\Local\Temp TMP=C:\Users\Jimmy\AppData\Local\Temp USERDOMAIN=Jimmy-PC USERNAME=Jimmy USERPROFILE=C:\Users\Jimmy windir=C:\Windows ...after further testing, this problem occurs both in the IDE and directly from the command prompt, with or without sed.

As mentioned above, I have (referring to it as the "MinGW build"). That's when the error shows up. Thanks for the help, though.

[sOLVED]: For any of you who are experiencing issues with batari Basic and Windows 7 / 64-bit versions of Windows, I have attached my working bB folder to this post. Hello, again, citizens of AtariAge! Now that my college coursework is beginning to die down, with winter break almost here, I thought I would once again fire up batari Basic and take another look at a few of the programs I wrote many (it must have been three, by now) years ago. Of the most noteworthy changes that have happened since then, my computers have seen a shift from Windows XP to Windows Vista in 2007 to Windows 7 this past month, running on a 32-bit Pentium 4 to now a 64-bit Pentium Dual-Core processor. This, I'm afraid, has caused compatibility issues to spring up. After I had settled on the Programmer's Notepad as an IDE and got Stella 3.0 up and running, I noticed that Windows, unable to run 16-bit applications, completely refused to run batari Basic 1.0, giving me: > "C:\Users\Jimmy\Documents\bB\2600bas.bat" C:\Users\Jimmy\Documents\bB\projects\Combat_DX.bas This version of C:\Users\Jimmy\Documents\bB\2600basic.exe is not compatible with the version of Windows you're running. Check your computer's system information to see whether you need a x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher. > Process Exit Code: 255 > Time Taken: 00:05 So, after a short search, I stumbled upon the MinGW build recently done by Batari, along with the files from the batari Basic 1.01 update. I then proceded to copy the files from the general update into my bB folder, followed by those in the MinGW build, replacing any duplicates as I went along. Everything seemed to run flawlessly... at first. Once I decided to compile one of my games, Combat DX, I was met with this: > "C:\Users\Jimmy\Documents\bB\2600bas.bat" C:\Users\Jimmy\Documents\bB\projects\Combat_DX.bas batari Basic v1.01 (C)2005-2007 (347): Error: Unknown keyword: B Compilation failed. > Process Exit Code: 0 > Time Taken: 00:00 At first I blew this off simply as a syntax error, possibly forgetting to rem a comment on my part. Strangely enough, however, all that line 347 contained was the end of my first data statement... 345 data pointerlo 346 $24,$1B,$12,$09,$00,$09,$12,$1B,$24,$2D,$36,$3F,$48,$3F,$36,$2D 347 end I have also noticed this in one of the known-working sample programs, Zombie Chase, which coincidence be, also points me to the first data statement as the source of an "error": > "C:\Users\Jimmy\Documents\bB\2600bas.bat" C:\Users\Jimmy\Documents\bB\samples\zombie_chase.bas batari Basic v1.01 (C)2005-2007 (542): Error: Unknown keyword: 2 Compilation failed. > Process Exit Code: 0 > Time Taken: 00:00 540 data gonextlevel 541 1,2,3,4,5,6,7,8,9,$10,$11,$12,$13,$14,$15,$99 542 end I believe I may have found a bug. It appears that I'm not the only one, either. Has anyone else experienced this? Has a fix been released or is there something wrong with my batari Basic installation? bB Windows 7.zip

Really? That's good to know. I'd be more than happy to find some time to polish this off and make a nice presentable, product for the AA store. In fact, I've a few ideas for this I've been thinking about trying, lately (more programs, for one). I'll see if I can come up with a nice demo, showing my new direction (well... revised direction), by this weekend.

I would, but isn't there a some expense involved with Atariage (Albert) constantly having to stock it?

I think I should try to create a simple split-screen tank demo to see if it would be feasible. I thought about the scrolling idea, too, but I'm not sure how it could be made to work. Basically, if each tank/player has his/her own window or half of the screen, then if the two tanks are in the same zone as each other, they would both need to be in both windows, the way the two people in "Tag! You're It!" do. And the way that's done is by using two copies of the players, set at wide spacing. So the scrolling would have to be a zone or "windowful" at a time. For example, if the entire playing area were 3x3 zones in size, as follows: +---+---+---+ | 1 | 2 | 3 | +---+---+---+ | 4 | 5 | 6 | +---+---+---+ | 7 | 8 | 9 | +---+---+---+ then the window would shift from 1 to 2, or 1 to 4, all at once, with the tank seeming to go off one edge of the window and reappear at the opposite edge, like moving from room to room in "Adventure." That could still be pretty neat, especially if the entire playfield is like a maze. For example, even if the two tanks are both in the same zone, there might be a wall between them, and the only way to get to the other side of the wall would be to go off the screen into other zones to find your way around. If possible, it might be interesting for each tank to have a certain number of hit points, and it would lose a point each time it's hit. And maybe each side could have a home base, and you could repair your tank (restore your maximum number of hit points) by making it back to your home base before you got hit and lost your last hit point. Then the strategy would change a bit, because if you have more hit points left than your enemy's tank, you might be more aggressive and try to chase him down and blast him, otherwise you might be more defensive and try to evade him so you won't get blasted and lose your last hit point. When a tank gets destroyed, the replacement tank could be dispatched from the home base, rather than respawning at a random location. Of course, there could also be several different variations to choose from-- a single-screen variation, a multi-screen variation, a single hit point variation, a multiple hit points variation, etc. And as far as variables are concerned, some of the variables might be defined differently depending on which variation is selected. Michael How's progress on said demo (I hope I haven't kept you waiting for a reply )? Something like that would help me (and others) better get a feel for how this would work, so we could make revisions to the previous thoughts as necessary. BTW: The Single/Dual screen idea sounds promising, but how would we separate the two engines during run-time and how might that effect rom space? I'm looking foward to starting this just as much as you are, I just need a good platform to start from.

There probably won't be. The cart idea somewhat disintegrated as I began working on my current project, Combat DX. However, the rom file is still freely available for those who have Superchargers/Cuttle Carts/Krocodile Carts or just want to run it from Stella. I also realize that the framerate, when opening and closing windows is kind of sketchy when run on real hardware. Once I'm able to free up some time to update this thing for bB 1.0, you should see some improvement (maybe even more than that ).

I agree. This would make a pretty good collaborative project. As for the game itself, I think that if we are going split-screen, it's going to be all or nothing (I'm for it if it can be done), so with that in mind, most of the current game should work almost immediatly, but there are a few things we (whoever's going to be working on this project, thus far I'm assuming SeaGtGruff and I, but if you or anyone else could contribute, that's fine too) must consider. First of all, the game could use, as suggested, quite a bit of optimization, not only in terms of rom space by cutting the if-then statements, but even more in terms of of free variables as we incorperate the split-screen side of things/all the logic associated with that (currently, there are only 3 variables free, all of which are split up into sections of bits). Second, it appears the levels I'm currently using may need to be (*Gasp*) shrunk or we'll need to implement some kind of scrolling engine into Michael's T! YI! concept, and I'm not sure how that might effect the game's already somewhat shaky performance, but if something like that could be done (say,your tank would be in the middle of the screen, and everytime your tank moves 8 pixels up, the screen jumps 8 pixels up, thus accounting for the playfield blocks and similar for the other directions) the possibilities for level design would really open up. Finally, some minor physics tweaks may need to be accounted for, for example instead of having the missile destruction borders being the extreme sides of the screen, let them be the sides and the center divider, or perhaps, let them move about the map until they hit a target. Once all of that's finished we could focus on getting the sound up, setting up a decent AI (this should definetly be done AFTER the split-screen system is incorperated, for obvious reasons) and add some final polish, maybe a few menus and/or a title screen and we're done! Of course, this is all assuming we're going with the split-screen idea. What do you all think? Who's in?

From the "Question - FB2 Portable?" thread: So, there is still hope, albeit somewhat sketchy.

Sorry for the somewhat late reply, everyone; I just haven't been here for quite some time, just today thought I should check back (good timing, I guess...). So, to respond, I'd be more than happy than to let you (Michael), along with a team of people, finish Combat DX. To tell you the truth, I've considered taking up the task, now that I'm a bit more free than I was, just before I noticed this; so (I'm probably being a bit repetitive, but) if you need any help, I'm here. Also, as of the last code "clean-up", I was about halfway through sound and was also testing a few AI concepts.

IIRC, I was using bank three for Combat DX, so no.

OK, I'll add Zyx as an Easter egg. It's only 2k. Sub Racer though, seems a perfect candidate for the mini-game, as GoSub 1's was Indy 500. If I can't program a decent Sub Racer, I'll replace it with a Zyx minigame with a GoSub theme (avoid the falling bombs, perhaps?) Good idea. As for the theme, the sub could be underwater (blue background?) possibly dodging sinking mines from the surface. That's just a suggestion, though. Feel free to go anywhere you want with the idea.

That's too bad. If you are absolutely sure you are done with your combat mini game, may I suggest another possiblity (if you haven't gotten too far already with Sub Racer). What about a GoSub-themed version of Zyx (Stickman)? It's an extremely addictive concept, substantially smaller than the fairly heavy-weight Combat DX engine your mini-game is based off of and best of all, it's already programmed.

I have no experience with a PPC port in Linux, but seeing how the older version worked, the newer one should as well. I suggest to delete your $HOME/.stella directory, so that it starts out with clean config files. Also, try compiling the source using the following instructions: 1) Change to the stella source directory: "cd ~/src/stella" (or whereever you decompressed the source code) 2) Build the application: "debuild -uc -us" 3) Answer yes and/or ignore any warnings If it complains about not finding certain header files, make sure you install the relevant packages. In Ubuntu, Stella needs the following development packages installed: libsdl1.2-dev zlib1g-dev libgl1-mesa-dev You don't actually need the last one, but Stella won't have OpenGL support if you don't install it. Thank you. It seems running it through debuild did the trick. One last question, though. Can I safely go about removing the installation files from my home folder, or just move them for access later?