My batari Basic personal help page is 'done'

[+Random Terrain]

As I said in a few threads, I have been working on my own adapted version of the help file so I can understand it better. I rearranged things and added more links and changed some big words and jargon to more common words so I won't have to decode them every time. I'm going through the page again a few more times to catch things I might have missed, but I think it's done enough to let others see it now:

 

http://www.randomterrain.com/atari-2600-me...c-commands.html

 

I don't know if it will help anyone besides me. If it helps, great, if not, you always have the original. I'm going to try my best to keep the page updated, so expect the page to change over time.

Edited June 25, 2006 by Random Terrain

[retrocon]

Holy Moley, those are some nice docs

[potatohead]

As I said in a few threads, I have been working on my own adapted version of the help file so I can understand it better. I rearranged things and added more links and changed some big words and jargon to more common words so I won't have to decode them every time. I'm going through the page again a few more times to catch things I might have missed, but I think it's done enough to let others see it now:

 

http://www.randomterrain.com/a2m/bbcommands.html

 

I don't know if it will help anyone besides me. If it helps, great, if not, you always have the original. I'm going to try my best to keep the page updated, so expect the page to change over time.

905382[/snapback]

 

Nice! I really like the color chart.

 

I got something I really needed out of your efforts right away. Somehow I missed this nugget:

 

dim var1=playfield+44

 

dim var2=playfield+45

 

dim var3=playfield+46

 

dim var4=playfield+47

 

I *need* some extra storage right now and it was there the entire time! Sweet. There is the ball area too, but I'm going to leave that be as my game will probably develop through the next version or so.

 

 

I've a coupla things you might consider putting into your update queue: (Of course, word this stuff as you choose to, I'm just trying to help fill in gaps.)

 

If then:

 

Put into numerical terms, the result of any comparison that equals a zero is false, with all other numbers being true. You more or less say this, but you were so focused on clarity (which you did a great job on!), this might make sense to say outright.

 

 

Drawscreen:

 

Batari posted some metrics for the big time consumers, here they are

 

pfpixel: 80 cycles

pfscroll left/right: 500 cycles

pfscroll up/down: 650 cycles every 8th time it's called, 30 cycles otherwise

pfvline: 230-600 cycles depending on length (Approx 200+34*length)

pfhline: 250-1500 cycles depending on length (Approx 210+42*length)

 

I ran out of time trying to clear the playfield with pfline commands. Maybe put these cycle counts in with the command descriptions?

 

Objects:

 

The order of the bytes that define the sprite appear visually, in your basic program, upside down from their on screen appearance.

 

Again, well done and appreciated. Bookmarked on my machine for sure.

[+Random Terrain]

Nice!  I really like the color chart. 

 

I got something I really needed out of your efforts right away.  Somehow I missed this nugget:

 

dim var1=playfield+44

 

dim var2=playfield+45

 

dim var3=playfield+46

 

dim var4=playfield+47

 

I *need* some extra storage right now and it was there the entire time!  Sweet.  There is the ball area too, but I'm going to leave that be as my game will probably develop through the next version or so.

 

 

I've a coupla things you might consider putting into your update queue:  (Of course, word this stuff as you choose to, I'm just trying to help fill in gaps.)

 

If then:

 

Put into numerical terms, the result of any comparison that equals a zero is false, with all other numbers being true.  You more or less say this, but you were so focused on clarity (which you did a great job on!), this might make sense to say outright.

 

 

Drawscreen:

 

Batari posted some metrics for the big time consumers, here they are

 

pfpixel: 80 cycles

pfscroll left/right: 500 cycles

pfscroll up/down: 650 cycles every 8th time it's called, 30 cycles otherwise

pfvline: 230-600 cycles depending on length (Approx 200+34*length)

pfhline: 250-1500 cycles depending on length (Approx 210+42*length)

 

I ran out of time trying to clear the playfield with pfline commands.  Maybe put these cycle counts in with the command descriptions?

 

Objects:

 

The order of the bytes that define the sprite appear visually, in your basic program, upside down from their on screen appearance.

 

Again, well done and appreciated.  Bookmarked on my machine for sure.

905590[/snapback]

Most of the original text is unchanged. I didn't do much to it except rearrange things and I changed a few big words to more understandable ones, but I will add the stuff you mentioned. Thanks for this stuff and please let me know if there are other things I should add to the page to make it better (more helpful).

 

After making these changes, the next thing might be to make some kind of simplified sound chart. Speaking of sounds, I hope someone makes a program or two that helps you make sound effects and music and then spits out the batari Basic code. Maybe the programs would look a little like this:

 

[attendo]

Very nice looking help file you made there!

[supercat]

In discussing "BCD compliant numbers" you need to make clear that for ANY number greater than nine, the result of adding to score will not be the "normal" result. For examle, if a=50, then saying "score=score+a" will add 32 to the score.

 

BTW, one thing that might be helpful would be an "add to score" function which could add or subtract a variable to the ones, tens, hundreds, thousands, ten-thousands, and maybe even hundred-thousands place.

[chad5200]

In the TIA section for NUSIZ0 and NUSIZ1... is this wrong?

 

