Programming Equivalents Tool Has Been Improved

[+Random Terrain]

Maybe I didn't explain it good enough. Say I click bit zero in the byte area, then type 64 in the decimal box, you would expect that clicking bit 4 in the byte area would show bit 6 and bit 4 on, but the byte area remembers that I previously clicked bit 0, so it shows bit 4 and bit 0 as being on. The fix is to make sure the byte area memory is cleared whenever someone types a number into the Decimal, Hexadecimal, Binary, Ternary, Quintal, or Octal box.

[bogax]

I goofed something.
See if this works better.

radix_converter_03_3.html

[+Random Terrain]

I goofed something.

See if this works better.

 

radix_converter_03_3.html

 

 

 

Yep, that seems to work how you'd expect now. Here's a short video showing how it worked before:

 

youtube.com/watch?v=UymO4K4jSlE

http://www.youtube.com/watch?v=UymO4K4jSlE

 

 

And here's a video of what you just posted, showing it working the way you'd expect:

 

youtube.com/watch?v=fhMWfdvZIMU

http://www.youtube.com/watch?v=fhMWfdvZIMU

 

It seems to be perfect now. Thanks. I'll add it to the page in a few minutes.

[+Random Terrain]

It's on the page now:

 

randomterrain.com/atari-2600-memories-batari-basic-tools-toys.html

 

 

Thanks.

[+Gemintronic]

It's on the page now:

 

randomterrain.com/atari-2600-memories-batari-basic-tools-toys.html

 

 

Thanks.

 

That's pretty sweet R.T. The "pixel" drawing area is a good enough solution for my use. I'll just use a piece of graph paper for the other rows of playfield graphics.

[+SpiceWare]

Maybe a pseudo drawing tool that displayed the decimal value for each row. That's what I typically wish for when drawing playfield pixels

 

[X][X][X][X][X][X][X][X] = 255

[X][X][X][X][X][X][X][X] = 0

[X][X][X][X][X][X][X][X] = 255

[X][X][X][X][X][X][X][X] = 0

[X][X][X][X][X][X][X][X] = 255

[X][X][X][X][X][X][X][X] = 0

[X][X][X][X][X][X][X][X] = 255

[X][X][X][X][X][X][X][X] = 0

 

I draw my graphics in code by using this include file.

graphics.h.zip

 

 

Here's 1 frame of the Large Fireball as seen in the source for Stay Frosty:

FireballLargeA:
        .byte zz_XXXXXX_ ; 17
        .byte zzXXXXXXX_ ; 16
        .byte zzXXXXXXXX ; 15
        .byte zzX_X_XXX_ ; 14
        .byte zzX_X_XXX_ ; 13
        .byte zzX_X_XXX_ ; 12
        .byte zzXXXXXXX_ ; 11
        .byte zzX___XXX_ ; 10
        .byte zzXXXXXX__ ;  9
        .byte zzXXXXXX__ ;  8
        .byte zzXXXXXX__ ;  7
        .byte zzXXXXXX__ ;  6
        .byte zz_XXX_XX_ ;  5
        .byte zz_XXX__X_ ;  4
        .byte zz__XX____ ;  3
        .byte zz__X_____ ;  2
        .byte zz___X____ ;  1
        .byte zz________ ;  0
        .byte zz________ ; -1
        .byte zz________ ; -2
        .byte zz________ ; -3
        .byte zz________ ; -4

 

The file contains a buch of definitions :

zz________ = %00000000; $0 0
zz_______X = %00000001; $1 1
zz______X_ = %00000010; $2 2
zz______XX = %00000011; $3 3
zz_____X__ = %00000100; $4 4
zz_____X_X = %00000101; $5 5
zz_____XX_ = %00000110; $6 6
zz_____XXX = %00000111; $7 7
zz____X___ = %00001000; $8 8

 

There's also reversed bit definitions that I use for defining playfield data. I don't know if it'll be helpful for bB coding.

zr________ = %00000000; $00 0
zrX_______ = %00000001; $01 1
zr_X______ = %00000010; $02 2
zrXX______ = %00000011; $03 3
zr__X_____ = %00000100; $04 4
zrX_X_____ = %00000101; $05 5
zr_XX_____ = %00000110; $06 6
zrXXX_____ = %00000111; $07 7
zr___X____ = %00001000; $08 8

 

You should be able to use it in bB, most likely by using the include command (after unzipping the header file of course):

  include graphics.h

[SeaGtGruff]

 

 

I draw my graphics in code by using this include file.

graphics.h.zip

 

 

This is very cool and useful! Thank you for sharing it!

[+Gemintronic]

I appreciate your time and expertise SpiceWare! Unfortunately, I don't think I'm being clear on what my intentions are.

 

batariBASIC divides the playfield into separate variables that can be accessed directly:

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#playfieldvariablechart

 

