Jump to content
IGNORED

Visual bB 1.0 - a new IDE for batari Basic


jwierer

Recommended Posts

Thanks once again for putting up with my ignorance. What is that not NTCS or PAL color table anyway? Are they a special table safe for NTSC and PAL colors?

By changing between PAL and NTSC you will see how the same color will be viewed on a PAL vs. NTSC television as the colors won't be rendered the same on a different regions tv. It makes sense that when you change the region setting it apply it to your sprites and playfields so that is how it will work in the future.

 

-Jeff

Link to comment
Share on other sites

  • 3 weeks later...

Ok...I've setup an old emachine computer running XP strictly for developing 2600 games. I have opted for the time being to use Visual bB. However, when compiling and testing programs, Stella returns "Could not locate <filename.bas.bin> and could not recompile." Is there something I am missing? Below is the current way I setup the programs.

 

A folder under the main hard drive "C:" was created and named "Atari 2600". From there, the rest looks like this:

 

*Atari 2600

|

|*batari

|*Stella

 

VisualbB resides under the Atari 2600 folder. It currently does not have a subfolder. The current settings for VisualbB are as follows:

 

For Stella: "C:\Atari 2600\Stella\Stella.exe"

For batari: "C:\Atari 2600\batari\2600basic.exe"

ALT Batch File: "C:\Atari 2600\batari\2600bas.bat"

 

I have performed manual and automatic searches for the BIN file that should of been compiled, but no file exists. I also checked for any warnings or errors and there were none. What am I doing wrong?

Link to comment
Share on other sites

Well, I discovered that Windows XP for some reason is making all folders read only. So, I attempted to try the development software on the laptop I have running Windows 7 (64-bit) and re-downloaded the appropriate VisualbB and Stella applications. Now when I attempt to build a test program to make sure everything works, I get this error message within VisualbB:

 

"System path does not include C:\Atari2600\batari"

 

What do I need to do to correct this?

Link to comment
Share on other sites

I have an Atari 2600 folder with a bB folder and a VbB folder in it. I also have a projects folder in there and I make a new folder in it for every game I start (again, each work in progress has its own folder). When I run a game I'm working on for the first time, VbB makes a bin folder in the current game folder and it runs the .bin file from there using Stella.

 

Don't know if that's helpful at all, but that's how my setup works.

Link to comment
Share on other sites

Ok...I've setup an old emachine computer running XP strictly for developing 2600 games. I have opted for the time being to use Visual bB. However, when compiling and testing programs, Stella returns "Could not locate <filename.bas.bin> and could not recompile." Is there something I am missing? Below is the current way I setup the programs.

 

A folder under the main hard drive "C:" was created and named "Atari 2600". From there, the rest looks like this:

 

*Atari 2600

|

|*batari

|*Stella

 

VisualbB resides under the Atari 2600 folder. It currently does not have a subfolder. The current settings for VisualbB are as follows:

 

For Stella: "C:\Atari 2600\Stella\Stella.exe"

For batari: "C:\Atari 2600\batari\2600basic.exe"

ALT Batch File: "C:\Atari 2600\batari\2600bas.bat"

 

I have performed manual and automatic searches for the BIN file that should of been compiled, but no file exists. I also checked for any warnings or errors and there were none. What am I doing wrong?

Remove the spaces from your path names, for example rename "C:\Atari 2600\Stella\Stella.exe" to "C:\Atari_2600\Stella\Stella.exe" and try again.

 

-Jeff

Link to comment
Share on other sites

Well, the 64-bit system returns an error saying that the preprocess.exe of batari does not support 64-bit windows. So, I'm back to the desktop. Any ideas on a solution would be most appreciated. Thanks.

For 64-bit Windows you'll need to use the updated compiler. There is an entire thread on it here. If you can't get it working I can zip up my bB folder and PM it to you.

 

-Jeff

Link to comment
Share on other sites

Odd...the setup on Windows XP fixed itself. The Windows 7 (64-bit) O.S. proved to be a little more troublesome. But for those that have upgraded to Windows 7 64-bit operating system might want to do the following. This is for those just starting in building a development kit for the 2600.

 

First, download the 64-bit versions of Stella and VisualbB. Obtain the updated batari BASIC file. Once you get all of these, extract/install them to your hard drive. For example, this is how my directories look:

 

ATARI 2600

|

+batari

|

+projects

|

+Stella

|

+VisualbB

 