Value: Effect:

$0x (x means don't care) missile = 1 pixel wide

$1x missile = 2 pixels wide

$1x missile = 4 pixels wide

$1x missile = 8 pixels wide

[+Random Terrain]

In the TIA section for NUSIZ0 and NUSIZ1... is this wrong?

 

Value:                    Effect:

$0x (x means don't care)  missile = 1 pixel wide

$1x                       missile = 2 pixels wide

$1x                       missile = 4 pixels wide

$1x                       missile = 8 pixels wide

906433[/snapback]

Already been fixed. Hit refresh.

 

A nice person helped me fix those errors, but I missed that part. I fixed that section right before you posted though. I'm looking for more errors and making some more adjustments. I recently added some color info below the color chart too.

Edited August 8, 2005 by Random Terrain

[s0c7]

This is extremely well done. You've done your part to lower the bar for newcomers to enter the scene. I hope a few more will after looking at your docs.

[+Random Terrain]

In discussing "BCD compliant numbers" you need to make clear that for ANY number greater than nine, the result of adding to score will not be the "normal" result.  For examle, if a=50, then saying "score=score+a" will add 32 to the score.

 

BTW, one thing that might be helpful would be an "add to score" function which could add or subtract a variable to the ones, tens, hundreds, thousands, ten-thousands, and maybe even hundred-thousands place.

906232[/snapback]

I meant to reply, but I forgot until now. I still don't understand BCD compliant numbers, so it's hard for me to convert the info into something a little more understandable. I don't even understand what you posted there yet.

[potatohead]

In discussing "BCD compliant numbers" you need to make clear that for ANY number greater than nine, the result of adding to score will not be the "normal" result.  For examle, if a=50, then saying "score=score+a" will add 32 to the score.

 

BTW, one thing that might be helpful would be an "add to score" function which could add or subtract a variable to the ones, tens, hundreds, thousands, ten-thousands, and maybe even hundred-thousands place.

906232[/snapback]

I meant to reply, but I forgot until now. I still don't understand BCD compliant numbers, so it's hard for me to convert the info into something a little more understandable. I don't even understand what you posted there yet.

906572[/snapback]

 

I've been using your page today and really like it. Since you did so much work, I thought maybe I would take a quick swing at BCD numbers for you.

 

Basically BCD numbers are 8 bit hexadecimal numbers, but only the ones that look like ordinary base 10 numbers are used. The CPU has a special mode that works with these numbers, as if they were actually base 10 numbers.

 

So lets take the number 15. In base 10, each digit is powers of 10. In binary it's powers of 2 and you know that looks like this: %0000 1111. And in hex, it looks like this: $0f. To understand BCD numbers, you need to know how hex numbers are represented in a byte. The bits of a byte can be divided evenly into nibbles, each nibble being 4 bits. Those 4 bits represent one of sixteen hexadecimal digits 0 - f.

 

BCD numbers are the hex numbers whose digits are only numbers, not letters. Getting back to the number 15 in BCD, it looks like this: $15.

 

If the cpu is not in bcd mode, and the program adds $5 to $15, the result would be $1f. If the cpu is in bcd mode, then the answer would be $20.

 

I put the '$' on the numbers to show they are hex numbers, representing the upper and lower nibbles of a byte in memory. --and they are, with the difference being how the CPU handles addition and subtraction operations.

Binary            Decimal           Hex          BCD
0000 0000          0                 $00             00
0000 0001          1                 $01             01
.
.
.
0000 1001          9                 $09             09
0000 1010          10               $0A             10     =     0001 0000
0000 1011          11               $0B             11     =     0001 0001
0000 1100          12               $0C             12    =     0001 0010
.
.
.
0001 0011          19               $13             19      =    0001 1001
0001 0100          20               $14             20      =    0010 0000

 

 

The number 10, in the little chart above is instructive because it shows the difference between ordinary hex, decimal and binary numbers. When the CPU is in BCD mode, adding 1 to the BCD number $09, results in the BCD number $10. The actual value of the bits, equal 16 however.

 

Counting up, works in the normal fashion until we again reach a number with a 9 for it's lower digit. Looking at the actual value of the bits for 19 BCD and 20 BCD shows a large jump that skips over all the other numbers that would have hex letter digits. ( $0a, $b0, etc...)

 

Looking at it another way, in hex only:

Hex    Bcd
00        00
01        01
.
.
.
09        09
0a        10
0b        11

 

The whole point of this is to create a simple way for the CPU to be able to represent base 10 numbers and allow math operations to be done on them. It's wasteful because a byte can only hold numbers between 0 and 99 instead of the larger 0-255 range the binary and hex representations allow.

 

When working with large integer numbers, such as the scores in our games, BCD makes a lot of things really easy. When the program says score = score + 10, the CPU can easily add 10 to the score, without conversion.

 

Lets say the score is stored in two bytes. That would give us a score between 0 and 65535. Adding 10 means, converting the decimal number 10 to a binary/hex representation useable by the CPU. That number would be, $0a or 0000 1010. The add is then done, then the result needs to be shown on screen. Since the 2600 depends on shapes stored in the ROM, mapping each graphical, on screen image to the actual numerical digits is complex, without BCD. This means more math to convert the binary numbers into decimal ones and their pointers to the onscreen images.

 

With BCD, this whole process is simple because the digits useable by the CPU are easily mapped to the pointers necessary to graphically display the score. So adding 10 to the score really is just an add, with no other major steps being required. When the score is displayed on screen, the computer can read each digit of the score directly from the bytes it is contained in, while using them as pointers at the same time. Those same two bytes would hold a score range of 0000 - 9999, by comparison. Wasteful, but easy to work with from both a mathmatical and display point of view.

 

Wow, this got long. To sum this up, BCD numbers are used only when the CPU is in BCD arithmatic mode. The whole point of BCD is to allow easy binary representations of decimal numbers without having to do conversions back and forth. BCD wastes a lot of storage space however, because a lot of bits go unused. Bytes hold two digit BCD numbers 00 - 99, instead of the normal 0 - 255 ($00 - $ff) range they are capable of.

Edited August 8, 2005 by potatohead

[+Random Terrain]

Thanks potatohead, I think I understand better, but I'm not clear on how you would add something like 1000 points to the score without screwing it up. I can't even add 1 point to the score without numbers flipping or flopping the wrong direction. I made an if-then to add 1 to the score as long as I held the joystick a certain way and the numbers in the score go crazy.

[potatohead]

Thanks potatohead, I think I understand better, but I'm not clear on how you would add something like 1000 points to the score without screwing it up. I can't even add 1 point to the score without numbers flipping or flopping the wrong direction. I made an if-then to add 1 to the score as long as I held the joystick a certain way and the numbers in the score go crazy.

906848[/snapback]

 

That's because the numbers in variables are not BCD compliant numbers. If you say score = score + 1, the bb compiler will do that operation with BCD numbers. If you say score = score + a, then it won't.

 

say a = 10, just like the example above shows.

 

in BCD 10 = 0001 0000

'1' '0'

 

in hex 10 equals = 0000 1010

'0' 'a'

 

See how the bit patterns are different? That's what hoses the score.

 

The compiler does the work when you just write a number, such as 10. When you put your number inside of a variable, the compiler can't do that, thus the number becomes an ordinary 8bit number from 0 - 255.

Edited August 8, 2005 by potatohead

[+Random Terrain]

Thanks potatohead, I think I understand better, but I'm not clear on how you would add something like 1000 points to the score without screwing it up. I can't even add 1 point to the score without numbers flipping or flopping the wrong direction. I made an if-then to add 1 to the score as long as I held the joystick a certain way and the numbers in the score go crazy.

906848[/snapback]

That's because the numbers in variables are not BCD compliant numbers. If you say score = score + 1, the bb compiler will do that operation with BCD numbers. If you say score = score + a, then it won't.

906999[/snapback]

Thanks, that's the problem though, I'm not using a variable, just the number 1. I used:

 

if joy0right then score = score + 1

When I add 1 to the score repeatedly (or any number), the second number from the right is flipped or mirrored, then the next number is OK and the next one after that is flipped or flopped. It shouldn't do that, right?

[+batari]

if joy0right then score = score + 1

When I add 1 to the score repeatedly (or any number), the second number from the right is flipped or mirrored, then the next number is OK and the next one after that is flipped or flopped. It shouldn't do that, right?

907007[/snapback]

I assume you have set REFP0=8 or REFP1=8, which unfortunately will mirror score digits as well as players. I am aware of this bug, and I will fix this so the score digits are unaffected in the next version.

 

If this isn't the case, I am not entirely sure what has happened.

[+Random Terrain]

I have set REFP0=8 or REFP1=8, which unfortunately will mirror score digits as well as players.  I am aware of this bug, and I will fix this so the score digits are unaffected in the next version.

907061[/snapback]

That's what it is! That's the answer. I took that out and the score went back to normal. Thanks.

[potatohead]

I have set REFP0=8 or REFP1=8, which unfortunately will mirror score digits as well as players.  I am aware of this bug, and I will fix this so the score digits are unaffected in the next version.

907061[/snapback]

That's what it is! That's the answer. I took that out and the score went back to normal. Thanks.

907090[/snapback]

 

Of course. I thought you were seeing garbled junk, which happens when non BCD numbers get involved with the score. (sometimes)

 

Well, at least there is some material here for the next guy.

[+Random Terrain]

I still need to update the page with the info that supercat and potatohead gave me and add a bit to the sound section, but I thought some people might want to know that I have added a conversion utility to change hex to decimal or binary to hex or whatever combination you need. I also added an interactive playfield graph. And I took a couple of hours tonight to make sure the color chart and graph look the same in IE and Firefox. I found out the hard way that <P> tags double the height of cells in Firefox, so I had to get rid of them.

Edited June 25, 2006 by Random Terrain

[+Random Terrain]

That code for the color chart table is large, and there's no good reason for it to remain a table since I'm done messing with it, so I changed it to an image today. I kept a copy of the of the color chart table just in case though.

Edited June 25, 2006 by Random Terrain