Jump to content
Mr SQL

Try a fun programming language - Tiny BASIC :)

Recommended Posts

Fun with Tiny BASIC :)

 

The Atari 2600 beat the Commodore 64, Speccy, ZX-81, TRS-80 and Apple in the 2016 Vintage BASIC contest! :)

 

My entry was 9LineBlitz for the Atari 2600 written in Virtual World Tiny BASIC, here's the 9 lines of code to discuss:

 

0 data city 1,4,2,5,3,2,3,1,4,1,1,1,5,2,2,3,1,4,1,4,3,1,4,4,1,1,2,2,3,1,3,4,5,4,4,3,4,5,1,2,4,1,5,2,2,3,1,3,1,1,4,1
1 if g=0 then for j=0 to 7:player1(j)=189:player0(j)=pl(j):next j:BYTErowoffset=120:COLUPF=$84:COLUP0=$b4 else goto 3
2 for j=20 to 71:k=j-20:k=city(k)+14:for i=k to 19:vwpixel(j,i,on):next i,j:player0y=88:player0x=94:COLUP1=$74:y=20
3 COLUBK=0:AUDV0=0:g=1:scrollvirtualworldtoggle=1:BITIndex=BITIndex+1:data pl 0,224,127,231,252,192,128,0:rem bitmap
4 if joy0fire=1 and y>=20 then AUDF0=6:AUDC0=8:AUDV0=15:x=BITIndex+11:y=11:i=88-player0y:i=i/10:y=y+i
5 if y<21 then vwpixel(x,y,bindplayer1):j=y-10:y=y+1:COLUP1=M(j):data M $64,$54,$b4,$a4,$32,$44,$24,$c4,$94,$f4,$54
6 if y<=19 and vwpixel(x,y,poll)>0 then vwpixel(x,y,flip):player1x=0:player1y=0:AUDC0=y:y=20:AUDF0=4:AUDV0=15
7 if BITIndex>71 then BITIndex=0:player0y=player0y-2:rem player flies lower each pass over the smoothly scrolling city
8 if CXP0FB>126 then CXCLR=0:g=0:for i=0 to 255:AUDF0=i:AUDV0=i:COLUBK=$34:next i:rem check collision, restart game

 

This is what's going on in the program:

 

Lines 1 and 2 are setup routines and use a couple of nested for-next loops to draw a City on the virtual world, load one sprite with a bitmap and the other sprite with a pattern, reading the data from named arrays.

Line 3 scrolls the virtual world by incrementing the X index of the camera.

Line 4 checks if the button was pressed while no missiles are in progress, and if so sets a missile in progress.

Line 5 handles a missile in progress by binding it to the virtual world and cycling the colors.

Line 6 checks for missile collisions and destroys city blocks that are hit.

Line's 7 and 8 are commented.

 

The tiny program illustrates tile mapping, flipping and sliding the entire display around while the sprites and playfield graphics are also moving - all features of the soft blitter chip in the BASIC.

 

I hope bB programmers will be motivated to try Virtual World Tiny BASIC and have fun with the blitter operations, write games, enter the contest next year and share fun tiny programs on AtariAge! :)

 

There are so many incredible BASIC 10 liners for the Atari 8-bit and other Vintage home computer systems it would be awesome to see more for the Video Computer System!

 

Here's a screenshot of the IDE showing the Assembly output and BASIC side-by-side and launching the program in Stella:

post-30777-0-42305200-1461242241_thumb.jpg

While vintage BASIC programs are completely programmatic, the IDE also supports drawing the sprites and virtual worlds with ASCII graphics designers and a music sequencer for chiptunes as shown in the Source Code for StarBlitz, a larger Tiny BASIC game.

 

  • Like 3

Share this post


Link to post
Share on other sites

post-30777-0-24877500-1461335748.png

Is this the thing that requires command line stuff:

atariage.com/forums/topic/245726-virtual-world-basic-ide/?p=3375262

 

I use Visual batari Basic so I don't have to fool around typing in -weird -complicated -commands.

 

