Atari 2600 BASIC compiler is here!

[Dan Iacovelli]

That animation demo didn't work for me in Stella. It just shows a black screen and sits there.

889713[/snapback]

Can someone provide a binary of that animation demo (I don't have Windows in front of me right now)? I'll see if it runs in the current Stella CVS code. Also, are you using the latest version (1.4.2)?

 

Steve

889754[/snapback]

what animation demo are you talking about?

[+stephena]

That animation demo didn't work for me in Stella. It just shows a black screen and sits there.

889713[/snapback]

Can someone provide a binary of that animation demo (I don't have Windows in front of me right now)? I'll see if it runs in the current Stella CVS code. Also, are you using the latest version (1.4.2)?

 

Steve

889754[/snapback]

what animation demo are you talking about?

889759[/snapback]

I assume it's the one with source code in post #108, and referenced by yuppicide in post #124 that doesn't work with Stella.

 

Steve

[Dan Iacovelli]

That animation demo didn't work for me in Stella. It just shows a black screen and sits there.

889713[/snapback]

Can someone provide a binary of that animation demo (I don't have Windows in front of me right now)? I'll see if it runs in the current Stella CVS code. Also, are you using the latest version (1.4.2)?

 

Steve

889754[/snapback]

what animation demo are you talking about?

889759[/snapback]

I assume it's the one with source code in post #108, and referenced by yuppicide in post #124 that doesn't work with Stella.

 

Steve

889760[/snapback]

 

It worked for me on pcaewin2.6

[+stephena]

That animation demo didn't work for me in Stella. It just shows a black screen and sits there.

889713[/snapback]

Can someone provide a binary of that animation demo (I don't have Windows in front of me right now)? I'll see if it runs in the current Stella CVS code. Also, are you using the latest version (1.4.2)?

 

Steve

889754[/snapback]

what animation demo are you talking about?

889759[/snapback]

I assume it's the one with source code in post #108, and referenced by yuppicide in post #124 that doesn't work with Stella.

 

Steve

889760[/snapback]

 

It worked for me on pcaewin2.6

889764[/snapback]

That's good to know. But again, can someone provide me with a binary, as I don't have access to Windows right now to create my own.

[potatohead]

I've attached a binary. --Just wanted to see if people were playing with this or not. (Didn't want to be the only one.)

 

Re: Sprite data I like the format. It pretty much eliminates the need for a sprite editor. Just put your text editor into overwrite mode, move your cursor and hit the 1 or zero key as needed. If I changed anything, it would be to allow different chars to make visualization easier and have the sprite data reversed so you don't have to build them upside down.

 

eg:

 

80 player0:
%00010000
%01000010
%00011000
%10110101
%00011000
%01000010
%00001000
end
80 player0:
%-o-o----
%--o-----
%o-o-o---
%--o-----
end

 

Re: Assembler

 

Batari has an inline assembly keyword. I tried it with a nop and it worked.

 

80 asm

%nop

%nop

end

 

Perhaps a little documentation here and one could just drop in real assembly language. Only downside is the inability, from what I can see, to target the actual display frame time to change colors, for example. What is there would work great for math routines & other such things that consume more code than they really should right now.

 

Perl sort of does things like this and the inline format has merit over data statements, IMHO. Also, since the output runs through DASM, everybody would be using the same assembly code mnemonics (sp?) and the combine stage of the workflow could just take the text as is and feed it to DASM along with everything else.

 

Adding the data statement would help for music and odd timing loops. If you wanted non-linear player motion, or perhaps to encode playfield data for different levels, the data statement would really help with codespace issues. (Have to use if, then or random numbers right now.) --Ugly

 

For game logic, this easy basic really is good. I would love an if, then else and a case statement. If the latter is to tough, let us goto based on the value of a variable.

 

Eg:

 

10 x = rand

20 if x < 5 then 10

30 x = x + 5 : x = x * 2 : x = x + 60

40 goto x

50 (whatever)

66 do something different

67 goto 100

68 do someting

69 goto 100

70 do something

71 do something else

72 goto 100

100 drawscreen

 

The old atari 8 bit basic had this and it worked really well for a lot of things. When I was a kid, I wrote a morse code program that would take input from the keyboard and output morse code sounds. It took the ascii value of the char to be output as morse, did some basic math on it, then wrote a bunch of little routines that did the right thing for each char, for example.

 

If then, * data and an array would have worked too, but this was easy. Given the rom only environment, the goto x thing would come in really handy here I think.

 

I've bumped into a coupla things that don't work and a bug. For an alpha, this thing rocks. Just about every line of code I've written worked great! (Amazing really.)

 

Anyway, the following appears to compile, but does not function correctly:

 

10 x = x + 1 : if x > 10 then x = 10

 

(Have to start a line with an if, then) --- Not a big deal, just FYI.

 

(assume playfield pixel is off)

 

10 pfpixel x y on : pfpixel x y on

 

(Playfield pixel should be on, but it's actually toggled.)

 

In the asm, I saw EOR. This should be OR or AND as the case may be. Probably a cycle count issue, but makes some programming difficult because one can't easily know the state of a pixel.

 

Oh, under the catagory of things to add:

 

pfpixel x y z

 

with z being true or false depending on the pixel located by x and y. This would help a lot, when used in combination with the collision register for handling things like shooting walls, etc...

 

I'll have a coupla more demos coming over the next few days. Honestly, I think this thing is great fun and will probably get an actual game complete once I've pushed the limits a little bit to know what is possible right now. (More than we think at first.) I'm spending an hour or so each day futzing with it to see how different ideas might be coded.

 

I've been posting my stuff because I want to see this project go somewhere. (Please, please consider a 7800 port someday.... The kernels possible on the 7800 would really make this shine! --and would still be very 2600 like in appearance and overall feel.)

 

Anyone else write anything cool? C'mon share and share alike!

 

 

animation.zip

 

Interesting this does not work. The text posted is the same compiled into the binary. I'll go over it today sometime to be sure. I'm running Linux and using Stella as my emulator. This thing is sweet. I open a few windows, edit a short run script and go. Make a change to the code, cursor over another window and type run. Bam, about a second later I'm looking at the code running in Stella. I'm totally happy in this regard. (Completely thrilled this works in Linux. I have a windows machine, but don't do anything fun on it. --Work machine.)

 

Just to be goofy, I'm going to compile DASM on my IRIX box this week. Then I can say I'm doing Atari development on an SGI workstation. (Stella works already.) Thanks again for the cross platform support. It means a lot.

Edited July 11, 2005 by potatohead

[Dan Iacovelli]

I couldn't get bin it's bin form so I had to zip it

Untitled.26b.zip

[potatohead]

I couldn't get bin it's bin form so I had to zip it

889772[/snapback]

 

 

We've got two binaries of the same thing on different platforms now. (I'm assuming.) I haven't checked, but are they different?

 

Also, for Linux people I've attached the Linux binary of the compiler. DASM comes with one already done. (Thank you!) I used the static linked one and it worked for me. Also, Linux Stella is attached. Maybe we could get this stuff on the budding web page for this project.

 

2600basic_linux.zip

 

stella_linux.zip

 

Unzip the compiler package, then just copy the attached binary into the same working directory and you should be good to go. Same with Stella.

[+stephena]

Interesting this does not work.  The text posted is the same compiled into the binary.  I'll go over it today sometime to be sure.  I'm running Linux and using Stella as my emulator.  This thing is sweet.  I open a few windows, edit a short run script and go.  Make a change to the code, cursor over another window and type run.  Bam, about a second later I'm looking at the code running in Stella.  I'm totally happy in this regard.  (Completely thrilled this works in Linux.  I have a windows machine, but don't do anything fun on it.  --Work machine.)

 

Just to be goofy, I'm going to compile DASM on my IRIX box this week.  Then I can say I'm doing Atari development on an SGI workstation.  (Stella works already.)  Thanks again for the cross platform support.  It means a lot.

889771[/snapback]

Thanks for incuding the binary. But of course, since I don't have access to Windows right now I can't test it. So I don't know why I asked for it right now

 

As for Stella in IRIX, what version are you using? Would you be interested in occasionally compiling the latest CVS code, to make sure it still works in IRIX?

 

Steve

[+stephena]

I couldn't get bin it's bin form so I had to zip it

889772[/snapback]

Unzip the compiler package, then just copy the attached binary into the same working directory and you should be good to go. Same with Stella.

889783[/snapback]

The version of Stella you're including is probably dynamically linked, and won't work with other distros. I think I'll add a static compile option to Stella CVS, so we can generate a static binary.

 

Steve

[potatohead]

I couldn't get bin it's bin form so I had to zip it

889772[/snapback]

Unzip the compiler package, then just copy the attached binary into the same working directory and you should be good to go. Same with Stella.

889783[/snapback]

The version of Stella you're including is probably dynamically linked, and won't work with other distros. I think I'll add a static compile option to Stella CVS, so we can generate a static binary.

 

Steve

889791[/snapback]

 

Thanks!

 

I can probably compile on IRIX for you. That might be how I got the version on the machine running. --It's been a while.

 

Here is a rough version of ooze. It works, but you better keep up with the ooze, or it starts to run through happy fun memory land, affecting the score, playfield and other things!

 

It's got a firing sound, hardware collision for the playfield ooze, and 5 rows of ooze in the center of the screen. Use joystick 0 left & right, button to fire away!

 

UPDATE: This is now the improved version with score, error correction and far better play balance. Should be able to play for as long as you like with no issues.

 

better_ooze.zip

Edited July 12, 2005 by potatohead

[+batari]

Perhaps a little documentation here and one could just drop in real assembly language.  Only downside is the inability, from what I can see, to target the actual display frame time to change colors, for example. 

Not sure what you mean here... can you explain further?

Adding the data statement would help for music and odd timing loops.  If you wanted non-linear player motion, or perhaps to encode playfield data for different levels, the data statement would really help with codespace issues.  (Have to use if, then or random numbers right now.)  --Ugly

I can probably add a data statement - it won't work exactly as it does in other BASICS, though, but rather closer to the way data tables are accessed in asm... but it won't be that hard to use.

For game logic, this easy basic really is good.  I would love an if, then else and a case statement.  If the latter is to tough, let us goto based on the value of a variable. 

Else is in the todo list. I'm also working on something like a case statement - an on...goto. I've already coded the asm for it - I just need to put it in the compiler.

 

Basically it's like this:

 

on x goto 100 200 300 400

 

so it replaces if x = 0 then goto 100... if x = 1 then goto 200... and so on. goto x would require much more complicated logic, and wouldn't support planned alphanumeric line numbers.

 

I've bumped into a coupla things that don't work and a bug.  For an alpha, this thing rocks.  Just about every line of code I've written worked great!  (Amazing really.)

 

Anyway, the following appears to compile, but does not function correctly:

 

10 x = x + 1 : if x > 10 then x = 10

 

(Have to start a line with an if, then)  --- Not a big deal, just FYI.

 

(assume playfield pixel is off)

 

10 pfpixel x y on : pfpixel x y on

 

(Playfield pixel should be on, but it's actually toggled.)

 

In the asm, I saw EOR.  This should be OR or AND as the case may be.  Probably a cycle count issue, but makes some programming difficult because one can't easily know the state of a pixel.

I'll look into these. Probably are bugs. Probably just logic errors I made somewhere.

Oh, under the catagory of things to add:

 

pfpixel x y z

 

with z being true or false depending on the pixel located by x and y.  This would help a lot, when used in combination with the collision register for handling things like shooting walls, etc...

Sure, should be easy to add. I'd probably do a separate function for this instead of reusing pfpixel.

(Please, please consider a 7800 port someday....  The kernels possible on the 7800 would really make this shine! --and would still be very 2600 like in appearance and overall feel.) 

889771[/snapback]

Sorry, I don't know much of anything about the 7800. But the compiler core could easily be adapted to any 6502 machine if someone else wants to attempt a port. I think one would just need to create new DASM assembly files and headers.

[potatohead]

Perhaps a little documentation here and one could just drop in real assembly language.  Only downside is the inability, from what I can see, to target the actual display frame time to change colors, for example. 

Not sure what you mean here... can you explain further?

 

Lets say I want to change the playfield color. That has to be done on the fly and I'm not sure where to put the inline assembly to do this. I know that the frame is complete after drawscreen, but what about during the frame? I know lots of stuff is happening to build the playfield graphics, is there room for a simple color change? At some point I'll slip one into the assembly and see for myself, but the question remains assuming there is time for such things.

 

Also, would I be able to do?

 

push register onto stack (can't remember off the top of my head if a 6502 can do this --6809 can)

lda #color

sta COLPF

pull register back off stack

 

do I need a return, or just try my best to leave things untouched and leave things at that? Again, the answer is in the assembly file I suppose.

 

 

Adding the data statement would help for music and odd timing loops.  If you wanted non-linear player motion, or perhaps to encode playfield data for different levels, the data statement would really help with codespace issues.  (Have to use if, then or random numbers right now.)  --Ugly

I can probably add a data statement - it won't work exactly as it does in other BASICS, though, but rather closer to the way data tables are accessed in asm... but it won't be that hard to use.

 

That works.

 

For game logic, this easy basic really is good.  I would love an if, then else and a case statement.  If the latter is to tough, let us goto based on the value of a variable. 

 

Else is in the todo list. I'm also working on something like a case statement - an on...goto. I've already coded the asm for it - I just need to put it in the compiler.

 

Basically it's like this:

 

on x goto 100 200 300 400

 

so it replaces if x = 0 then goto 100... if x = 1 then goto 200... and so on. goto x would require much more complicated logic, and wouldn't support planned alphanumeric line numbers.

 

That works too. Between the else and the ongoto, things would be well covered.

 

I've bumped into a coupla things that don't work and a bug.  For an alpha, this thing rocks.  Just about every line of code I've written worked great!  (Amazing really.)

 

Anyway, the following appears to compile, but does not function correctly:

 

10 x = x + 1 : if x > 10 then x = 10

 

(Have to start a line with an if, then)  --- Not a big deal, just FYI.

 

(assume playfield pixel is off)

 

10 pfpixel x y on : pfpixel x y on

 

(Playfield pixel should be on, but it's actually toggled.)

 

In the asm, I saw EOR.  This should be OR or AND as the case may be.  Probably a cycle count issue, but makes some programming difficult because one can't easily know the state of a pixel.

I'll look into these. Probably are bugs. Probably just logic errors I made somewhere.

Oh, under the catagory of things to add:

 

pfpixel x y z

 

with z being true or false depending on the pixel located by x and y.  This would help a lot, when used in combination with the collision register for handling things like shooting walls, etc...

Sure, should be easy to add. I'd probably do a separate function for this instead of reusing pfpixel.

 

That's the big problem with the ooze game proto I've got up right now. Keeping track of the state of everyting is tough. I suppose that's why some folks don't use the hardware collision. IMHO, too much code without it. Fixing the existing function will make things a lot better. Reading pixels will be golden.

 

(Please, please consider a 7800 port someday....  The kernels possible on the 7800 would really make this shine! --and would still be very 2600 like in appearance and overall feel.) 

889771[/snapback]

Sorry, I don't know much of anything about the 7800. But the compiler core could easily be adapted to any 6502 machine if someone else wants to attempt a port. I think one would just need to create new DASM assembly files and headers.

889903[/snapback]

 

I suspected as much. Truth is there is a ways to go with this yet. At some point in the future, if we see success, we can get a 7800 guru to build a kernel (maybe...)

 

Oh, I had an interesting thing happen with some misguided playfield pixel math. The digits on the score changed to other numbers. I don't see the functions for changing those just yet. Looks like we are a peek or poke (or well crafted pfpixel statements) from changing the score.

[+batari]

Oh, I had an interesting thing happen with some misguided playfield pixel math.  The digits on the score changed to other numbers.  I don't see the functions for changing those just yet.  Looks like we are a peek or poke (or well crafted pfpixel statements) from changing the score.

889917[/snapback]

The score variables are near the playfield, and since there's no checking for exceeding the bounds of the playfield, this will wrap into everything else.

 

Maybe I didn't document this well, but the score works now. valid statements could be :

 

score = 1000

 

score = score + 1

 

score = score - 400

 

Basically the compiler will parse 0-999999 for arithmetic with the score.

 

Hopefully, with the next release, I'll make a command reference that describes each command (perhaps it will just be an html file, with each command as a hyperlink) and clicking on the link will give the syntax and a few examples in proper context.

[+batari]

It worked for me on pcaewin2.6

889764[/snapback]

The pf scrolling uses an exotic illegal opcode that's not supported by PCAE, so as long as binaries don't use playfield scrolling (and none so far have) PCAE would work. But I think I will replace these illegals with valid opcodes so that in the next release, PCAE will always work no matter what.

[Dan Iacovelli]

It worked for me on pcaewin2.6

889764[/snapback]

The pf scrolling uses an exotic illegal opcode that's not supported by PCAE, so as long as binaries don't use playfield scrolling (and none so far have) PCAE would work. But I think I will replace these illegals with valid opcodes so that in the next release, PCAE will always work no matter what.

889990[/snapback]

I also have z26 so if theres soemting with scrolling playfeilds I can always use that

so doesn't matter to me.

[potatohead]

It worked for me on pcaewin2.6

889764[/snapback]

The pf scrolling uses an exotic illegal opcode that's not supported by PCAE, so as long as binaries don't use playfield scrolling (and none so far have) PCAE would work. But I think I will replace these illegals with valid opcodes so that in the next release, PCAE will always work no matter what.

889990[/snapback]

I also have z26 so if theres soemting with scrolling playfeilds I can always use that

so doesn't matter to me.

889999[/snapback]

 

Scrolling worked for me on Stella, BTW. I just didn't post the binaries.

[potatohead]

Well, just learned a couple biggies tonight. I'm about to get pretty busy for the next few days, so I thought I would work on some basic this evening while I had the time.

 

Attached is a much more playable version of the ooze mess I posted earlier. I'm going to go ahead and post the basic code here as well. Timing issues are a biggie when programming this thing. It's easy to get race conditions and it's easy to do things out of order and not realize it.

 

Programming in a modular way really helps as you can turn off different parts of the game to isolate problems. Of course this is probably old hat to you 2600 veterans out there, but it's news to me and others fiddling with this system right now.

 

I've commented this one as an example of a semi-practical playable game. The first few bits were really rough and had a lot of problems. This one still has some problems, but it resembles a real 2600 game more than anything else I've done anyway. You can turn off the different elements by rem-ing out the gotos around 200 or so. I also think this is very close to hitting the 4K limit as well. Added a few things and compiler failed

 

If I'm to get credit for something on the Batari Basic page, let it be this program instead of the messy brick game. Prospective new programmers will benefit far more from this than they would the other program.

 

1 rem smartbranching on
2 rem init code set intial values here executed only on reset or initial 
3 rem start.
4 rem
5 rem x, y = player position -- w, v = bullet position -- b = bullet launched
6 rem p bullet latch --once launched, stays launched  
7 rem a,g,c,d,e = ooze depth variables -- h m = rand vars for ooze rate
8 rem
9 rem
10 x = 50 : y = 89 : w = 60 : v = 60 : b = 0 : p = 0
11 a = 0 : c = 0 : d = 0 : e = 0 : g = 0 : h = 254 : k = 0 : m = 3
12 AUDC0 = 13 : q = 50 : r = 30
22 pfvline 0 0 10 on
23 pfvline 31 0 10 on
49 rem
50 rem begin main game loop executes 60 times / sec NTSC
51 rem
60 COLUPF = 90 : COLUP0 = 120 : scorecolor = 15 : COLUP1 = 47 : h = rand
70 player1x = w : player1y = v : player0x = x : player0y = y
80 player0:
%01000010
%11100111
%11111111
%01111110
%00111100
%00011000
%00011000
%00011000
end
85 player1:
%00011000
%00010000
%00001000
%00010000
%00001000
end
99 rem
100 rem end display loop setup code, time to draw the screen
101 rem
200 drawscreen
205 rem
207 rem call each part of the game so that it gets done each frame
210 goto 1000
220 rem player movement
230 goto 1100
235 rem bullet movement and sound
240 goto 1300
245 rem draw some ooze
250 goto 1600
255 rem on bullet collision, erase some ooze
260 goto 2000
265 rem increase game difficulty
500 goto 50
550 rem do it all over again, and again, and again....
1000 if joy0left then x = x - 1
1010 if joy0right then x = x + 1
1020 if x < 35 then x = 35
1030 if x > 147 then x = 147
1040 goto 220
1100 if p = 1 then 1140
1120 if INPT4 < 15 then b = 1 : p = 1 : AUDV0 = 10
1140 if v > 5 then v = v - 4
1160 if b = 0 then w = x : v = y - 8 : p = 0 : AUDV0 = 0
1180 AUDF0 = v / 2
1200 if v < 5 then b = 0 : AUDV0 = 0
1220 goto 235
1300 k = rand
1305 m = m + 1
1307 if m > q then m = 0 : goto 1310
1309 goto 1520
1310 if v < 80 then 1520
1312 if k > h then pfpixel 11 a on : a = a + 1
1315 k = rand
1320 if k > h then pfpixel 13 g on : g = g + 1 
1325 k = rand
1340 if k > h then pfpixel 15 c on : c = c + 1
1345 k = rand
1360 if k > h then pfpixel 17 d on : d = d + 1
1365 k = rand
1380 if k > h then pfpixel 19 e on : e = e + 1
1400 if a > 8 then a = 8
1410 if g > 8 then g = 8
1420 if c > 8 then c = 8
1430 if d > 8 then d = 8
1440 if e > 8 then e = 8
1520 goto 245
1600 rem
1620 if CXP1FB > 64 then 1635
1630 goto 255
1635 k = w - 28 : k = k / 2 : k = k / 2
1640 if k = 11 then a = a - 1 : pfpixel 11 a off : b = 0 : score = score + a
1650 if k = 13 then g = g - 1 : pfpixel 13 g off : b = 0 : score = score + g
1660 if k = 15 then c = c - 1 : pfpixel 15 c off : b = 0 : score = score + c
1670 if k = 17 then d = d - 1 : pfpixel 17 d off : b = 0 : score = score + d
1680 if k = 19 then e = e - 1 : pfpixel 19 e off : b = 0 : score = score + e
1690 if a < 1 then a = 1
1692 if g < 1 then g = 1
1694 if c < 1 then g = 1
1696 if d < 1 then d = 1
1698 if e < 1 then e = 1
1840 goto 255
2000 rem
2010 r = r + 1
2020 if r > 200 then q = q - 3 : r = 0
2030 if q < 5 then q = 5
2040 goto 265

 

And the binary:

 

better_ooze.zip

[+batari]

I also think this is very close to hitting the 4K limit as well.  Added a few things and compiler failed

Nope, not even close to the 4k limit. Must be some other reason causing it to fail, since I've added an indicator that lets you know how much space is free when compiled, and it says 2262 bytes are free. Considering that the kernel and support routines take up around 1k, the BASIC portion of this actually takes just around 800 bytes.

 

Hopefully whatever is preventing it from compiling will be fixed in the next release, which I should finish in a few days.

 

If I'm to get credit for something on the Batari Basic page, let it be this program instead of the messy brick game.  Prospective new programmers will benefit far more from this than they would the other program.

890161[/snapback]

I'll see if Kirk can replace the existing program with this one.

[potatohead]

I also think this is very close to hitting the 4K limit as well. Added a few things and compiler failed

Nope, not even close to the 4k limit. Must be some other reason causing it to fail, since I've added an indicator that lets you know how much space is free when compiled, and it says 2262 bytes are free. Considering that the kernel and support routines take up around 1k, the BASIC portion of this actually takes just around 800 bytes.

 

Hopefully whatever is preventing it from compiling will be fixed in the next release, which I should finish in a few days.

 

Nice! That presents me with a coupla more questions then. (Since I can write about 3x this amount of code, a real game can happen!)

 

How many letter variables do I get? Is it the alphabet or more....

 

Will there be additional ones, or a peek / poke to squeeze everything out of the RAM I can?

 

Thinking about filling the screen with ooze, but one byte per stack of ooze is expensive. WIll probably have to use nibbles and do some masking and math.

 

There is support for the bit operators right? Can I use hex values? ($ff) ($f0)

 

If a = $fe and I do an a and $f0 , then divide by 16 (four times / 2) I can isolate the upper nibble for an ooze height.

 

Does this work?

 

a = a & $f0

[+batari]

For some reason my reply got posted twice - see the one below.

Edited July 12, 2005 by batari

[+batari]

How many letter variables do I get?  Is it the alphabet or more....

 

Will there be additional ones, or a peek / poke to squeeze everything out of the RAM I can?

26 is all there are. Basically all of the 102 bytes are reserved for something else.

 

But depending on the game, you may be able to use some of these reserved bytes for other purposes. Since you're not using the ball (and can't, actually), you can use ballx, bally, and ballheight for general storage right now. There are a few more scattered bytes here and there that you can use if you're not using certain features, but you'll need to use inline asm to get to all of them.

 

Also, you can use temp1 to temp6 for temporary storage - but whatever you put there will be obliterated when you call drawscreen, and the playfield routines take temp1-temp3 (as I recall, may be wrong.)

 

With the next version, however, you will be able to get to the extra bytes without resorting to inline asm. I will include a section on "advanced programming" or something like that to describe how to access any unused bytes.

 

There is support for the bit operators right?  Can I use hex values?  ($ff) ($f0)

 

If a = $fe and I do an a and $f0 , then divide by 16 (four times / 2) I can isolate the upper nibble for an ooze height.

 

Does this work?

 

a = a & $f0

890175[/snapback]

Yes, this should work - you can use hex values in your program by using $, or at least I coded this in - I don't recall if I ever tested it though.

Edited July 12, 2005 by batari

[potatohead]

How many letter variables do I get?  Is it the alphabet or more....

 

Will there be additional ones, or a peek / poke to squeeze everything out of the RAM I can?

26 is all there are. Basically all of the 102 bytes are reserved for something else.

 

But depending on the game, you may be able to use some of these reserved bytes for other purposes. Since you're not using the ball (and can't, actually), you can use ballx, bally, and ballheight for general storage right now. There are a few more scattered bytes here and there that you can use if you're not using certain features, but you'll need to use inline asm to get to all of them.

 

Also, you can use temp1 to temp6 for temporary storage - but whatever you put there will be obliterated when you call drawscreen, and the playfield routines take temp1-temp3 (as I recall, may be wrong.)

 

With the next version, however, you will be able to get to the extra bytes without resorting to inline asm. I will include a section on "advanced programming" or something like that to describe how to access any unused bytes.

 

There is support for the bit operators right?  Can I use hex values?  ($ff) ($f0)

 

If a = $fe and I do an and a with $f0 , then divide by 16 (four times / 2) I can isolate the upper nibble for an ooze height.

 

Does this work?

 

a = a & $f0

 

890175[/snapback]

Yes, this should work - you can use hex values in your program by using $, or at least I coded this in - I don't recall if I ever tested it though.

890189[/snapback]

 

Temp1 - temp6 !!?!? That's really handy! Seems there is a lot to this we don't yet know. --Way cool.

 

I can't really use inline asm until I know:

 

what I have to do to preserve code state. Does the system preserve this, or am I responsible for that?

 

the addresses of the variables. (The old ADR command or an equiv would be handy in this regard.

 

when things are happening. --I'll pore over the generated assembly file to help clarify this for myself. Maybe the code between init and drawscreen is clear enough to tell from that.

 

Both the brick game and the ooze game can be easily completed --probably with a goofy title screen of sorts with what you just posted. I was being as frugal as possible assuming worst case where code size is concerned. I'm surprised actually. It's rather efficent (sp) in this regard.

 

Now that I know where I stand code wise, I can make far better use of the variables than I am currently doing. I suspect cycle time will become an issue at some point before storage actually will. Who would have thought?

 

Thanks again for your hard work. I'm actually having a lot of fun right now. Damn cool stuff.

 

Now that the score works, I'm not sure I would trade it for the balls at this point.

 

Will the gaps in the playfield graphics be eliminated at some point? No biggie right now --it works and looks just fine, but lacks that polished 2600 look. Just wondering....

 

I'll test the hex stuff tomorrow most likely.

 

I'm doing subs with goto and that kind of sucks actually. When I tried the gosub, I could not find the proper return, rts statement. Was rejected by the compiler. Any hints there? And where are the return addresses stored? Probably the stack? Meaning I get 1, 2, maybe 3 levels of subroutines?

 

Any thoughts about using the inline asm capability to do things like color changes, or is that asking too much? I think I know enough now to add them into the assembly file, but I really want to produce a well polished game with the basic language only. We all will get the best bang for the buck that way as others will be able to see something real instead of demos...

 

At this point, it's safe to say your project will enable me to get a completed 2600 game done in what I consider to be record time. The learning process is damn fast. As a benchmark, I once took one of the disassembled game listings and worked at understanding it. The flow was obvious after a few days, more subtle issues started to become clear after a solid week of tinkering in my free time.

 

However trying any concepts out took *forever*. Asm is great, and I used to write quite a bit of it for 6502 & 6809 as a teenager. (Saw some success too.) But it's a lot of details any one of which can hose you good for a few days debugging. (With no debugger.) The result being I have not done any serious programming since the 3D graphic viewer project I mentioned here a while ago. Have not done any assembly in probably 20 years. Can still read it well enough, writing it is another matter...

 

With this, I've knocked out 20 short programs to explore this and that over a matter of days. I think this is a very significant reduction in both learning and coding time! The reality is I have nearly all the elements necessary for a well polished game figured out at this point. It's rapidly coming down to simply putting them all together at one time.

 

My apologies for being all over this right now. My time will ebb and flow depending on my other projects and one of the ebb times is coming soon here in a couple days. If I'm doing anything to offend or monopolize this, just whack me on the head with the appropriate clue stick and I'll see the light, otherwise I'm just going to post what I learn here in the hopes it helps others get started.

 

And those of you wondering if that makes sense, know that it totally does at this stage. Download the latest ooze example and check it out. That's probably 8 hours total programming time.

 

Anyone else working on cool code snippets? Feel like posting them ?!?!

 

(Just curious as to what others have tried, that's all.)

Edited July 12, 2005 by potatohead

[+batari]

I can't really use inline asm until I know:

 

what I have to do to preserve code state.  Does the system preserve this, or am I responsible for that?

 

the addresses of the variables.  (The old ADR command or an equiv would be handy in this regard.

 

when things are happening.  --I'll pore over the generated assembly file to help clarify this for myself.  Maybe the code between init and drawscreen is clear enough to tell from that.

No need to preserve any registers - you can do whatever you want with the registers when using inline asm. Well, except the stack pointer.

 

The variables can be accessed all the same in asm. The actual address is determined during assembly by DASM. For instance:

 

LDA #40

STA a

 

is the same as doing a=40, and in fact this is exactly how it's compiled.

 

Basically, all compiled BASIC code is happening during overscan. The code executed during vblank is general housekeeping code like object repositioning and setting score pointers. There is some extra time available in vblank, so I'll try to think of what I can put here so that you have as much time as possible in overscan.

 

I suspect cycle time will become an issue at some point before storage actually will.  Who would have thought?

I've been waiting for someone to hit this limit - so far it seems that nobody has.

Now that the score works, I'm not sure I would trade it for the balls at this point. 

I still hope to get the ball in there - cross your fingers.

Will the gaps in the playfield graphics be eliminated at some point?  No biggie right now --it works and looks just fine, but lacks that polished 2600 look.  Just wondering....

Not in this kernel. Such gaps are common in asymmetric playfields, actually, since doing an asymmetric playfield requires writes on every scanline, and the timing is so tight that there's not enough time to write to the playfield registers while changing the pointers to the next row of pixels. So that's exactly what's happening here.

 

If the primary concern is that the borders look funky, you can instead just set PF0 to give a clean border. try PF0=128 for instance.

I'm doing subs with goto and that kind of sucks actually.  When I tried the gosub, I could not find the proper return, rts statement.  Was rejected by the compiler.  Any hints there? And where are the return addresses stored?  Probably the stack?  Meaning I get 1, 2, maybe 3 levels of subroutines? 

Oops, this appears to be a bug. "return" should compile without errors. There should be 2 or 3 levels of returns allowed depending on what you are doing within the subroutines.

 

EDIT: Just checked, definitely a bug, and I just fixed it. You'll be able to use return in the next release which I should have done in a few days.

Any thoughts about using the inline asm capability to do things like color changes, or is that asking too much?

What do you want to change the color of?

Edited July 12, 2005 by batari

[potatohead]

Any thoughts about using the inline asm capability to do things like color changes, or is that asking too much?

What do you want to change the color of?

890242[/snapback]

 

Thinking of setting the playfield color, and or the background color to something different for the area of the screen that currently holds the score.

 

You mentioned all compiled code happening during the blanking period --must be the vblank period. Time is tight on the hblank, with the playfield graphics being redrawn as they are. (I'll look into PF0 --not sure what that actually does yet.)

 

That's the other color change I was considering for the breakout type game at one point. Getting rid of the borders (or someday using the missles for them, or a player...) would then make for multi-colored bricks. I'm fairly sure this was done for the original commercial game.

[yuppicide]

Know what would be awesome?! Once you get this program more polished?!

 

Let's have some source code for a complete game and get one of the classic magazines to put it in their magazine. Sort of like the old Compute! magazines where you typed in C64 games. The article would list what programs you need, where to get them, and have a full source code with documentation.

 

That Ooze game has some errors too.. one would be when the ooze gets to the bottom most spot it can goto you cannot shoot it away, yet you can shoot the parts behind it. Pretty cool game. Spice it up a little with some sort of increased difficulty.. or maybe the ooze moving back and fourth or something. Maybe different levels. Slap on an intro screen and slap it into a cartridge and I'll buy one heh.

Edited July 12, 2005 by yuppicide