Convert to Data File

[RetroFiends]

EDIT:

Despite what the manual seemed to be telling me, I seem to be able to put graphics in banks other than the last bank and it is indeed stored in that bank. Where the manual says that graphics are put into the last bank automatically regardless of where they are called from. Am I missing something here? If I'm able to put playfields in say, bank 3 in addition to bank 4 then I don't even need convert to data. I would still love to figure out what's going on with not being able to compile data-fied playfields, though.

 

Original Message:

Hello everyone. I tried to use convert to data file today, but it just isn't working for me.

I tried the example for this and it wouldn't compile.

I am given an ambiguous syntax error if I use data ANYWHERE it seems.

Am I missing something I need in my installation? That's the only thing I can think of. Otherwise I'm at a loss. I really want that data working :<

Edited August 10, 2013 by RetroFiends

[+Random Terrain]

EDIT:

Despite what the manual seemed to be telling me, I seem to be able to put graphics in banks other than the last bank and it is indeed stored in that bank. Where the manual says that graphics are put into the last bank automatically regardless of where they are called from. Am I missing something here? If I'm able to put playfields in say, bank 3 in addition to bank 4 then I don't even need convert to data. I would still love to figure out what's going on with not being able to compile data-fied playfields, though.

 

Are you looking at the space used after the program is compiled? Maybe the info needs to be updated to be more clear. Sprites and playfields are supposed to get tossed into the last bank when your program is compiled. Nothing will move around in your actual BASIC code.

[RetroFiends]

Yes, I'm looking at the space. And while there is a small (4 bytes) decrease in available space in bank 8 when I store a playfield in bank 7, bank seven takes on most of the burdon. Is batari automatically bankswitching from 8 to 7? Or maybe the graphics really are somehow only 4 bytes and bank seven is just spitting out pfcolors info?

Edited August 10, 2013 by RetroFiends

[+Gemintronic]

The translation process from BASIC to assembler to compiled code is just magical enough for me not to try and understand it. All sources say batari puts graphics and playfields in the last bank. Good enough for me.

 

That being said, you can at least store playfields in other places by using pfpixel commands or manually modifying playfield variables (i.e. var0 = 255)

 

Are you running out of space?

[RetroFiends]

Well, yes and no. If I'm careful I could totally make what I have planned now fit but it'll be a very tight fit. I was also mistaken that bank 7 was taking on a large part of the burden as it seems to have been an anomaly (meaning, I'm tired and reality totally wasn't cooperating with that fact.)

I could shave a little bit of space off by moving all my pf color commands over to another bank. Right now the game already has a staggering 16 rooms with 19 planned. (The extra 3 being buildings or caves for a little of the beaten track exploration that I haven't gotten in yet.) I only have one enemy plugged in so far.

 

Since Convert to Data File obviously isn't working for me I would still have a ton of room in the other 6 unused banks to make a convoluted system using pfpixels but I worry about how ungodly slow that might be.

[bogax]

I don't know how visual bB works

 

you can compile just the playfield statements

then with a little finessing copy the data from

the generated bB.asm file to data statements.

 

finessing will be removing the .byte directive

of the asm from the data.

[+Gemintronic]

You might start thinking about playfields in terms of building them instead of using up playfield data directly. I'd definietly explore at least creating parts of the screen from var statements.

 

This code right here puts three gravestones on the screen:

 

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

[+Random Terrain]

Since Convert to Data File obviously isn't working for me . . .

 

I don't know what your code looks like, so it could be some simple error. I'll post a simple example and see if your code is similar. If I want to draw the playfield the normal way, I could use something like this:

 

  playfield:
  XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  XX............................XX
  XX............................XX
  XX..XXXXXXXXXXX..XXXXXXXXXXX..XX
  XX..XX....................XX..XX
  XX..XX....................XX..XX
  XX..XX....................XX..XX
  XX..XXXXX..XXXX..XXXX..XXXXX..XX
  XX............................XX
  XX............................XX
  XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
end

 

I could also use VbB to grab the Hex Data Values (with reversed data) and draw the playfield like this:

 

   dim _Loop = w

  for _Loop = 0 to 43
  var0[_Loop] = _Data_Screen_01[_Loop]
  next

  COLUPF = $CE

__Main_Loop

  drawscreen

  goto __Main_Loop


  data _Data_Screen_01
  $FF,$FF,$FF,$FF,$C0,$00,$00,$C0,$C0,$00,$00,$C0,$CF,$7F,$7F,$CF,
  $CC,$00,$00,$CC,$CC,$00,$00,$CC,$CC,$00,$00,$CC,$CF,$79,$79,$CF,
  $C0,$00,$00,$C0,$C0,$00,$00,$C0,$FF,$FF,$FF,$FF
end

 

That code compiles and works for me. If it doesn't work for you, something might be wrong with your version of bB.

[RetroFiends]

Oh wow! For some reason I had it in my head that those playfield variables would only work in 4 vertical rows. I don't know why. I guess I got that in my head by the manual diving them up like such and your previous reply where you value it at 255.

 

But yes, this actually pretty much works perfectly, is accessible from any bank and is visually intuitive (so long as you take into account the rows with reversed bit order.) I take my lack of understanding and admit I need to get a bit of sleep. This is good news though, as it means I can definitely do the underworld I wanted to add to my game aswell, and not have to worry about the ROM space.

 

EDIT:

Yes, Random Terrain, something is wrong with my bB. I upgraded to build 566 just for convert data, but not even the example you posted in the "why this is so great" thread would compile. using data in general seems to not work regardless of what version my bB is and at this point I don't want to poke around too much further for fear that I might muck something else up. Still, it seems extremely odd that this is literally the only thing that is borked in my install.

Edited August 10, 2013 by RetroFiends

[+Random Terrain]

Just remember that VbB is separate from batari Basic. Where did you get your version of batari Basic?

[RetroFiends]

I... don't exactly recall atm, I believe it was that old Tinkernut link and the more I read these forums the more I see that was probably not the best idea.

I was also seriously unaware that batari basic and visual bB were two separate things as a result. I was under the impression it was just one package.

Edited August 10, 2013 by RetroFiends

[+Random Terrain]

I... don't exactly recall atm, I believe it was that old Tinkernut link and the more I read these forums the more I see that was probably not the best idea.

I was also seriously unaware that batari basic and visual bB were two separate things as a result. I was under the impression it was just one package.

 

Yeah, you'll probably want to read this:

 

http://www.randomterrain.com/atari-2600-memories-batari-basic-vbb.html#install_vbb

 

 

And I'll probably have to update that section soon because RevEng's newest project will probably become the semi-official version of batari Basic:

 

http://atariage.com/forums/topic/214909-bb-with-native-64k-cart-support-11dreveng/