RT here's an easier way - type powershell in the windows search thingy, then right click PowerShell ISE and run as Administrator. Now all you need to do is click the play button to compile and launch BASIC programs in Stella! :)

 

Virtual World BASIC is designed to be closer to vintage BASIC's like Atari BASIC and Bally BASIC to be easier to pick up and use for many people who wrote BASIC on home computers bitd, while bB requires you to also learn a lot of modern programming concepts and low level concepts too.

 

I think BASIC should transparently handle page boundries, bank switching and cycle counting - lots of cool bB games are delayed and stalled over these.

 

Try this BASIC RT :) you write awesome games in bB and I really like the scroller, Gyvolver. I bet you could come up with some really creative programs!

 

Share this post


Link to post
Share on other sites

RT here's an easier way - type powershell in the windows search thingy, then right click PowerShell ISE and run as Administrator. Now all you need to do is click the play button to compile and launch BASIC programs in Stella! :)

 

Nope. Didn't work. I Googled it and you have to type in commands to bypass it, then you're vulnerable to malicious scripts:

 

google.com/search?q=%22powershell+ise%22+running+scripts+is+disabled+on+this+system

Share this post


Link to post
Share on other sites

 

Nope. Didn't work. I Googled it and you have to type in commands to bypass it, then you're vulnerable to malicious scripts:

 

google.com/search?q=%22powershell+ise%22+running+scripts+is+disabled+on+this+system

Good catch RT, looks like Thing2 is required! From the first entry your search returned:

Go to Start Menu and search for "Windows PowerShell ISE".

Right click and choose "Run as administrator".

post-30777-0-15296900-1461433748_thumb.jpg

In the top part, paste "Set-ExecutionPolicy RemoteSigned"

run the script. Choose "Yes".

 

Thing 2 cannot open your system up to malicioius script execution because the default scope is local-machine and your user account that you browse the web with cannot run powershell scripts unless an alternate method is used and then it must ask your permission first, always say no if a webpage wants to run a powershell script.

 

This BASIC is totally safe and hosted on my commercial servers so I can guarantee the integrity of the download; try it RT you will see, you will like the IDE :)

Share this post


Link to post
Share on other sites

Good catch RT, looks like Thing2 is required! From the first entry your search returned:

Go to Start Menu and search for "Windows PowerShell ISE".

Right click and choose "Run as administrator".

attachicon.gifThing2.jpg

In the top part, paste "Set-ExecutionPolicy RemoteSigned"

run the script. Choose "Yes".

 

Thing 2 cannot open your system up to malicioius script execution because the default scope is local-machine and your user account that you browse the web with cannot run powershell scripts unless an alternate method is used and then it must ask your permission first, always say no if a webpage wants to run a powershell script.

 

This BASIC is totally safe and hosted on my commercial servers so I can guarantee the integrity of the download; try it RT you will see, you will like the IDE :)

 

Thanks.

 

1. Pasted "Set-ExecutionPolicy RemoteSigned" in the blue area on the left that has the flashing cursor, pressed the Enter key, then clicked on the Yes button in the pop-up box.

 

2. Clicked on the File menu, selected Open, then opened the "vwBASIC_Compiler.ps1" file.

 

3. Clicked on the File menu again, selected Open, changed the type to "All Files" from the drop-down menu (to the right of the "File Name" box), then opened the "Program.txt" file.

 

4. Clicked on the vwBASIC_Compiler.ps1 tab, then clicked on the green "Run Script" icon.

 

5. A bunch of stuff happened in the blue area on the left and some error text in red was displayed because the program expected Stella to be in the vwBASIC folder for some weird reason. I could look at the code and see where the path info is and change it to where Stella is on my computer.

 

 

When I work on a program, I use Save As a lot (probably 10 to 12 times a day). Here are just two examples:

 

gyvolver_2016y_04m_21d_0117t.bas

gyvolver_2016y_04m_21d_1518t.bas

 

 

Looks like I'd have to edit "vwBASIC_Compiler.ps1" every time I use Save As to change the file name ($infile = "c:\vwbasic\gyvolver_2016y_04m_23d_1614.bas" # BASIC program). If true, that would be an annoying speed bump.

 