Naturally, developers can name their folders what they want. Out of old DOS habits, I name mine according to the program name and/or purpose for the folder. I also try to stick with the old filename/folder limits of 8 characters that was a DOS rule. When VisualbB is started for the first time, the program will need to be configured to point to two files...the 2600bas.exe file that will be under the batari BASIC folder. The other is the Stella.exe file that will be under the Stella folder. After this, developers should be ready to go.

 

If error messages pop up (from Windows) stating "Unsupported 16-bit Application", download the update to batari again, but keep it separate from the original folder during extraction. Go back to VisualbB and under the SETTINGS tab, re-point the Compile File to the updated 2600bas.exe file in the second batari folder. After this, save any projects and exit VisualbB. Restart VisualbB and everything should be kosher.

 

I learned an important step to VisualbB's settings...when making file-pointing changes, the program has to be restarted for the changes to take effect. This was my fault as I should of known. Windows has made a habit of allowing most program changes to take effect immediately. Obviously VisualbB is not one of the programs it allows.

 

I hope that this helps others new to Windows 7 64-bit who are porting their 2600 development stuff to the operating system. Windows 7 is much cleaner, efficient, and user friendly than previous versions...but be prepared to do some old-school reworking of old programs.

Link to comment
Share on other sites

I've compiled a number of updates and fixes over the last couple of months. For all the new technology adopters, I think I finally have everything you need to get this working well under Windows 7 64-bit. You can download from the first post. Because AA limits 2MB uploads you'll need to download both files and unzip it to the same folder.

 

New Features

 

  • Build tool strip menu button remembers if you used the standard or alternate batch file for compiling
  • Allows reordering of results and projects tab
  • Better cleanup of previous compilation errors after a successful compile
  • Active project tab is colored
  • Startup and Settings tabs are colored
  • bB reference guide defaults to online copy if internet is available
  • vbB now warns you if you have unsaved changes before compiling
  • Support for DATA and SDATA in music editor
  • End data for music editor simplified to "255"
  • Channel 1 is displayed when using 2 voices in music editor
  • Music editor allows you to select if you want to cleanup (delete) test music binaries
  • ImgToCode.exe now allows you to right-click Convert to Assembly so if you create a playfield, edit it and convert to assembly.
  • Right click Save Snapshot for playfields/Sprites
  • Added Setting for associating .bas, .pla, and .spr files with VisualbB. Double clicking any file will launch in vbB
  • Added a pause button to the music and sound editor
  • Image Converter (ImgToCode) now supports the Title Kernel
  • Added new context menu item for code editor allowing you to highlight a term and seach for next instance or jump to code where a label is defined

Bug Fixes

 

  • Now Works under Windows 64-bit editions (see upgrade info)
  • When using a shortcut to run visualbB.exe some menu items didn't appear
  • Using File-Open would crash vbb if a project was not selected
  • "Test" bins were not being deleted in the music editor
  • When in the settings tab, hitting backspace while typing in the compiler field crashes VbB
  • When you try to set playercolor or playfield color the dialog always said background
  • Removed dependency on gif.components.dll
  • Save as GIF in sprite animater fails if run from shortcut
  • When REGION is changed the color palette is applied to all open sprites/playfields
  • when dragging sprites from from project explorer it will always use the latest even if not saved.
  • Identified registry issue for those not able to use the playfield/sprite editors. This was due to a bad registry setting (see this thread)

Upgrading for 64-bit Windows

If you are running on a Windows 64-bit operating system and you have settings that you like, you should migrate them before upgrading. Note this is a one time step.

 

  1. Run your CURRENT version of visualbB and go to file->export settings
  2. Edit the resulting .reg file and replace instances of HKEY_LOCAL_MACHINE\SOFTWARE\VisualbB with HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\VisualbB
  3. Double click the .reg file to import it into the registry, just say yes when it asks you if you want to do this.
  4. Replace your vbb files with updated version

I've also included a copy of my bB folder that includes all 32-bit binaries for the compiler.

 

-Jeff

  • Like 2
Link to comment
Share on other sites

great work as usual jeff.

VB now works with my win 7 64-bit machine even the music editor works.

so now I can program on my desktop pc once again.

I'll prob still use the old version on notebook to do some fine tuning though(I'm on my desktop more then my notebook since I only use that when I travel)

Great! Did you have to update your bB files as well? Up until last week I didn't realize I was still using 16-bit copies of preprocess, postprocess, and optimize that wouldn't load in 64-bit Windows. Batari gave me the updated ones last week so I figured I'd share the wealth.

 

