+batari Posted July 15, 2005 Author Share Posted July 15, 2005 Personally, guys, I'd suggest not rushing for too much publicity yet. Let this thing mature a while, it's still so young and raw... 892364[/snapback] Maybe you're right - it might me good to at least wait until this is good enough to call it beta instead of alpha. Quote Link to comment Share on other sites More sharing options...
bliprob Posted July 15, 2005 Share Posted July 15, 2005 Personally, guys, I'd suggest not rushing for too much publicity yet. Let this thing mature a while, it's still so young and raw... 892364[/snapback] Maybe you're right - it might me good to at least wait until this is good enough to call it beta instead of alpha. 892419[/snapback] Slashdot wasn't enough publicity? But yeah, probably would want to wait for the multiple kernels option... or a mad rush of new users will ask over and over about two scores. Quote Link to comment Share on other sites More sharing options...
Dan Iacovelli Posted July 15, 2005 Share Posted July 15, 2005 I think the playfield commands are clear enough for instance: if you do pfhline 1 10 30 you will get a line on the bottom starting in the 1st column 10th row and 30 copies. a more simple comparison is if you compre it to TI basic Playfield commands: Call hchar ( row,column , char, rep) just have to reverse the row and column and drop the char since batari basic doesn't use it. Quote Link to comment Share on other sites More sharing options...
vdub_bobby Posted July 15, 2005 Share Posted July 15, 2005 That's a good idea. Though the format is a little deceiving since some of the playfield bytes have their bits reversed, and I'd probably want to make it a logical bit-to-pixel mapping instead. So there's no reason why I'd have to use %010010... I could use something else that's easier to visualize. What do you think? Well, I think that in BASIC you'd want to hide the weirdness of the bit order of the PF bytes from the programmer. On the other hand, maybe not. But even assigning each 1/4 of the PF separately would still be easier than plotting points and drawing lines. Like this: 95 rem playfieldleft is normal 100 playfieldleft: %11111110 %10000000 %10000000 %10000000 %10000000 %10000000 %10000000 %10000000 %10000000 %10000000 %11111110 105 rem playfieldleftcenter is reversed 110 playfieldleftcenter: %11111110 %00000000 %00000000 %00000000 %00000000 %00000000 %00000000 %00000000 %00000000 %00000000 %11111110 115 rem playfieldrightcenter is normal 120 playfieldrightcenter: %11111110 %00000000 %00000000 %00000000 %00000000 %00000000 %00000000 %00000000 %00000000 %00000000 %11111110 125 rem playfieldright is reversed 130 playfieldright: %11111110 %10000000 %10000000 %10000000 %10000000 %10000000 %10000000 %10000000 %10000000 %10000000 %11111110 To create this screen: 100 playfield: %111111100111111001111111 %100000000000000000000001 %100000000000000000000001 %100000000000000000000001 %100000000000000000000001 %100000000000000000000001 %100000000000000000000001 %100000000000000000000001 %100000000000000000000001 %100000000000000000000001 %111111100111111001111111 Quote Link to comment Share on other sites More sharing options...
+batari Posted July 15, 2005 Author Share Posted July 15, 2005 That's a good idea. Though the format is a little deceiving since some of the playfield bytes have their bits reversed, and I'd probably want to make it a logical bit-to-pixel mapping instead. So there's no reason why I'd have to use %010010... I could use something else that's easier to visualize. What do you think? Well, I think that in BASIC you'd want to hide the weirdness of the bit order of the PF bytes from the programmer. On the other hand, maybe not. 892450[/snapback] I definitely want to hide that weirdness - it's not complicated to understand, it's just annoying. I'll include a mention of the weirdness in the docs, definitely, so those moving on to assembly aren't surprised when things work a little differently. I guess what I meant is that I could use something other than % and 0 and 1, like this: XXXXXXXXXXXXXXX..XXXXXXXXXXXXXXX X..............................X X..............................X X..............................X X..............................X X..............................X X..............................X X..............................X X..............................X X..............................X XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Quote Link to comment Share on other sites More sharing options...
danwinslow Posted July 15, 2005 Share Posted July 15, 2005 (edited) Batari, the parsing issues are going to drive you insane. I am speaking from personal experience. My advice is to set up a real parser now before you get too much kluged in there. It just gets worse as you go along. You need expression trees, BNF, etc. Yah, lex and yacc are good. Cryptic but they work. Actually, you should be able to find pre-made basic parsers out on the net that you could mod. I will see if I can't find a couple and post them. Edited July 15, 2005 by danwinslow Quote Link to comment Share on other sites More sharing options...
+batari Posted July 15, 2005 Author Share Posted July 15, 2005 Batari, the parsing issues are going to drive you insane. I am speaking from personal experience. My advice is to set up a real parser now before you get too much kluged in there. It just gets worse as you go along. You need expression trees, BNF, etc. Yah, lex and yacc are good. Cryptic but they work. 892472[/snapback] This is the plan - but for now I patched up the parsing by preprocessing the input, and the compiler is now much more forgiving about spacing/whitespace or lack thereof. I will definitely need something much better for parsing more complex statements - in this case I agree that this will begin to get away from me before long if I don't bite the bullet soon and learn how to use lex/yacc. Quote Link to comment Share on other sites More sharing options...
kisrael Posted July 15, 2005 Share Posted July 15, 2005 I think a cool feature would be the ability to write to the entire playfield like you write to the players, like this:100 playfield: %111111111111111111111111 %100000000000000000000001 %100000000000000000000001 %100000000000000000000001 %100000000000000000000001 %100000000000000000000001 %100000000000000000000001 %100000000000000000000001 %100000000000000000000001 %100000000000000000000001 %111111111111111111111111 This would make the creation of an adventure game (in the vein of Superman, ROTLA, or Adventure) with multiple screens much easier. 892361[/snapback] That's a good idea. Though the format is a little deceiving since some of the playfield bytes have their bits reversed, and I'd probably want to make it a logical bit-to-pixel mapping instead. So there's no reason why I'd have to use %010010... I could use something else that's easier to visualize. What do you think? 892417[/snapback] Very good thought -- don't make things look alike that aren't. _ and X or something for characters? Also, will this be at the same low resolution as the hline/vline type graphics, or can it be higher? Quote Link to comment Share on other sites More sharing options...
+batari Posted July 15, 2005 Author Share Posted July 15, 2005 I think a cool feature would be the ability to write to the entire playfield like you write to the players, like this:100 playfield: %111111111111111111111111 %100000000000000000000001 %100000000000000000000001 %100000000000000000000001 %100000000000000000000001 %100000000000000000000001 %100000000000000000000001 %100000000000000000000001 %100000000000000000000001 %100000000000000000000001 %111111111111111111111111 This would make the creation of an adventure game (in the vein of Superman, ROTLA, or Adventure) with multiple screens much easier. 892361[/snapback] That's a good idea. Though the format is a little deceiving since some of the playfield bytes have their bits reversed, and I'd probably want to make it a logical bit-to-pixel mapping instead. So there's no reason why I'd have to use %010010... I could use something else that's easier to visualize. What do you think? 892417[/snapback] Very good thought -- don't make things look alike that aren't. _ and X or something for characters? Also, will this be at the same low resolution as the hline/vline type graphics, or can it be higher? 892480[/snapback] Since it's in ROM, it could be higher resolution, but using a higher resolution would also preclude using the pf plotting routines on the same screen. Therefore you would have three choices - one, to use the existing kernel, but have the playfield command copy the data to RAM when it is called. Second, do not use the playfield RAM at all. Playfields would be static, but they could be higher resolution. Third, selectively compile in two slightly different kernels, one for PF in RAM and one for PF in ROM. This would eat up space in the ROM (around 256 bytes to be exact) so it wouldn't be automatic. You can't use the same kernel because there's not enough cycles for indirect indexing, nor is there enough free bytes to store the pointers! I'll think about this some more so I can figure out the best solution. At any rate, If I want to include this sort of flexibility, I will wait until Alpha 0.3 or so to get it in. Quote Link to comment Share on other sites More sharing options...
bliprob Posted July 16, 2005 Share Posted July 16, 2005 I will definitely need something much better for parsing more complex statements - in this case I agree that this will begin to get away from me before long if I don't bite the bullet soon and learn how to use lex/yacc. 892477[/snapback] Take a look at this basic interpreter file. It's been floating around the net for a while (I first compiled in 1993 or so). It's very compatible in some respects (26 vars, etc.) but has loops and a complete expression parser for math. And, it's short enough and simple enough to understand in an hour, something lexx and yacc will never be. I'm happy to help if I can. BAS_INT.txt Quote Link to comment Share on other sites More sharing options...
kisrael Posted July 16, 2005 Share Posted July 16, 2005 Third, selectively compile in two slightly different kernels, one for PF in RAM and one for PF in ROM. This would eat up space in the ROM (around 256 bytes to be exact) so it wouldn't be automatic. You can't use the same kernel because there's not enough cycles for indirect indexing, nor is there enough free bytes to store the pointers! I'll think about this some more so I can figure out the best solution. At any rate, If I want to include this sort of flexibility, I will wait until Alpha 0.3 or so to get it in. 892486[/snapback] Well, especially as you add in support for different kernals for title screens and game play and what not, you should strongly consider (and it shouldn't be too hard) dymanic inclusion/exclusion of commands. If a subroutine isn't used, it'd be nice if it wasn't in the ASM at all...I mean I know right now you have a big chunk before and after and then just have dynamic logic in between, but I think doing "includes" for various chunks is going to become a neccesity. Quote Link to comment Share on other sites More sharing options...
+batari Posted July 16, 2005 Author Share Posted July 16, 2005 Third, selectively compile in two slightly different kernels, one for PF in RAM and one for PF in ROM. This would eat up space in the ROM (around 256 bytes to be exact) so it wouldn't be automatic. You can't use the same kernel because there's not enough cycles for indirect indexing, nor is there enough free bytes to store the pointers! I'll think about this some more so I can figure out the best solution. At any rate, If I want to include this sort of flexibility, I will wait until Alpha 0.3 or so to get it in. 892486[/snapback] Well, especially as you add in support for different kernals for title screens and game play and what not, you should strongly consider (and it shouldn't be too hard) dymanic inclusion/exclusion of commands. If a subroutine isn't used, it'd be nice if it wasn't in the ASM at all...I mean I know right now you have a big chunk before and after and then just have dynamic logic in between, but I think doing "includes" for various chunks is going to become a neccesity. 892601[/snapback] I think what I am going to do is have a header file auto-generated that defines compiler flags to tell what will go in and what won't. Alpha 0.2 already auto-generates a header file for variable aliasing, so including such flags in the header would be trivial at this point. Oh, and stay tuned for Alpha 0.2 so you can put it on the web page - I'll post it shortly. Quote Link to comment Share on other sites More sharing options...
potatohead Posted July 16, 2005 Share Posted July 16, 2005 Very good thought -- don't make things look alike that aren't. _ and X or something for characters? I'm liking all the ideas so far. As for the characters that define the playfield, you could let the user choose... with any two chars they wanted as args. 100 playfield - 0 %-----------------0------------- ...etc. Looking forward to 0.2. Re: playfield.... I really like the idea of the ram playfield. Makes some things really easy. Of course it does not look that great, but with the language having only the two sprites, it's the difference between being able to actually do something and not. As this develops, choices are good. My only comment in this regard would be trying to avoid locking the user into a particular one. eg: static playfield for title screen, dynamic one for game level screen that changes, static one for bonus level that doesn't... Quote Link to comment Share on other sites More sharing options...
+batari Posted July 16, 2005 Author Share Posted July 16, 2005 (edited) Ok... here it is. Just built it minutes ago - I hope it's all there. Some changes are: vastly improved parser - not nearly as sensitive to spacing score calculation improved. slight kernel improvements alphanumeric labels allowed, and labels/linenumbers are now optional. blank lines allowed indexing (array-like feature) implemented data statement implemented fixed bug in inline asm where it was impossible to add labels one boolean now allowed in an if-then (&&,||) ability to access individual bits fixed bug where return command wasn't recognized for-next loops added dim statement for alternate variable names Upon compilation, DASM shows bytes free in ROM removed exotic illegal opcodes that would cause problems in some emulators, like PCAE Included files are now in cr/lf format to patch a limitation of DASM fixed various bugs in pfpixel and pfhline routines on....goto added Fixed problem where duplicate labels were created FAQ and Command reference started. other things I can't remember. I think this should work quite a bit better. But let me know immedately if you find any fatal bugs that cause it to not work at all. EDIT: Quick fixes on both - the cause of the "bus error" should now be gone, and data statements should work. if you downloaded them before, please do so again. batari_basic_alpha2.zip Batari_basic_alpha2_source.zip Edited July 17, 2005 by batari Quote Link to comment Share on other sites More sharing options...
Dan Iacovelli Posted July 16, 2005 Share Posted July 16, 2005 (edited) Ok... here it is. Just built it minutes ago - I hope it's all there. Some changes are: vastly improved parser - not nearly as sensitive to spacing score calculation improved. slight kernel improvements alphanumeric labels allowed, and labels/linenumbers are now optional. blank lines allowed indexing (array-like feature) implemented data statement implemented fixed bug in inline asm where it was impossible to add labels one boolean now allowed in an if-then (&&,||) ability to access individual bits fixed bug where return command wasn't recognized for-next loops added dim statement for alternate variable names Upon compilation, DASM shows bytes free in ROM removed exotic illegal opcodes that would cause problems in some emulators, like PCAE Included files are now in cr/lf format to patch a limitation of DASM fixed various bugs in pfpixel and pfhline routines on....goto added Fixed problem where duplicate labels were created FAQ and Command reference started. other things I can't remember. I think this should work quite a bit better. But let me know immedately if you find any fatal bugs that cause it to not work at all. 892626[/snapback] sounds good batari, I'll d/l it tomarrow will be at my show all day from 9am to 6pm today Edited July 16, 2005 by Dan Iacovelli Quote Link to comment Share on other sites More sharing options...
attendo Posted July 16, 2005 Share Posted July 16, 2005 Actually isn't it supposed to work with z26, or not? I pointed it it to z26, but I always get "file not found...untitled.bin" also, sometimes programs like this open up the last edited program, that's often useful and you really shouldn't have a "clear clipboard" option...no other program does it so it's a little confusion, and who cares about a bit of text stuck in the clipboard anyway? 890870[/snapback] The 2600IDE for 2600Basic is now updated check here for v0.3 It works best with the latest version of Batari's Basic. Removed the clear option, added last file opened and did some other changes. Tried it again with Z26 but it worked fine here, did the compile and run, etc. Im using V2.13 Quote Link to comment Share on other sites More sharing options...
bliprob Posted July 16, 2005 Share Posted July 16, 2005 Fred -- I'm having trouble with .2 without line numbers. The first line of my program is: rem smartbranching on ...and it throws a compilation error: Error: cannot parse line rem Then I got the same thing here: player0x = 50 Error: cannot parse line player0x So I added a space in front of every line that didn't have a label or line number. Is that right? I'm still getting compilation errors. Do you have some sample code for the new features? Quote Link to comment Share on other sites More sharing options...
potatohead Posted July 16, 2005 Share Posted July 16, 2005 (edited) Got a build problem on Linux: [dougd@feona src]$ make all cc -O2 -o 2600bas 2600bas.c statements.c keywords.c /home/doug/tmp/ccZvsD80.o(.text+0x1903): In function `doif': : undefined reference to `pow' /home/doug/tmp/ccZvsD80.o(.text+0x2052): In function `let': : undefined reference to `pow' /home/doug/tmp/ccZvsD80.o(.text+0x2693): In function `let': : undefined reference to `pow' collect2: ld returned 1 exit status make: *** [2600bas] Error 1 I had time to just tweak a little this morning. Removing the (int) let the build continue, but then got this: [dougd@feona src]$ make all cc -O2 -o 2600bas 2600bas.c statements.c keywords.c statements.c: In function `let': statements.c:775: error: invalid operands to binary ^ make: *** [2600bas] Error 1 Assuming the above means a type mismatch which is what the (int) was supposed to take care of ?!?! Does this suggest we need a built in pow function that will output an int value? (Will this vary too much per platform?) I'm happy to chip away at getting this to build this afternoon. If I have not provided enough info, and I'll post more, make you an ssh account... (or whack me with the clue stick, and I make the edits and send the changes!!) Edited July 16, 2005 by potatohead Quote Link to comment Share on other sites More sharing options...
bliprob Posted July 16, 2005 Share Posted July 16, 2005 I've got another problem here. Firstlt -- my compliation error above was caused whitespace AFTER a keyword (i.e. "return " and "x = rand "). That was hugely frustrating to figure out. Watch out for extra whitespace! New problem is with arrays. Attempting to access a[x] and so on. Output from DASM: /Users/rob/desktop/rand-2.bas.asm (888): error: Syntax Error 'a'. /Users/rob/desktop/rand-2.bas.asm (889): error: Syntax Error 'a[x]'. /Users/rob/desktop/rand-2.bas.asm (989): error: Syntax Error 'a'. /Users/rob/desktop/rand-2.bas.asm (990): error: Syntax Error 'a[x]'. I sort of expected to be able to use a variable as an array index -- am I off base here? Quote Link to comment Share on other sites More sharing options...
bliprob Posted July 16, 2005 Share Posted July 16, 2005 I sort of expected to be able to use a variable as an array index -- am I off base here? 892759[/snapback] This is what I'm aiming for: for u=0 to z x = u + 10 pfpixel a[u] a[x] off next Quote Link to comment Share on other sites More sharing options...
bliprob Posted July 16, 2005 Share Posted July 16, 2005 Am I doing something wrong? In the .asm file, it has compiled into: .L020; pfpixel a[u] a[x] off LDX a[u] LDY a[x] I don't know anything about 2600 programming, but I have some creaky 6502 assembly somewhere in my brain, so I'll take a look at the C file and see. Quote Link to comment Share on other sites More sharing options...
+batari Posted July 16, 2005 Author Share Posted July 16, 2005 So I added a space in front of every line that didn't have a label or line number. Is that right? yes. You must indent lines without linenumbers. I'm still getting compilation errors. Do you have some sample code for the new features? 892736[/snapback] There is some in the help.html file. Quote Link to comment Share on other sites More sharing options...
+batari Posted July 16, 2005 Author Share Posted July 16, 2005 (edited) Got a build problem on Linux: [dougd@feona src]$ make all cc -O2 -o 2600bas 2600bas.c statements.c keywords.c /home/doug/tmp/ccZvsD80.o(.text+0x1903): In function `doif': : undefined reference to `pow' /home/doug/tmp/ccZvsD80.o(.text+0x2052): In function `let': : undefined reference to `pow' /home/doug/tmp/ccZvsD80.o(.text+0x2693): In function `let': : undefined reference to `pow' collect2: ld returned 1 exit status make: *** [2600bas] Error 1 892749[/snapback] See above - fixed source (problem was the makefile) posted above. Edited July 16, 2005 by batari Quote Link to comment Share on other sites More sharing options...
+batari Posted July 16, 2005 Author Share Posted July 16, 2005 Am I doing something wrong? In the .asm file, it has compiled into: .L020; pfpixel a[u] a[x] off LDX a[u] LDY a[x] I don't know anything about 2600 programming, but I have some creaky 6502 assembly somewhere in my brain, so I'll take a look at the C file and see. 892835[/snapback] You've run into a limitation - you can assign arrays but currently you can't use then in some functions To fix the above, first reassign the arrays to a fixed variable then call pfpixel. I'll add this to the list for Alpha 0.3. that is, y=a:z=a[x]:pfpixel y z off Quote Link to comment Share on other sites More sharing options...
+batari Posted July 16, 2005 Author Share Posted July 16, 2005 I've got another problem here. Firstlt -- my compliation error above was caused whitespace AFTER a keyword (i.e. "return " and "x = rand "). That was hugely frustrating to figure out. Watch out for extra whitespace! 892759[/snapback] That's annoying - I'll fix this whitespace problem for Alpha 0.3. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.