Visual batari Basic users may not like the extra steps that are involved.

  • Like 1

Share this post


Link to post
Share on other sites

 

Thanks.

 

1. Pasted "Set-ExecutionPolicy RemoteSigned" in the blue area on the left that has the flashing cursor, pressed the Enter key, then clicked on the Yes button in the pop-up box.

 

2. Clicked on the File menu, selected Open, then opened the "vwBASIC_Compiler.ps1" file.

 

3. Clicked on the File menu again, selected Open, changed the type to "All Files" from the drop-down menu (to the right of the "File Name" box), then opened the "Program.txt" file.

 

4. Clicked on the vwBASIC_Compiler.ps1 tab, then clicked on the green "Run Script" icon.

 

5. A bunch of stuff happened in the blue area on the left and some error text in red was displayed because the program expected Stella to be in the vwBASIC folder for some weird reason. I could look at the code and see where the path info is and change it to where Stella is on my computer.

 

 

When I work on a program, I use Save As a lot (probably 10 to 12 times a day). Here are just two examples:

 

gyvolver_2016y_04m_21d_0117t.bas

gyvolver_2016y_04m_21d_1518t.bas

 

 

Looks like I'd have to edit "vwBASIC_Compiler.ps1" every time I use Save As to change the file name ($infile = "c:\vwbasic\gyvolver_2016y_04m_23d_1614.bas" # BASIC program). If true, that would be an annoying speed bump.

 

Visual batari Basic users may not like the extra steps that are involved.

 

Awesome feedback RT, I do exactly the same thing! :) I ended up keeping a seperate command line window open to keep backing up program.txt to different timestamped file names while I was coding StarBlitz and 9LineBlitz. Also mixed it up a couple of times (program name is always the same) and was glad I had the backups.

 

I'm adding this option to the compiler:

$override_infile_and_BIN_filenames_from_first_txt_tab = "no" # yes uses first txt tab

 

It will use the first IDE Tab with a text file in it as the BASIC program instead of Program.txt, and will also use it to create the output filename for the ROM binary.

 

I definitely prefer to use this option, I should probably make it the default unless the compiler is run from the command line.

 

There's also an option to launch the program in Stella that's on by default:

$launch_emulator="yes" # "yes" Launches ROM in emulator after compiling (Stella emu expected in c:\vwBASIC\Stella, can just place a copy there or edit hard coded path to point to another emu).

 

The BIN should compile successfully even without being able to launch in Stella if you don't see any other RED errors in the blue area on the left; try examining it with the scrollbar, it should just show the Assembly output generated.

 

Keep up the great feedback! Looking forward to hearing more of your ideas :)

  • Like 1

Share this post


Link to post
Share on other sites

I've implemented this feature for the next release and tested it out by easily saving the different builds of the display list interrupt demo as I worked on it without having to ever leave the IDE (another awesome idea).

 

I didn't like having tons of binary output files cluttering the BASIC directory, so I decided to leave the output file as program.bin

 

This may help encourage the programmer give their programs a friendly name when releasing them, "Maze game v 3.bin" instead of "Maze Game January 3, 2016 4:54:36 PM.bas.bin" - I rename them like that manually as a player whenever I download a cool game.

Share this post


Link to post
Share on other sites

. . . instead of "Maze Game January 3, 2016 4:54:36 PM.bas.bin"

Nobody should use names like that if they want the file names to be listed in the order they were saved.

 

It should be year, month, day, and time. I put letters too so it's easier for me to remember:

 

space_farts_2016y_04m_26d_1110t

 

 

Related link:

 

atariage.com/forums/topic/181138-easy-software-versioning/

  • Like 1

Share this post


Link to post
Share on other sites

Having a pre-configured IDE for batari BASIC was the point where I felt comfortable diving in. Perhaps Mr SQL could whip up a web based IDE. Or, make a custom configuration for Scite, Eclipse, etc..

 

Also, this is amazing!!

  • Like 1

Share this post


Link to post
Share on other sites