In order to save space sometimes I place objects semi-randomly on the screen instead of storing a whole playfield. My hope was that Random Terrian would expand his toy to include an 8x8 playfield pixel grid that displays the decimal value for each row. That would make it easier to use those values to draw gravestones, obstacles, etc.. procedurally.

[+SpiceWare]

I appreciate your time and expertise SpiceWare! Unfortunatly, I don't think I'm being clear on what my intentions are.

 

This is how I think you'd use graphics.h with bB to draw a gravestone in the playfield:

var0 = zz___XX___
var4 = zz__XXXX__
var8 = zz__XXXX__

And it looks like you can use the reversed bit definitions as well, for the 2nd and 4th playfield variables of each row. This would also draw a gravestone:

var0 = zz_______X : var1 = zrX_______
var4 = zz______XX : var5 = zrZZ______
var8 = zz______XX : var9 = zrZZ______

[+Random Terrain]

I appreciate your time and expertise SpiceWare! Unfortunatly, I don't think I'm being clear on what my intentions are.

 

batariBASIC devides the playfield into seperate variables that can be accessed directly:

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#playfieldvariablechart

 

In order to save space sometimes I place objects semi-randomly on the screen instead of storing a whole playfield. My hope was that Random Terrian would expand his toy to include an 8x8 playfield pixel grid that displays the decimal value for each row. That would make it easier to use those values to draw gravestones, obstacles, etc.. procedurally.

 

 

An 8 x 8 tool could be made that shows two numbers at the side of it, one normal and one reversed. Then you could use whatever numbers you'd need.

[+Gemintronic]

@SpiceWare Ah! I think I'm starting to get a better understanding of what you just did there!

 

@Random Terrain: please! This kind of format would greatly help my long neglected Adventure/Roguelike Destiny that you took notice of awhile ago!

http://atariage.com/forums/topic/172686-destiny-wip/

[SeaGtGruff]

In order to save space sometimes I place objects semi-randomly on the screen instead of storing a whole playfield. My hope was that Random Terrian would expand his toy to include an 8x8 playfield pixel grid that displays the decimal value for each row. That would make it easier to use those values to draw gravestones, obstacles, etc.. procedurally.

 

The equates defined in SpiceWare's include file could be used in any situation where you'd use a constant or literal, such as "var47 = zz__XXXX__" instead of "var47 = 60." I'm not sure how useful that is by itself, since you could just say "var47 = %00111100," but the "zr" equates would be helpful for writing to the playfield bytes that get reversed.

 

As for "procedurally," I'm not sure what you mean by that-- but since the "zz" and "zr" equates can be used in place of numbers, you could even do something "crazy," such as

 

 

   for a = zz_______X to zzX_______

[SeaGtGruff]

Sorry, I started composing that post before anyone else replied, then had to deal with something before I could finish and post it-- after other people already said the same thing! D'oh!

 

PS -- Trying to edit an existing post in the new forum software stinks.

[+Gemintronic]

The final output or actual code representation isn't as critical as being able to properly create the playfield pixel object and then get its decimal values for later use. For instance, here is my code to draw three gravestones:

 var29 = %00011000 : var10 = %00011000 : var12 = %00011000
 var33 = %00111100 : var14 = %00111100 : var37 = %00111100 : var18 = %00111100 : var16 = %00111100 : var20 = %00111100

.

Notice I actually have to obfuscate it a bit since you really can't visualize those gravestones from the code above. This is fine to me. I'm willing to sacrifice some readability for the code optimization bB does when the same value needs to be stored into multiple variables.

 

The real issue is being able to draw the gravestones and then snatch up their decimal values. My suggested modification to R.T.s toy would handle that PERFECTLY

[+SpiceWare]

I'm not sure how useful that is by itself, since you could just say "var47 = %00111100," but the "zr" equates would be helpful for writing to the playfield bytes that get reversed.

It's easier to "see" what the data is, which is very helpful when you're scrolling through a large source file. Compare this:

        .byte %00111100
        .byte %01011010
        .byte %00100100
        .byte %00011000
        .byte %01111110
        .byte %10111101
        .byte %10111101
        .byte %00111100
        .byte %00100100
        .byte %00100100

with this:

        .byte zz__XXXX__
        .byte zz_X_XX_X_
        .byte zz__X__X__
        .byte zz___XX___
        .byte zz_XXXXXX_
        .byte zzX_XXXX_X
        .byte zzX_XXXX_X
        .byte zz__XXXX__
        .byte zz__X__X__
        .byte zz__X__X__

In the first set of data it takes me a while to recognize the graphic for Timmy. In the second set of data I see Timmy right away.

[bogax]