-Jeff

Link to comment
Share on other sites

great work as usual jeff.

VB now works with my win 7 64-bit machine even the music editor works.

so now I can program on my desktop pc once again.

I'll prob still use the old version on notebook to do some fine tuning though(I'm on my desktop more then my notebook since I only use that when I travel)

Great! Did you have to update your bB files as well? Up until last week I didn't realize I was still using 16-bit copies of preprocess, postprocess, and optimize that wouldn't load in 64-bit Windows. Batari gave me the updated ones last week so I figured I'd share the wealth.

 

-Jeff

yep, everything is working also did export >import my settings so I didn't have to worry about that.

I just have figure out how to use the title kernel so I can do some cool title screens.

Link to comment
Share on other sites

  • 2 weeks later...

With no project open you can:

1. Click on FILE

2. Click on Close Project

3. Receive a valid message about no projects to close -> Click OK

4. An unhanded exception message appears.

 

Happens on XP but haven't tried on different platforms.

Thanks for the report. That's fixable.

 

-Jeff

Link to comment
Share on other sites

  • 4 weeks later...

I'd like to submit a feature request for the Img2Code utility.

 

Right now if you load a picture with 256 lines and hit the "Create Image" button, the number of lines gets changed to 192, and indeed only 192 lines of data are generated per slice.

 

The soon-to-be released version of the titlescreen kernel uses images up to 265 lines tall for scrolled pictures or animation frames. It would be cool if Img2Code could work with these larger images!

  • Like 2
Link to comment
Share on other sites

I'd like to submit a feature request for the Img2Code utility.

 

Right now if you load a picture with 256 lines and hit the "Create Image" button, the number of lines gets changed to 192, and indeed only 192 lines of data are generated per slice.

 

The soon-to-be released version of the titlescreen kernel uses images up to 265 lines tall for scrolled pictures or animation frames. It would be cool if Img2Code could work with these larger images!

 

That should be possible.

 

EDIT: Luckily I had a constant defined for that. Please give this a shot.

 

ImgtoCode.0.9.1.5.zip

 

-Jeff

  • Like 3
Link to comment
Share on other sites

Now that we have RevEng's beautiful title screen kernel, we should have an IMG2CODE that will insert directly into the appropriate files.

 

You tell IMG2CODE where your files are, when you follow Rev's tutorial.. it says select sprite.. select 96 image wide, by however tall (in my case 53), instead of selecting Assembly you would select which Title Screen option to output. This would output the file 96x2_1_image.asm in my case. It's up to you to modify your colors later on.

 

What I would like to see still (maybe I'm forgetful here) is an easy way to assemble that code your program outputted so I can easily edit it. So far it looks decent, but I need to change a few pixels here and there to make letters look okay, or maybe clean up a few pixels. I'd like a way for this to at least line up the byte numbers in the correct position so I can easily find them. I'll then use my eyes to visually inspect it and add some 1's or 0's where needed, then a way to quickly insert them back into the program.

 

It's quite tiresome making a logo, pasting in 11 things of bytes, then having part of it look crappy have to redo it all and repaste all those again.

Link to comment
Share on other sites

Now that we have RevEng's beautiful title screen kernel, we should have an IMG2CODE that will insert directly into the appropriate files.

 

You tell IMG2CODE where your files are, when you follow Rev's tutorial.. it says select sprite.. select 96 image wide, by however tall (in my case 53), instead of selecting Assembly you would select which Title Screen option to output. This would output the file 96x2_1_image.asm in my case. It's up to you to modify your colors later on.

 

What I would like to see still (maybe I'm forgetful here) is an easy way to assemble that code your program outputted so I can easily edit it. So far it looks decent, but I need to change a few pixels here and there to make letters look okay, or maybe clean up a few pixels. I'd like a way for this to at least line up the byte numbers in the correct position so I can easily find them. I'll then use my eyes to visually inspect it and add some 1's or 0's where needed, then a way to quickly insert them back into the program.

 

It's quite tiresome making a logo, pasting in 11 things of bytes, then having part of it look crappy have to redo it all and repaste all those again.

 

Now that the title kernel is final, I've been thinking of creating a title wizard that would have you assemble the different images and then just output the code and create everything for you, but it still wouldn't do what you are suggesting. I thinky you're actually much better off creating the image in any of the the hundreds of free graphic editors out there. It would be much easier to resize, cleanup, change to black and white in something like GIMP and then convert it to code.

 

-Jeff

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...