This is almost perfect for the kind of games that I make. There are a few things about it though that keep me from it and stick to Batari BASIC. The big one is the inability to do multicolored sprites and multicolored playfields, with the option to change the resolution of the playfield. For the game I'm working on now, the multicolored playfield is a must (however Robot Zed uses single colored sprites). The Virtual World thing is great along with binding sprites to the world. Something I really wish Batari would do, but I have routines I've written on my end that do this kind of thing. Now, if you give this thing a little more features and flexibility, along with an IDE written specifically for it, then I might consider it.

  • Like 2

Share this post


Link to post
Share on other sites

This is almost perfect for the kind of games that I make. There are a few things about it though that keep me from it and stick to Batari BASIC. The big one is the inability to do multicolored sprites and multicolored playfields, with the option to change the resolution of the playfield. For the game I'm working on now, the multicolored playfield is a must (however Robot Zed uses single colored sprites). The Virtual World thing is great along with binding sprites to the world. Something I really wish Batari would do, but I have routines I've written on my end that do this kind of thing. Now, if you give this thing a little more features and flexibility, along with an IDE written specifically for it, then I might consider it.

 

Very cool Sprybug, it would be awesome to see you build a game with this BASIC!

 

Agree about the multicolored sprites and playfields - I would like to add those features but am first working on a cross compiler so the games can run on the 8-bit/5200 as well. Right now multicolor sprites and playfields are possible with artifact colors, which is pretty cool when it works.

 

With the games you are writing I think you could make good use of the Atari 8-bit style display lists feature comming in next release:

http://atariage.com/forums/topic/251949-display-list-interrupt-demo/

Share this post


Link to post
Share on other sites

The new release of vwB is now available on my site, here's a copy:

vwBASIC.zip

 

Lots of great feedback on this thread, everything we've discussed has been added to the new release! :)

 

1. The compiler is integrated with the IDE and will compile any .txt or .bas program opened with the IDE instead of only program.txt.

2. Display List Interrupts (from the other thread) have been added.

3. mulitcolor sprites and playfield and DLI color zones have been added.

 

 

  • Like 3

Share this post


Link to post
Share on other sites

This is neat. After I finish Zed, I'll have to play with this and see what kind of games I can make with it.

  • Like 3

Share this post


Link to post
Share on other sites

Two things to note for begginers:

 

Windows 10 automatically restricts some scripting features needed by vwBASIC. You need to run a PowerShell command prompt as administrator and execute this: "set-executionpolicy remotesigned"

http://www.faqforge.com/windows/windows-powershell-running-scripts-is-disabled-on-this-system/

 

If you just run vwBASIC_Compiler.ps1 it will partially balk because it expects a copy of Stella at .\vwBASIC\Stella This is easily solved by either copying your existing Stella folder to the vwBASIC directory or installing Stella there.

  • Like 1

Share this post


Link to post
Share on other sites

Two things to note for begginers:

 

Windows 10 automatically restricts some scripting features needed by vwBASIC. You need to run a PowerShell command prompt as administrator and execute this: "set-executionpolicy remotesigned"

http://www.faqforge.com/windows/windows-powershell-running-scripts-is-disabled-on-this-system/

 

If you just run vwBASIC_Compiler.ps1 it will partially balk because it expects a copy of Stella at .\vwBASIC\Stella This is easily solved by either copying your existing Stella folder to the vwBASIC directory or installing Stella there.

 

Thanks! :) I've created a one page quickstart guide with this information and illustrations to get beginners started right away without having to write code:

 

vwBASIC_quick_start_guide.pdf

 

Also added a feature to display remaining memory after compiling a program, the latest release is online here, and here is another copy: vwBASIC.zip

  • Like 2

Share this post


Link to post
Share on other sites

How feasible and arduous would it be to have another kernel that arranges the virtual world into 46 x 40 instead of 92 x 20?

Great question! :)

 

46x40 would require another kernel but you can use the camera (20x10) to remap the physical view of the virtual world to dimensions of 46x31 (losing 9 pixels from the y axis) or 165x10 (losing 19 pixels from the X axis).

 

I wrote a program recently that did the latter; the lost pixels are used to create an overlap area for the CAM:

 

