A few bBasic questions...

[superogue]

Hi People,

 

After doing some vectrex and colecovision programming, i decided to give the atari2600 another shot with the newly release bBasic (awesome project!!!).

 

I've done a few tests, but i have a few questions:

 

- I need to acces data with a 16-bit offset. Right now i can't find a way to define 'normal' (non-fixedpoint) 16-bit vars (i only need 1 or 2 of them) and then use it to acces data, like: offset=670:value=mydata[offset];

Is there currently ANY way to do this??? I think more people would find this useful for a hand full of things (like a musicplayer or animation data,etc.)

 

- I couldn't find a way to adjust object/pf/bg color per scanline, maybe a good idea to include a small array or list of some kind (starty,startcolor,numlines (will automatically be increased). in which you can set the colors which are later handled in the kernel

 

- last but not least:

a way to to 'scale'/extend' the playfield', so you don't have those square blocks, but you can also use it for logos,text,etc. maybe same mechanism (starty, playfield 'scale', num playfieldlines, and maybe pointer to playfield data (so you can point it to static data in rom!!!).

 

Hope anyone here can answer my questions or is able to help implementing these features.

 

Martijn

[+batari]

- I need to acces data with a 16-bit offset. Right now i can't find a way to define 'normal' (non-fixedpoint) 16-bit vars (i only need 1 or 2 of them) and then use it to acces data, like: offset=670:value=mydata[offset];

Is there currently ANY way to do this??? I think more people would find this useful for a hand full of things (like a musicplayer or animation data,etc.)

The problem here is with the 6507 CPU. It only allows a one-byte index register, thus the 256-byte limit for data.

 

Changing the code to automatically allow a 16-bit index would be tough, and would require indirect indexing (so we can change the high byte of the index for counts above 256) and a few bytes of RAM for various other purposes.

 

But realistically, a little bit of hackish coding in bB can help you to achieve such a thing without waiting for compiler updates (that may or may not happen.)

 

(this is an idea, as yet untested, but should (might) work for 1024 byte tables)

 

 dim offset=a.b
 dim mydata1=mydata+256
 dim mydata2=mydata+512
 dim mydata3=mydata+768
 data mydata
 ... more than 256 bytes of data here ...
end

 offset=2.5: rem this is 640/256
 on offset goto first second third fourth
first
  value=mydata[b]:goto here
second
  value=mydata1[b]:goto here
third
  value=mydata2[b]:goto here
fourth
  value=mydata3[b]
here

I assume that you will instead be adding 1 to your offset every frame or something. TO do so, you'd actually just add 1/256 or 0.00390625. yeah, someday I might get 16-bit integers in there too, but up until now I hadn't seen a real need for them.

- I couldn't find a way to adjust object/pf/bg color per scanline, maybe a good idea to include a small array or list of some kind (starty,startcolor,numlines (will automatically be increased). in which you can set the colors which are later handled in the kernel

That's because there isn't one. The problem here is that every last cycle is used up already in the kernel - I can't get anything else in there without taking something out first. Someday I might include options to, for instance. take out the ball in exchange for sprite colors to be changed every scanline, but not until I actually write all of those kernels...

a way to to 'scale'/extend' the playfield', so you don't have those square blocks, but you can also use it for logos,text,etc. maybe same mechanism (starty, playfield 'scale', num playfieldlines, and maybe pointer to playfield data (so you can point it to static data in rom!!!).

967458[/snapback]

Not yet... but this has been discussed and it is on the todo list. Maybe not the next release, but an upcoming one.

 

That said, I really do want to work on bB again, it's just that the last couple of months have been really hectic. I expect things to slow down again soon (like they were in the summertime when all of the bB coding took place...)

Edited November 18, 2005 by batari

[superogue]

Thanks for the workaround.

 

though it will no doubt take much higher number of cycles (i need to look up a total of 8 times per frame), it seems to work fine.

i had to change one thing. if offset was declared as dim offset=d.e

Then, I had to replace "on offset goto ..". by "on d goto ....."

i also put the lookup functionality in a gosub-return construction for easy reading

 

As fo the kernel issues, i have no problem giving up one item for another. you can do it this way that old programs also work. like i mentioned in the kernel-features post.

 

1) - some kind of var/point to attach 'colordata' to (for background a 192byte array in rom', for sprites a 'spriteheight' array of colors in rom )... which during drawing will be read..... you could do it by having vars like p0colordata=mycolordata

 

if you do p0colordata=14 it will just draw the sprite normally with color 14

otherwise it will draw it using the data in mycolordata and increase colordatapointer each scanline.

 

same goes for the background.....

 

===> so in this case, if users make use of the option (checked by seeing if p0colordata is attached to a pointer) it will be handled (but no ballsprite for example), if it points to a simple color, it will set COLUP0 to the color and continue as it does normally

 

Sound like a good solution to me, but let me know what you think...

 

martijn

 

P.S> Is there is no way to do any kind of sprite multiplexing other than interlacing from bBASIC (for example have a sprite start coordinate, if its bigger than otherspritey+spriteheight, it will automatically be multiplexed

 

P.S2> For your kernal memory-structurig problem. I'm assuming you want playerdata to be alligned at 256 and making sure you won't wast memory?

How about defining them from the back-end of the romspace of the main bank or another bank (can be defined with data definition) to the front and let the programmer bankswitch before drawing. 16 sprites per bank * 8 banks for 32kb should be enough to hold all your graphics. and nowadays 27c256s aren't much more expensive than 4kb roms. Only problem i don't know how 'costly' bankswitching is. coming from gameboy DMG/Gameboy color it wasn't that much of a problem. all my game graphics relied on bankswitching.

Edited November 18, 2005 by superogue

[vdub_bobby]

P.S2> For your kernal memory-structurig problem. I'm assuming you want playerdata to be alligned at 256 and making sure you won't wast memory?

How about defining them from the back-end of the romspace of the main bank or another bank (can be defined with data definition) to the front and let the programmer bankswitch before drawing. 16 sprites per bank * 8 banks for 32kb should be enough to hold all your graphics. and nowadays 27c256s aren't much more expensive than 4kb roms. Only problem i don't know how 'costly' bankswitching is. coming from gameboy DMG/Gameboy color it wasn't that much of a problem. all my game graphics relied on bankswitching.

It's a little more complicated than just aligning on page boundaries. The graphics data not only cannot cross page boundaries, they also have to be a certain number of bytes past the page boundaries, typically around 100 bytes past the page boundary. So you end up with a page, often multiple pages, that are only half full of graphics and you have to fit other data and code into the front half of those pages. Which is fairly simple to do, though not always trivial, when coding in assembly by hand, but is pretty sticky to automate.

 

And bankswitching is not costly at all - usually just takes around 10-20 cycles for each switch and not much ROM. However, since there is so little RAM in the 2600, you almost always read your graphics from ROM, so all your graphics have to be in the same bank as the kernel.