bataribasic.com planned updates

[+batari]

I'm planning to update the bB website and post the official 1.01 release. I plan to incorporate all of the changes over the years by myself and others and to build new binaries for all supported platforms.

 

Also, I can host Visual bB there (I see the download is >2MB now, so there would be no need to split it up.)

 

Here's where I need help - there are several user-created changes such as SeaGtGruff's changes, RevEng's fonts, CurtisP's score mods, and I need the latest version of these and any documentation. If there are any others I should include, let me know. Some of the changes (particularly most of SeaGt's stuff and the fonts) may be incorporated into the main bB download, while others uploaded separately.

 

Feel free to post links to the latest user changes here.

 

Thanks!

[jwierer]

I'm planning to update the bB website and post the official 1.01 release. I plan to incorporate all of the changes over the years by myself and others and to build new binaries for all supported platforms.

 

Also, I can host Visual bB there (I see the download is >2MB now, so there would be no need to split it up.)

 

Here's where I need help - there are several user-created changes such as SeaGtGruff's changes, RevEng's fonts, CurtisP's score mods, and I need the latest version of these and any documentation. If there are any others I should include, let me know. Some of the changes (particularly most of SeaGt's stuff and the fonts) may be incorporated into the main bB download, while others uploaded separately.

 

Feel free to post links to the latest user changes here.

 

Thanks!

Is this based on your MinGW build? If so, I am still having trouble with it under certain conditions whether on 64 or 32-bit Windows.

 

-Jeff

[rpgfaker]

so does this mean we can use text?

[+batari]

I'm planning to update the bB website and post the official 1.01 release. I plan to incorporate all of the changes over the years by myself and others and to build new binaries for all supported platforms.

 

Also, I can host Visual bB there (I see the download is >2MB now, so there would be no need to split it up.)

 

Here's where I need help - there are several user-created changes such as SeaGtGruff's changes, RevEng's fonts, CurtisP's score mods, and I need the latest version of these and any documentation. If there are any others I should include, let me know. Some of the changes (particularly most of SeaGt's stuff and the fonts) may be incorporated into the main bB download, while others uploaded separately.

 

Feel free to post links to the latest user changes here.

 

Thanks!

Is this based on your MinGW build? If so, I am still having trouble with it under certain conditions whether on 64 or 32-bit Windows.

 

-Jeff

You need to use the latest kernel if using the minGW build. Apparently, the one I posted here is the latest. Let me know if this works.

[jwierer]

I'm planning to update the bB website and post the official 1.01 release. I plan to incorporate all of the changes over the years by myself and others and to build new binaries for all supported platforms.

 

Also, I can host Visual bB there (I see the download is >2MB now, so there would be no need to split it up.)

 

Here's where I need help - there are several user-created changes such as SeaGtGruff's changes, RevEng's fonts, CurtisP's score mods, and I need the latest version of these and any documentation. If there are any others I should include, let me know. Some of the changes (particularly most of SeaGt's stuff and the fonts) may be incorporated into the main bB download, while others uploaded separately.

 

Feel free to post links to the latest user changes here.

 

Thanks!

Is this based on your MinGW build? If so, I am still having trouble with it under certain conditions whether on 64 or 32-bit Windows.

 

-Jeff

You need to use the latest kernel if using the minGW build. Apparently, the one I posted here is the latest. Let me know if this works.

That fixed it! Looking forward to the update.

 

Thanks,

Jeff

[jbs30000]

Thank you for the minGW build link. bB seems to completely work again on my computer too.

[RevEng]

Very nice, batari. It will be great to have a new official baseline!

 

The latest score font file is in the first post of this thread.

 

Here's some instructions I just wrote up in the bB online-manual style. Feel free to change anything - these instructions, the constants I used, or whatever...

 

• 
   
  Score Font
  There are 12 different score fonts to choose from. You can change a different font by setting the "fontstyle" constant to one of the font names.
   
  

const fontstyle = HANDWRITTEN

 
The available fonts are: STOCK, NEWCENTURY, WHIMSEY, ALARMCLOCK, HANDWRITTEN, INTERRUPTED, TINY, RETROPUTER, SNAKE, HUSKY, CURVES, and PLOK.
 
Score with Hexadecimal Characters
Normally only the score digits 0-9 are defined, but it's possible to display hexadecimal digits as well. This can be useful for displaying the contents of certain variables while debugging your program.
 
To turn enable hexadecimal score-support, set the fontcharsHEX constant to 1.
 

const fontcharsHEX = 1

 
Once you've enabled hexadecimal support, you can access the different digits in the score as follows.
 

 rem The following code snipplet will display "BABE01" in the score
 dim sc=score
 sc[0]=$BA
 sc[1]=$BE
 sc[2]=$01

 

 rem The following code snipplet will display player0's X coordinate in the score
 dim sc=score
 sc[0]=player0x

 
Score with Special Characters
You can also define the score hexadecimal digits with non-letter characters too. To define which special characters you want to use, you set the constant for that character.
 
The available characters are: fontcharSPACE, fontcharDOLLAR, fontcharPOUND, fontcharMRHAPPY, fontcharMRSAD, fontcharCOPYRIGHT, fontcharFUJI, fontcharHEART, fontcharDIAMOND, fontcharSPADE, fontcharCLUB, fontcharCOLON, fontcharBLOCK, fontcharUNDERLINE, fontcharARISIDE, and fontcharARIFACE.
 

 rem The following code snipplet will display " (c)2010" in the score
 const fontcharSPACE = 1
 const fontcharCOPYRIGHT = 1
 dim sc=score
 sc[0]=$AB
 sc[1]=$20
 sc[2]=$10

[RevEng]

I just posted a score fade effect kernel mod here. Feel free to add it to the official bB dist if you see fit!

[SeaGtGruff]

I need to review my posts and include files to see what mods I'd made. I'm not even sure what they are anymore, other than the inventory strip mod.

 

Will version 1.01 add support for additional bankswitching schemes, like E7? I'd modified version 0.35 for that, but I never updated it for version 1.00-- and now I know what I didn't know then, that I could have used ORG and RORG to define and compile all of the banks in one step without having to use a specially-written "post processing" program.

 

Michael

[jwierer]

I need to review my posts and include files to see what mods I'd made. I'm not even sure what they are anymore, other than the inventory strip mod.

 

Will version 1.01 add support for additional bankswitching schemes, like E7? I'd modified version 0.35 for that, but I never updated it for version 1.00-- and now I know what I didn't know then, that I could have used ORG and RORG to define and compile all of the banks in one step without having to use a specially-written "post processing" program.

 

Michael

I hope your bitmap kernel gets formally included.

 

-Jeff

[+batari]

I need to review my posts and include files to see what mods I'd made. I'm not even sure what they are anymore, other than the inventory strip mod.

 

Will version 1.01 add support for additional bankswitching schemes, like E7? I'd modified version 0.35 for that, but I never updated it for version 1.00-- and now I know what I didn't know then, that I could have used ORG and RORG to define and compile all of the banks in one step without having to use a specially-written "post processing" program.

 

Michael

Among other things, you did something to the batch files and possibly other source files to fix things for other operating systems. I don't think I ever applied those changes here because I've never needed to, but I might as well now.

 

As for the various other things, once it's all together, I'll decide what can be included with the main release and what can be an additional download, but either way, it should work with the current software.

[SeaGtGruff]

I hope your bitmap kernel gets formally included.

I'm not so sure it should, at least not as it is currently. It's really just a custom kernel with limited (i.e., rather narrow and specific) usefulness, as opposed to an enhancement that has more generic usefulness. Custom kernels can be posted and shared without being part of the batari Basic package per se.

 

Michael

[MausGames]

Wish you were still messing with it Michael, it has a lot of promise for sure!

[+Random Terrain]

Wish you were still messing with it Michael, it has a lot of promise for sure!

Like he said, it's pretty limited. I'd be more excited about this:

 

http://www.atariage.com/forums/topic/93867-using-the-score-for-a-game-title-or-inventory-strip/page__view__findpost__p__1140372

. . . I'm actually thinking of writing a new kernel specifically designed for game title screens, with a much bigger title in the center of the screen, including additional lines for things like the copyright message, or "press fire to begin," or the game difficulty level picker. The userscore stuff could still be used for things like inventory strips, or "lives remaining" icons, etc.

That would be extremely useful and something pretty much every bB user would use in every game.

 

 

I also hope that bB will be getting 4-bit variables that bB will handle automatically instead of needing to use code that can be confusing:

 

http://www.atariage.com/forums/topic/133045-feature-requests-for-batari-basic/page__view__findpost__p__1610607

I will look into it. I'm not sure how difficult it would be. I suppose that depends on what programmers would expect to do with 4-bit variables.

 

Anyway, you can do this now using &, |, * and /. & and | are useful to "mask" bits, while * and / by powers of two do bit shifts. If 4-bit variables are implemented into bB, these operations are what will take place under the hood.

Yep, as I said, SeaGtGruff's example is useful and works great, but it can make the code hard to figure out later, even with comments. And I've screwed up the conversion more than a few times and it never seems to get easier. If bB could allow us to use nybble variables as if they were regular variables, any confusion would be eliminated and the code would be easier to understand.

 

If it's possible to have bB do the calculations for us, it would be less confusing since we could just use 4-bit variables like any other variable. Bit operations are nice for flags, but there are a lot of times when you need more, but you don't need the whole variable. That's where 4-bit variables will come in handy. I'm working on 3 programs right now and there are many variables in all three programs that don't need to contain a value over 15. It's a waste to use a whole variable for them, and the one program I converted using SeaGtGruff's example works fine, but the code has become so confusing to look at, even with comments, that it has become almost impossible to continue work on it.

 

If you can fix it so 4-bit variables can be as easy to use as regular variables, I bet I won't be the only one doing a happy dance.

 

I commented the crap out of the code of one program I was working on and still couldn't decipher it, so I ripped out the 4-bit variables and went back to regular ones so I could see what was going on.

[MausGames]

That would be extremely useful and something pretty much every bB user would use in every game.

 

This is something I would definitely NOT use, unless the sprite data could be contained in any bank, something we don't yet even have for the standard bB kernel. I have enough trouble fitting a decent amount of sprites in the same bank as the kernel and whatever else gets stuffed in the same bank, much less a giant amount of title screen data.

 

edit: and this is something that has always confused me, I'm still not clear on what gets put in what bank, and why. All I know is I have never been able to fit all of my sprites and code into a project, because of what is smushed all into one bank, and it makes having 32k of space to work with somewhat useless. Could anyone point me to a description of what gets moved where at compile, and why?

Edited May 18, 2010 by MausGames

[Dan Iacovelli]

how would the title screen kernel work with multisprite kernel since it uses the mirrored play field .

[RevEng]

This is drifting quick.

 

Maus: pretty much all data the bB kernel needs access to while drawing the screen gets stuck in the last bank with the kernel, to avoid bankswitching delays. This includes sprites, playfields, color lists, height lists, score fonts, etc. Also, vblank code goes there too.

 

The title screen kernel could go in another bank, and would probably require that the data it uses sit in the same bank it's in.

 

Dan: the titlescreen kernel would be responsible for drawing the display while it was active, not the regular bB kernels, so it doesn't have the same limitations as them.

Edited May 18, 2010 by RevEng

[yuppicide]

Yes, a title screen maker would be my most wanted feature I think.

 

If not a custom title screen maker, how about something to make a 5200 like title screen.. shows a bAtari Basic logo, has copyright year, programmer name, and game name.

[+Philsan]

Yes, a title screen maker would be my most wanted feature I think.

 

If not a custom title screen maker, how about something to make a 5200 like title screen.. shows a bAtari Basic logo, has copyright year, programmer name, and game name.

I agree.

[SeaGtGruff]

Maus: pretty much all data the bB kernel needs access to while drawing the screen gets stuck in the last bank with the kernel, to avoid bankswitching delays. This includes sprites, playfields, color lists, height lists, score fonts, etc. Also, vblank code goes there too.

Playfields can go in other banks if they're written to bB's playfield RAM, either in zero-page RIOT RAM or Superchip RAM. Other graphics data-- players, color lists, etc.-- can also be stored in other banks *IF* you copy the data into RAM (zero-page or Superchip) and then change the lo/hi pointers so they point to RAM.

 

Michael

[+batari]

SetGtGruff: can you tell me if the file you posted here:

http://www.atariage.com/forums/topic/123417-a-pfcolors-question-for-batari-basic-experts/page__p__1490744#entry1490744

 

is the latest bB update you created, or is there a newer one?

[SeaGtGruff]

SetGtGruff: can you tell me if the file you posted here:

http://www.atariage.com/forums/topic/123417-a-pfcolors-question-for-batari-basic-experts/page__p__1490744#entry1490744

 

is the latest bB update you created, or is there a newer one?

The only differences I see with the files I'm currently using are the std_kernel.asm and std_overscan.asm, which I'd modified for my "userscore" enhancement. The modified files are attached.

 

Michael

std_kernel.zip

[SeaGtGruff]

Here's the post that discusses the userscore changes:

 

http://www.atariage.com/forums/topic/93867-using-the-score-for-a-game-title-or-inventory-strip/page__view__findpost__p__1648180

 

Also, I think the 2600basic.exe file that was in the zip you were looking at was an older version.

 

Michael

[SeaGtGruff]

http://www.atariage.com/forums/topic/93867-using-the-score-for-a-game-title-or-inventory-strip/page__view__findpost__p__1648180

I just posted a modification to the multisprite_kernel.asm in that thread. But both versions of the kernel-- standard and multisprite-- have a timing issue with the score routine that causes one of the sprites to be updated 1 color clock too soon or too late. I think the issue was always there, but was never visible because the score digits have a blank column where the timing is off, so it never made a visible difference, but the difference shows up when that bit column isn't blank. I haven't worked out the fix for that yet.

 

Michael

 

To clarify:

 

In the standard kernel, the last digit of the score is updated 1 color clock too late. That is, the first pixel column of the 6th digit ends up being the same as the first pixel column of the 4th digit. I think shifting all the digits to the right 1 color clock should fix it, but I haven't tried it yet.

 

In the multisprite kernel, the first digit of the score is updated 1 color clock too soon. That is, the last pixel column of the 1st digit ends up being the same as the last pixel column of the 3rd digit. So shifting all the digits to the left 1 color clock should fix it-- in theory!

Edited May 21, 2010 by SeaGtGruff

[Pioneer4x4]

Any possibility of supporting supercharger in any format other than basic 4K no extra ram. While I don't understand 80% of what goes on in detail, I think that if the one of the other modes might be able to be converted to work on a supercharger. Isn't there a 4k with extra ram? or a 2k with 2k ram?