If we represent the 92x20 virtual world as 5 TV screens accross and 2 TV screens down:

 

XXXXX

XXXXX = XXXXXXXXX (165x10 virtual world)

 

We can mirror the blue areas (and make sure to mirror pixel updates to both regions) losing 19 pixels from the x axis that are duplicated.

 

46x31 (need a wider representation to show the split)

 

XXXXXXXXXX XXXXX

XXXXXXXXXX = XXXXX

XXXXX (46x31 virtual world)

 

The same thing again but we lose 9 pixels from the y axis.

Share this post


Link to post
Share on other sites

Mr. SQL, right now I'm weighing my options. I want my game to do more than what I can do with the standard kernel in Batari, however I do have a few questions about VWBasic. How big can the ROM game size get? I know Robot Zed is probably going to be a 64K game. Does it support bankswitching? Also, can you have more than one virtual world? Like lets say the player beats the first world and then we move on to the next one. Would the programmer be able to define multiple worlds in their game and then jump from one to another accordingly?

And one last question. How many sprite tables can you have? Right now in my game, I have probably at least 1K worth of sprite data.

Edited by Sprybug
  • Like 1

Share this post


Link to post
Share on other sites

Mr. SQL, right now I'm weighing my options. I want my game to do more than what I can do with the standard kernel in Batari, however I do have a few questions about VWBasic. How big can the ROM game size get? I know Robot Zed is probably going to be a 64K game. Does it support bankswitching? Also, can you have more than one virtual world? Like lets say the player beats the first world and then we move on to the next one. Would the programmer be able to define multiple worlds in their game and then jump from one to another accordingly?

And one last question. How many sprite tables can you have? Right now in my game, I have probably at least 1K worth of sprite data.

 

 

Awesome you are thinking of building a game with Virtual World BASIC Sprybug! :)

 

And excellent questions! I'll answer them in reverse order:

You can define up to 32 sprites in the sprite library table, but can define more sprite tables containing one or more sprites each and load the sprites from there:

20 loadplayer0(0): rem --- load player0 with the second sprite in the sprite library

30 rem --- load player1 from a defined array table called mytable:

40 for x=0 to 7:player0(x)=mytable(x):next x