The final output or actual code representation isn't as critical as being able to properly create the playfield pixel object and then get its decimal values for later use. For instance, here is my code to draw three gravestones:

 var29 = %00011000 : var10 = %00011000 : var12 = %00011000
 var33 = %00111100 : var14 = %00111100 : var37 = %00111100 : var18 = %00111100 : var16 = %00111100 : var20 = %00111100

.

Notice I actually have to obfuscate it a bit since you really can't visualize those gravestones from the code above. This is fine to me. I'm willing to sacrifice some readability for the code optimization bB does when the same value needs to be stored into multiple variables.

 

The real issue is being able to draw the gravestones and then snatch up their decimal values. My suggested modification to R.T.s toy would handle that PERFECTLY

 

Why decimal?

Hex is prettier and binary is easier to see

what's going on.

 

How do you deal with reversed playfield bytes?

[+Random Terrain]

How do you deal with reversed playfield bytes?

 

I'm working on a test page, doing my best to hack your code to have a separate 8 x 8 grid. I've done one extra strip besides your original so far and it seems to be working. My plan is to have two boxes, one with the normal number and another with the reversed number. I was going to Google it, but while you are here, do you know of a good way to reverse the order?

[SeaGtGruff]

It's easier to "see" what the data is, which is very helpful when you're scrolling through a large source file.

 

 

I agree, which is why your graphics.h file will be useful to me.

 

But when I was comparing it to simply using binary, I was thinking more in terms of a statement on a line with other statements-- possibly inside an "if...then"-- in which case it wouldn't be quite as useful. Yes, with "_X" it's easier to see the graphics than with "01"-- but if all the statements don't line up with each other vertically, then the overall "shape" is harder to see anyway, even with the equates.

 

But for data tables, this is excellent!

 

Edit: And for setting playfield bytes where the data needs to be reversed.

Edited September 5, 2013 by SeaGtGruff

[SeaGtGruff]

Why decimal?

Hex is prettier and binary is easier to see

what's going on.

 

Yeah, I always use hex or binary instead of decimal in cases where they make it easier to see what's what-- hex for color values and other situations where the nibble values are important, and binary for things where specific bits are used for specific purposes. I don't understand why some people use decimal values for colors and such-- other than that they apparently have a "fear" of hex and binary, or feel like they don't understand hex and binary well enough. IIRC some people have explained their reluctance to use hex and binary by saying that they don't know how to, or can't quickly/easily, convert hex or binary values to decimal values. But to me that doesn't make any sense, because why would you want to? If you're setting a color register to $46, why does it matter what $46 is in decimal notation?

[bogax]

 

do you know of a good way to reverse the order?

There's probably a more elegant way but this

takes a number and returns a string of the lower

whatever bits.

(128 (2^7) is 8 bits, 32768 (2^15) would be 16 bits etc)

 

 

function rev(p){
function arev(p,q){return (q>=1)?arev(p,q/2)+((p&q)?"1":"0"):"";}
return arev(p,32768);}

Edited September 5, 2013 by bogax

[+Random Terrain]

 

There's probably a more elegant way but this

takes a number and returns a string of the lower

whatever bits.

(128 (2^7) is 8 bits, 32768 (2^15) would be 16 bits etc)

 

function rev(p){
function arev(p,q){return (q>=1)?arev(p,q/2)+((p&q)?"1":"0"):"";}
return arev(p,32768);}

 

 

I know nothing about JavaScript, so it took me a while to figure out what I was doing horribly wrong when I started on the third section, but I got it working. I also figured out that I didn't need to use what you posted above to get the reversed numbers. The answer was already there in the code you provided before, I just had to reverse part of it. The hard part is over. Now I just have to do a lot of copying and pasting and changing dozens of IDs and things. I hope to be finished within the next 6 hours.

[+Random Terrain]

Looks like I'm done:

 

www.randomterrain.com/atari-2600-memories-batari-basic-tools-toys.html

 

 

I'm amazed that it works since I didn't know what in the heck I was doing as I was mangling bogax's code.

[+Random Terrain]

Just fixed it so you can jump right to it:

 

randomterrain.com/atari-2600-memories-batari-basic-tools-toys.html#playfield_variables

 

You might need to refresh/reload the page for it to work.

[+Gemintronic]

Just fixed it so you can jump right to it:

 

randomterrain.com/atari-2600-memories-batari-basic-tools-toys.html#playfield_variables

 

You might need to refresh/reload the page for it to work.

 

That's REALLY awesome R.T.!

 

Doesn't bB use a dollar sign in front of hex numbers? If so, could a $ be placed in front of those hex numbers so bB programmers could just copy and paste the results?

[+Random Terrain]

Doesn't bB use a dollar sign in front of hex numbers? If so, could a $ be placed in front of those hex numbers so bB programmers could just copy and paste the results?

 

Didn't take long to do. Refresh the page:

 

randomterrain.com/atari-2600-memories-batari-basic-tools-toys.html#playfield_variables