Dragnerok X
-
Posts
741 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Community Map
Posts posted by Dragnerok X
-
-
Here is another build of 2600basic.exe to try. Let me know if it works.
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:01Edit: ...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.
-
Thanks - I guess that didn't do quite what I expected. I realize now that the code I sent will produce output to the screen (through stderr) not to bB.asm. Can you send me the screen output instead?
Here are text files of the output.
-
Well, I am stumped, so I will send you a special debugging version. It simply echoes the contents of the keyword parser and is of no use except for debugging.
Anyway, run this, and send me the bB.asm files it produces.
Here you are.
-
For example, the.golden.ax wrote "Jimmy Ray Says: Just go out in the country, bop bop, awe yeah... I'm goin' to Vegas!". Someone else chimed in and said "loathes Vegas." It is now gone and ax's comment is at the top. Or am I just seeing things?
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.
-
Am I the only one who is noticing that some status updates are disappearing? Why is this happening (if it is. Excuse me if I'm just crazy.)
When people post new updates, their old status disappears. Otherwise, they are deleting their status, then updating it, causing it to be removed.
-
OK, it's not the preprocessor and the compiled output looks fine. It appears that an implicit const statement is passing itself to the keyword parser after the data statement, and that must be failing.
I can't test this because everything is working just fine for me, but if you could test this, let me know if it works. This is just the 2600basic.exe file.
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+5Interestingly enough, Combat DX fails at the same data statement mentioned before. Attached in the .zip are each game's bB.asm file.
-
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.
-
Can you PM me the actual preprocessed output? There might be something funny about it that is failing in Windows 7. Also, can you include the bB.asm file that is generated?
PM sent.
-
I don't have easy access to a Windows 7 PC to troubleshoot the problem, but it might help if we can figure out if it's the preprocessor or compiler causing the issue.
Type preprocess<zombie_chase.bas>zombie_chase.i or something and take a look at the zombie_chase.i file. If you can post the preprocessed output around the data statement, that may reveal something (or rule out the preprocessor.)
Anyway, there is also a java bB that I posted, though it's more of an experiment. If you want to give it a go, grab it here:
http://www.atariage.com/forums/topic/144671-any-interest-in-web-based-bb2600-asm-ide/page__st__24
I would imagine that since it's Java, it will work on anything.
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...
-
Finally some more people are trying my minGW build. There has been very little feedback on this so far.
However, I cannot repeat your problem - everything seems to work fine for me.
When updating bB, install all of the other updates first (like SeaGtGruff's fixes) then do the minGW files last and overwrite any existing files.
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.
-
Try This
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?
-
Not on your part.
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. -
Since you don't want to spend time making carts for it, why don't you see if Atari Age will carry it? This way they deal with cart making, selling, and shipping and we get to buy it.
I would, but isn't there a some expense involved with Atariage (Albert) constantly having to stock it?
-
Of course, this is all assuming we're going with the split-screen idea.
What do you all think? Who's in?
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.
-
When is a cart going to be available for it?
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
). -
Jimmy, just let us know if there is anything we can help out with. I think it would really be cool for us all to work together on a project. I think if we're serious then working out the logistics like Michael was saying would be the next step. Let us know what you think.
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?
-
As for the FB2 portable, I was lead to believe that there is going to be a fb2 portable form wikipedia, the page was last modified August 2007. Maby the person that wrote the article is wrong, but I hope they are not!
From the "Question - FB2 Portable?" thread:
Not as much as I wanted to see it out for Christmas...But no, it is NOT canceled, just put on hold due to issues of licensing and production. With the additional time, the product features have expanded and it will see release in Spring/Summer 08'
Curt
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.
-
Here's a question for someone knowlegable for bB: Are playfield commands still restricted to the last bank? If not, I could have like 100 of them fill up banks 5-8. That'd be cool. Otherwise, I'd have to upgrade to 32k, using only 20k worth of it. I have 4,931 bytes left in all 4 banks, but I'm not done designing mazes for the (first?) 20 levels.
IIRC, I was using bank three for Combat DX, so no.
-
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.
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.
-
Bad news, it looks like I'll have to make a new mini-game. Problems arose and I have no idea how I triggered them or how to fix them, so rather than release a potentially bug-filled program, I decided to scrap the GoSub Combat mini-game. Well, it was fun while it lasted. No worries, though, as I have an idea for a new mini-game: Sub Racer. It'll be like Street Racer only with submarines. I made a new maze, level 7. If you have more than 9 lives, the game will limit you to 9, so at least I have *some* sense of programming.
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. -
After a recent (fairly successful) switch to Ubuntu on my iBook, I decided I should download Stella. So, I fired up the Synaptic Package Manager as usual, and located it with ease. Everything ran great, however, the release I downloaded was only version 2.2 and I wanted the latest release, 2.4.2 (partly due to the new interface color-scheme, the other half due to that feeling of being ¨up to date¨) . So, I took my hand at compiling it using the Build-Essential tools. It appeared just as the older release had in the Games menu, but when I ran it, the screen resolution went absolutely out-of-whack, which ironically, didn´t happen with the older release. Have I just compiled something wrong? Any help would be appreciated.
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? -
After a recent (fairly successful) switch to Ubuntu on my iBook, I decided I should download Stella. So, I fired up the Synaptic Package Manager as usual, and located it with ease. Everything ran great, however, the release I downloaded was only version 2.2 and I wanted the latest release, 2.4.2 (partly due to the new interface color-scheme, the other half due to that feeling of being ¨up to date¨) . So, I took my hand at compiling it using the Build-Essential tools. It appeared just as the older release had in the Games menu, but when I ran it, the screen resolution went absolutely out-of-whack, which ironically, didn´t happen with the older release. Have I just compiled something wrong? Any help would be appreciated.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
[SOLVED] Windows 7 (64-bit) bB Compilation Issue
in batari Basic
Posted · Edited by Dragnerok X
Sorry NE146, but Batari has beat you to it.