45 rem --- the ASCII art isn't as pretty using 1's and 0's but you can still draw bitmapped sprites in the mytable table because all arrays can read beyond boundaries.
50 data mytable %11001101
51 data mytable1 %11111101
52 data mytable2 %11111101
53 data mytable3 %11111101
54 data mytable4 %11111101
55 data mytable5 %00000001
56 data mytable6 %11111101
57 data mytable7 %11111101
Yes, you could have 1K of sprite data if you wanted, but 512 bytes might be able to handle the same load because the sprites and the color definitions for the sprites and the playfield are in RAM (there's an interesting discussion on the rpg demo thread on the main 2600 programming forum about the advantages to having color tables in RAM) so you can easily change the colors programatically saving space, and also do full and partial updates without having to use a seperate ROM color table definition each time which saves space too - you can do things like load the sprites starting at any row in the sprite library or your own sprite tables, splitting sprite definitions to create additional sprites - for example loadplayer0(4) would load the second half of the first sprite in the sprite library and the first half of the second sprite in the library.
Multiple worlds - you can do the same thing, only they are pretty big - 240 bytes each . You probably don't want to have more than one or two virtual worlds. Because the virtual world is a RAM table it can get modified during the game, if you restart the game it's been wiped out - nothing to reload unless you kept an extra 240 byte table around to reload it from (also a RAM table that could be partially reassembled or revised level to level before reloading the Virtual World from it). As a feature you might start the game with an initial virtual world that will never be seen again plus one or two virtual worlds that are restored from tables - that initial definition doesn't cost any extra memory, but it is volatile!

 

Bank switching is transparent - there are two banks, one for each gameloop and both banks can see each other so if you run out of space in one bank you could just call a routine in the other - that also works great for load balancing - you get instant extra cycles because Virtual World BASIC's gameloops hook both the top and bottom vertical blanks respectively, which gives you double the cycle time of bB which hooks only one (If you use Virtual World BASIC in old-school vintage BASIC mode you only have one blank/one gameloop like bB).

Going from world to world and big games 64K plus - there is a really cool feature you might be the first to experiment with:
You can actually make 20 6K games and chain them together and Harmony/Melody will let you load the next image from within the game, but it's a forward only double bank switch - you can't get back to the previous banks! This is great for building a massive game with tons of levels but the player would have to reload it to start over - power off/on as the reset if using a cart to host the game isn't as bad as having to rewind the tape to play over again with that model.
There are two ways to do that I think - hopefully someone who is familiar with the technique can clarify:
The ROM's can either be concatenated or you can use a special naming convention that tells Harmony/Melody the ROM's are particpating in a group as an extended SuperCharger game (there's a supercharger rpg game that does this which is an excellent example).

 

I haven't used any asm for any of my Virtual World BASIC games (pure BASIC) but right now you would need a line of inline asm to load the next game - I would be glad to help you with that if you want to build a large multiload game; that feature is eventually getting added as the BASIC key word 'load'! :)

 

I think you'll really like that the RAM arrays allow for a lot of efficient and interesting coding possiblities not possible with bB because it's ROM based - here's an example of a recent game from that has 512 bytes of ASCII text and an ASCII character generator plus the game too fitting into a single load:

Share this post


Link to post
Share on other sites

Wow, thanks for the detailed explanation. One of my concerns, with the scale of the game I'm working on, is that the overall size when you combine everything will be massive, because for every 6k, we'd have to repeat the same code, just the data would be different for the levels, enemies, music, etc. The plan would probably be for every level, there would be a new 6k chunk. I also have to let you know that the data for the music in my game is quite large. It follows pretty much the same format you have laid out in your engine. The intro level music is about 1.5k and the Sky Land one (which you can find in one of my threads) is over 2K in data! I also would also need to keep track of progress because the player can select which level they go to after the first intro level. I love the fact that the hard stuff is pretty much done for you, as with BB, I have to do all the scrolling and playfield detection for platforming myself, which is quite complicated. Also, what about HUDs? I would need a way to show a life bar, power orb collection counter, and a boss life counter.

  • Like 1

Share this post


Link to post
Share on other sites

It sounds like vwBASIC can handle large cart sizes now? Does this still mean if I wanted to put a game onto a real cart I'd have to scavenge boards with CBS memory?

Edited by theloon
  • Like 1

Share this post


Link to post
Share on other sites

Wow, thanks for the detailed explanation. One of my concerns, with the scale of the game I'm working on, is that the overall size when you combine everything will be massive, because for every 6k, we'd have to repeat the same code, just the data would be different for the levels, enemies, music, etc. The plan would probably be for every level, there would be a new 6k chunk. I also have to let you know that the data for the music in my game is quite large. It follows pretty much the same format you have laid out in your engine. The intro level music is about 1.5k and the Sky Land one (which you can find in one of my threads) is over 2K in data! I also would also need to keep track of progress because the player can select which level they go to after the first intro level. I love the fact that the hard stuff is pretty much done for you, as with BB, I have to do all the scrolling and playfield detection for platforming myself, which is quite complicated. Also, what about HUDs? I would need a way to show a life bar, power orb collection counter, and a boss life counter.

 

HUD's are harder to build, there is no native score support in the kernel like bB has.

 

The built in tracker-sequencer should come in handy though - there's 255 bytes reserved for 51 shaped notes patterns that can play sequentially as a main theme or subtunes, the Jamout demo reserves another 800 bytes of RAM to re-sequence the patterns and change the envelope for interesting effects and longer songs; an intro 6k chunk could have a pretty long song with that method.

 

 

 

It sounds like vwBASIC can handle large cart sizes now? Does this still mean if I wanted to put a game onto a real cart I'd have to scavenge boards with CBS memory?

 

It would require Melody/Harmony, it's SuperCharger format but Melody/Harmony can be configured to hold multiload SuperCharger games.

 

There was an older CBS RAM version used for Dodge It Panoramic Adventure but it's not up to date.

Share this post


Link to post
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.

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...