VBXE for Beginners Tutorial Thread

[Mark2008]

I don't follow AtariAge all the time, so hopefully this isn't too much of a repeat, but even if it is, I think back in the day, the magazines and many books often repeated various topics, and that was actually pretty cool.  One could find a tutorial that appealed.

 

VBXE was designed to be super simple to get started. For example, this code in basic already initializes and draws on a VBXE screen:

 

 

10 OPEN #6,12,3,"S2:"
20 COLOR 128:PLOT 30,30:DRAWTO 150,150
30 GOTO 30

 

Before running this program you  need to have the S2 driver loaded.
You can do that by using device S_VBXE in SpartaDos, but if you use another DOS,
there is a program called SDXLD, the purpose of it is to load SVBXE driver from another DOS.

 

The above code, Line 10, opens up device 6, the 12 means read/write, the 3 means use a standard screen 320x240 with 256 colors, and "S2:" is the VBXE device handler.

 

By default this turns off antic DMA, and you can use regular basic commands like PLOT and DRAWTO to draw to your VBXE screen, with more colors.

The above program simply draws a high resolution blue line on the screen.

 

This standard screen has a very simple layout, 1 byte = 1 pixel.   The value of the byte, represents the color of the pixel.

 

Now let's try something:

 

25 POSITION 50,50:PRINT #6;"HELLO WORLD!"

 

If you add this to the program, what you'll see now is not the words HELLO WORLD! but about 13 dots starting at postition 50,50.

 

This is because what we've done, is taken characters "H" and then "E" and "L", etc, each character is one byte long, and as it prints into position 50,50, then 51,50, and then 52,50 and so on, and each character byte, is now the pixel's color at those positions.

 

I've created a small ATASCII to character to color chart, just for fun, so I can use print statements to draw a picture on the screen:

 

Atascii to Colors
========================
inverse A                 Dark Green
D                            RED
LEFT ARROW           YELLOW
Inverse J                 LIGHT GREEN
Inverse UP ARROW   AQUA BLUE
f                             PURPLE
Inverse D                DARK GREEN
CTRL-D                   Grey

 

This is not coming from any chart, I just printed out some characters and observed the colors and this is my opinion of the colors they represent.  Now, I don't find it easy to share ATASCII character listings so I will share a screenshot of the code:

 

You can kind of see what I'm drawing, just in the listing:

 

 

 

 

Here is the end result:

 

 

 

And as a matter of fact, I added a little step to animate the ship across the screen.

 

Now, of course this is not the way to do it, because as you see when you run the program, it's a bit slow as the ship shimmies across the screen.

Also, with this many pixels, it's tedious to draw a sprite this way.

 

There is, of course, an answer for that and that is loading from a spritesheet and using the VBXE blitter.

 

My intention is to address those subjects in a later update, I'm going to be adding a modest vbxe lib to my PL65 collection.

 

The attached atr has the basic listing, but it is otherwise an empty disk.  Don't forget to get SDXLD if you need it.

 

 

90KB.atr

Edited December 7, 2022 by Mark2008

[Mark2008]

OK, let's blit this ship around the screen in basic, and then I'll work backwards and talk about it.

 

There are restrictions, for this demo I'm not checking which vbxe base you use, it assumes D6.   It probably assumes you aren't using the rambo core.

It assumes that you've loaded S_VBXE device.    These things will be solved in a future tutorial.  But for now - the focus is on blitting the ship around.

 

Download the latest 90k disk attached to this thread.    Load your S_VBXE.SYS device in DOS, and go to the BASIC prompt.

ENTER "D:SHIP.BAS" and Run it.

 

This is the same ship from the last installment, but in a specific spot on the screen.

Stop the program and type "NEW"

 

NEW clears basic's program space, but even though you don't see it, the ship is still in the VBXE memory.

 

Now:

 

ENTER "D:BLIT.BAS"

 

Run it.  Dramatic difference, right?    

 

 

10 V=214*256
20 MEMCONTROL=V+94
30 MEMBANK=V+95
40 POKE MEMCONTROL,128+8:REM $8000, 4K, CPU ACCESS
50 POKE MEMBANK,128:REM BANK 0
60 XDL=32768
70 POKE XDL,98
80 POKE XDL+1,136
90 POKE XDL+2,191
100 POKE XDL+3,0
110 POKE XDL+4,0
120 POKE XDL+5,0
130 POKE XDL+6,64:REM 128
140 POKE XDL+7,1:REM 2
150 POKE XDL+8,17
160 POKE XDL+9,223
170 POKE XDL+10,0
180 POKE XDL+11,0
190 REM START BLITTER CONTROL BLOCK
191 REM BCB IS ALWAYS 21 BYTES
199 POKE XDL+12,128:REM SOURCE ADDRESS BYTE 1
200 POKE XDL+13,46
201 POKE XDL+14,0:REM SOURCE ADDRESS BYTE 3
202 POKE XDL+15,64:REM SOURCE STEP Y BYTE 1
203 POKE XDL+16,1:REM SOURCE STEP Y BYTE 2
204 POKE XDL+17,1:REM SOURCE STEP X
205 POKE XDL+18,129
206 POKE XDL+19,121
207 POKE XDL+20,0
208 POKE XDL+21,64:REM DEST STEP Y BYTE 1
209 POKE XDL+22,1:REM DEST STEP Y BYTE 2
210 POKE XDL+23,1
211 POKE XDL+24,64:REM WIDTH BYTE 1
212 POKE XDL+25,1:REM WIDTH BYTE 2
213 POKE XDL+26,32
214 POKE XDL+27,255:REM AND MASK
215 POKE XDL+28,0:REM XOR MASK
216 POKE XDL+29,0:REM COLLISION AND MASK
217 POKE XDL+30,0:REM ZOOM
218 POKE XDL+31,0:REM PATTERN FEATURE
219 POKE XDL+32,0:REM CONTROL
300 POKE V+65,0:POKE V+66,0:POKE V+67,0:REM SET XDL ADDRESS
310 POKE V+64,3:REM ENABLE XDL, EXT COLOR
330 POKE V+80,12:POKE V+81,0:POKE V+82,0:REM SET BCB ADDRESS
340 POKE V+83,1:REM START BLITTER
390 AA=128
391 BB=121
400 FOR X=0 TO 320
410 AA=AA+1
420 IF AA>255 THEN AA=0:BB=BB+1
430 POKE XDL+18,AA:POKE XDL+19,BB
440 POKE V+83,1
450 NEXT X
500 END 

 

 

 

 

Blitter copies the ship, and now it animates smoothly across the screen in atari basic!

 

 

At this point - the programming here can seem tedious.  Because you point to this memory, that memory points to other memory....if you are like me, you find it annoying.

 

Which is why, I plan to write a library for it, and call that.  

 

For example, if a PL65 library were written, it may be called this way:  MOVE_SPRITE(1, X, Y)

Imho, that's a bit easier to work with than the above code.

 

About the blitter copy- basically you need to construct 21 bytes.  It's always 21 bytes, so look up what goes where and plug in the values.  And some of those bytes are for techniques you may not use in your first program.

 

What you can concentrate on for a first effort, is - tell the blitter the source address of what you want to copy, the destination address, and how tall and how wide the sprite is.

Other than that, copy the values I used.

 

There are many options for the blitter as you go forward. But a starting strategy is create a spritesheet.  Load that into memory, not usually visible, like this example, that was just for the tutorial...but load it, put it in memory off screen.

 

And then write that sprite to the location on the screen where you want it - moving it around as needed per your game logic.

 

Later tutorials - will necessarily include sprite sheets, and why I created an XDL.  There isn't really a need for the S_VBXE.SYS driver inside a custom program.  The S_VBXE.SYS driver though is handy to have loaded, anyway so you can program in 80 columns, and other tasks.

 

 

Lines 199 to 219 are of interest for the BCB.   I may try to update this post later for clarity.  But for now, I want to say if you go through the code and why I write to the same area of memory - for the XDL list, for the screen memory - it's not because it is best practice, it is for the purpose of not delving into other topics, as yet.

 

Starting at line 390 is the actual animation.   What I'm doing is incrementing the location that is the "destination" memory address.  The POKE V+83,1 tells the blitter to start work.

POKE V+83,1

 

 

 

90KB.atr

Edited December 9, 2022 by Mark2008

[Mark2008]

In my last installment I was anxious to share blitter code - which was fun.  Still, I want to organize future posts a bit better, and to follow some kind of logical pattern.
I've decided therefore, to go through porting a game w/VBXE use- in Altirra BASIC. That will bring forth various real-world concerns - and thus logical posts that are hopefully useful.  

The game will be runway 180, I've ported it before, but this is the first time using BASIC or VBXE.

There is a thread on AtariAge, where a poster created an XDL (Extended Display List) in Atari BASIC and talked about why he used a 4K window when using Atari BASIC and communicating with the VBXE.

The VBXE has 512K of RAM.  The CPU in the Atari, the 6502, only can see 64K.

So, to interface with all that RAM, a window is opened, whereby you map a bank of Atari RAM to VBXE RAM.  When you are writing to that BANK, you write to the VBXE.  
But this can be a challenge for BASIC, if the basic interpreter starts putting lines of your BASIC program into that window that is mapped to the VBXE - and then if the code then swaps that ram bank out - mayhem ensues.   Therefore, that poster opened a smallish 4K window to an area of RAM that BASIC would stay out of - at least for a while.

I've used that suggestion, but I will also additionally split this out into 2 programs. First, an init program that uses ram banking to load the VBXE ram with game assets.  Then the game itself, which will not use ram banking.

This strategy is a tradeoff.  The game will not have to worry that its own code moves into a banking window, as it just won't open a window at all. The tradeoff is it won't, then get to modify VBXE contents directly during runtime. 

The development will consist of two basic programs with tutorial "posts" following key milestones as follows.  

INITGAME.BAS
    1) Open up a Window to VBXE RAM (Post topic: Window to the VBXE)
    2) Upload to the VBXE a simple 12-byte Extended Display List to VBXE RAM, 320x240 w/256 colors "standard" resolution (Post: A simple XDL)
    3) Upload to the VBXE  Blitter Control Blocks, one for every position of the airplane, which, only moves along the Y access.   Recall as I don't plan to use bank switching during gameplay, I will therefore only be able to control VBXE by using the VBXE registers and pointing the blitter to an already existing BCB.  Therefore, there will be a BCB for every Y position of the plane. I'll be burning through RAM, but the VBXE has 512k of RAM, I say Burn, baby! Burn! (Post: BCBs for everyone)
    4) Upload to the VBXE a spritesheet, which are 2 airplanes (Post: Spritesheets)
    5) The init program will then turn off ram banking.

I will leave it as a challenge for someone to extend INITGAME.BAS to delete itself, and then automatically load and run R180GAME.BAS.   As a convenience to the user, this would allow them to run one program to get started playing.

 

R180GAME.BAS
    1) The game will switch on VBXE, it will expect to have VBXE assets already in VBXE memory, i.e., it requires that initgame.bas has been run.
    2) The plane will move up and down using a subroutine. E.G. PLANEYPOS=40.  The subroutine will translate the value 40, into the correct memory positions for the BCB that will move the plane to position 40.  And then trigger a blitter start.
(Post: memory that points to memory that points to memory - learn it, love it)
    3) VBXE will be used for the planes only.  It's a tutorial and I will leave it as a challenge for someone else to someday update the text HUD or other graphics using VBXE.  (Post: We've got game)
    4) The game will strictly follow the logic of the original.  If I don't follow some rules, I'll never finish it, as I go off chasing butterflies.  However, because the original TI game used airspeeds that are low - a note is being made here to only use small single engine type planes, maybe WWI biplane something like that. (Post: Wrap up)
 

[Mark2008]

Topic:  Spritesheets

 

First thing I want to say, is with this many pixels to work with, it is a different style of development than the familiar grabbing some graph paper and calculating pixels.

 

But it is also exciting and a fun way to develop.  I started today, by going to a website, I had never used them before:

 

High quality 2d Game assets and 2d game sprites (gamedeveloperstudio.com)

 

The reason I'm giving them a shout out, is for $1.35 cents, I bought the rights to use some artwork, and that is really exciting.

 

Here is a picture of the starting artwork:

 

 

 

Upon download the purchase, I find a spritesheet already made, animations for the propeller and an adobe illustrator file.

 

The challenge is going to be the color palette.

 

That is a file has color palette.  Recall I talked about in VBXE one byte = the color of one pixel.  Say the byte is :  155 what color does it mean?  Light blue?  Purple? Yellow?  That is what the color pallete decides.

 

To simplify things, I don't want to, for this demo change VBXE palette.   Luckily, the VBXE documentation discuss what palette is loaded by default, it came from the Atari800 project and is laoo.act.   ACT is an adobe palette file format, and I use GIMP.  I located a copy of laoo.act, converted it to gimp, named it atari.gpl and that is attached.

 

I experimented with different sizes for this spritesheet but ultimately decided on 320x39 because of the details in the plane, I cannot make the sprites that small.

 

I flipped the direction in GIMP.  This isn't a GIMP tutorial but it is Image->Transform->Flip Horizontal.

 

Then I have to set the Imaged for indexed mode and to use that atari.gpl palette.  

Go to Image->Mode->Indexed

 

 

Make sure that "Removed unused and duplicate colors from colormap" is NOT checked.

You don't want an optimized pallete, because let's say your image used 32 colors.  If you optimize it your pixel map will all be in the range 0 to 31.

That wouldn't match the 256 color palette we are using in the VBXE.

 

After you have the image as you want, export it to PNG.

 

Now, we could probably write a PNG reader for VBXE, but again, going after simplicity, so here is some python, what it does, is it opens up an image, writes back just the byte data to a bin file.

 

from PIL import Image

image = Image.open("sheet.png")
pixels =image.load()

out_file = open("sheet.bin", "wb")

for y in range(39):
  for x in range(320):
      out_file.write(bytes([pixels[x,y]]))

 

 

OK, that's not so complicated.  Now here is Atari Basic to load it to memory. 

 

1 OPEN #6,12,3,"S2:"
10 V=214*256
20 MEMCONTROL=V+94
30 MEMBANK=V+95
40 POKE MEMCONTROL,128+8:REM $8000, 4K
50 POKE MEMBANK,128+1:REM BANK 2
55 VMEM=32768:REM  
56 REM
57 REM LOAD 320 x 39 = 12,480 PIXELS
58 REM START IN VISIBLE SCREEN AREA (BANK1+3584) 
59 REM 
60 OPEN #1,4,0,"D1:SHEET.BIN"
61 OFFSET=3584
65 FOR Y=0 TO 511
80 GET #1,V
85 POKE VMEM+Y+OFFSET,V
95 NEXT Y
150 POKE MEMBANK,128+2
165 FOR Y=0 TO 4095
180 GET #1,V
185 POKE VMEM+Y,V
195 NEXT Y
200 OFFSET=192
250 POKE MEMBANK,128+3
265 FOR Y=0 TO 4095
280 GET #1,V
285 POKE VMEM+Y,V
295 NEXT Y
350 POKE MEMBANK,128+4
355 REM WRITTEN 512+4096+4096  3776 to go
365 FOR Y=0 TO 3775
380 GET #1,V
385 POKE VMEM+Y,V
395 NEXT Y
400 CLOSE #1
410 GOTO 410

 

 

And now the results:

 

 

 

The latest code is attached in a disk.

 

 

atari.gpl 90KB.atr

[Mark2008]

Whew, that's a lot of things to copy and paste into a post. 

Let me just add as a follow up.  

The basic idea, is that as I have a 4k or 4096 byte window that I'm using and my spritesheet is larger than that, I have to put in bytes until the end of the window, POKE a switch to the bank I'm using.  Write out another 4096 bytes, and so on, until I've written out all the bytes.

 

I put the spritesheet in a visible part of memory, for development, so I can see what I'm doing, but I can later switch where VBXE look for screen data to somewhere else - that will make this spritesheet offscreen.

There is no need to cut anything, because the blitter will be instructed  look for frame 1 starting at this memory location and X=64, Y=39.   Then you tell it look for frame 2 at this memory location, and X=64 and Y=39 and so on and so forth.  The blitter instructions I will just say are effectively a copy and paste operation.

 

You tell it what to copy, you paste it to where it should go.  Copy from off screen memory, paste to on screen - that's how I'll phrase it.

 

 

 

Edited December 10, 2022 by Mark2008

[Thelen]

Very cool you're doing this VBXE stuff in Basic! Nice work!

[Mark2008]

11 hours ago, Thelen said:

Very cool you're doing this VBXE stuff in Basic! Nice work!

Thanks!

 

Today, what I've done is created a boot disk, so that someone can download it and double click on it - simpler to get to the results.

 

It is BW-DOS, freeware version.  And I was going to have it load SDXLD V_VBXE.SYS, but while it will load manually, as part of the startup.bat it errors.

 

So, that's fine, to workaround that I removed the dependency on S_VBXE.SYS

 

it now loads an XDL that is a recreation of the S2: standard XDL.

Further, though the documentation states lsoo.act is loaded by default when you turn on  the VBXE, I couldn't get it to use the colors, so I created an vbpal.bin file from the lsaoo.act, and this now has a routine to enter in the palette file as well.  Which is just as well, if someone wants to create their own palette, they can see the process of loading it.

 

And finally, I included a fast screen clear in basic.

 

Later, the blitter will do the fast screen clear.   

 

One last note -  what is showing on this screen, is what will later be "off screen" - it actually shows the XDL as a series of dots at the top of the screen, and then the spritesheets.   Later I will just point the display area to be another area of VBXE memory - in other words, it won't have the dots, of course.

 

VBPLAY.ATR

Edited December 11, 2022 by Mark2008

[Mark2008]

A note on strategy - eventually, I'm just going to have the XDL as another asset.  The XDL is loaded from xdl.bin, palette is loaded from vbpal.bin, spritesheets loaded from sheet.bin

 

the final BASIC program will be simple to understand, as the code will be just load off disk, place in memory.  And what I hope is possible, is for another programmer to simply use the same xdl.bin and the same vbpal.bin.  Without any need to delve into how they were created.

 

It's intentional, to me, the goal is to have a kind of onramp to using VBXE, and then one would concentrate on the game logic, that uses this new paradigm, rather than pushing new limits with the VBXE.  And I'll be making that switch to finishing up runway180 fairly soon.  However, others will want to push the limits of the VBXE - but in my view that path includes necessarily learning the MADS assembler, because really I'm finding the majority of examples in that, and a few in mad pascal.

 

However, when I can remember to share my struggles - that may help someone in the future, so 

 

This is how I created vbpal.bin    since I had earlier used similar code to create the atari.gpl file that I used in the image program GIMP, I was fairly certain that creating this bin file and then poking the values into the VBXE would match up - and it looks like it did.

 

So, you could do the same, if you want custom colors.

 

#!/usr/bin/env python3
#
# How to use:
#   python act_to_vbpal.py laoo.act
#
# Code based on swatchbook/codecs/adobe_act.py from:
# http://www.selapa.net/swatchbooker/


import os.path
import struct
import sys


def parse_adobe_act(filename):
    filesize = os.path.getsize(filename)
    with open(filename, 'rb') as file:
        if filesize == 772:  # CS2
            file.seek(768, 0)
            nbcolors = struct.unpack('>H', file.read(2))[0]
            file.seek(0, 0)
        else:
            nbcolors = filesize // 3

        # List of (R, G, B) tuples.
        return [struct.unpack('3B', file.read(3)) for i in range(nbcolors)]


def write_vbpal(colors, name, columns=0):
    out_file = open("vbpal.bin", "wb")
    for color in colors:
        out_file.write(bytes([color[0]]))
        out_file.write(bytes([color[1]]))
        out_file.write(bytes([color[2]]))

if __name__ == '__main__':
        write_vbpal(parse_adobe_act(sys.argv[1]), sys.argv[1])

 

 

And this is from the disk earlier today, where I poke in the values:

 

20292 POKE CSEL,0:POKE PSEL,1:OPEN #1,4,0,"D1:VBPAL.BIN"
20293 FOR G=0 TO 15
20294 FOR H=0 TO 15
20295 GET #1,COLR:POKE CR,COLR
20296 GET #1,COLG:POKE CG,COLG
20297 GET #1,COLB:POKE CB,COLB
20298 NEXT H:NEXT G
20299 CLOSE #1

 

[Mark2008]

Trivial update, and it requires Altirra basic.

But the BGET command is just so much faster than the get command, and the speed is needed here.

 

 

 

VBPLAY.ATR

[Yaron Nir]

This is great so thumbs up!

and could be even greater.....

  

 

can you go over your basic code and explain line by line (almost)?

It is missing some VBXE background knowledge  for a simple person who wants to learn VBXE from scratch....

 

thanks again for the good work!

  

Edited December 12, 2022 by Yaron Nir

[Mark2008]

9 hours ago, Yaron Nir said:

This is great so thumbs up!

and could be even greater.....

  

 

can you go over your basic code and explain line by line (almost)?

It is missing some VBXE background knowledge  for a simple person who wants to learn VBXE from scratch....

 

thanks again for the good work!

  

I'd be happy to do that - I'll see if I can do that this weekend.

 

Meanwhile - this demo has got all the elements together - might be good to examine before the code is cluttered full of game logic.

 

Basically this adds a check for the VBXE itself and now sets the base.  And it's really organized.

  And go ahead and run runway180.bas, I put a little something, for the curious.

 

It will require Altirra BASIC.  I could  write XIO commands and support Atari BASIC, but the nature of this game itself is that it is important to have the timing right, and so, I'm just calling it and requiring altirra basic - probably turbo basic would work about the same too.  

 

 

VBPLAY.ATR

Edited December 13, 2022 by Mark2008

[Thelen]

9 hours ago, Mark2008 said:

go ahead and run runway180.bas, I put a little something, for the curious.

Yes, Nice 👌

[Mark2008]

Attached is a demo - the last demo.

 

The next download will be the completed game.  I am going to stop now and work on that line by line description.

 

As I've now typed in about 50% of the game itself, and re-familiarized myself with the original game, it does have x-axis movement at least after you miss a landing, so I decided to go ahead and allow for any arbitrary x,y movement.  

 

A small diversion from the original plan - but I don't see any roadblocks at this point.  The demo allows for looking at the initial title screen, instructions, takes you to the game screen - but doesn't allow to play the game - only to see the various objects being animated.   The landing gear is already out - in the game it starts not out - then is deployed.

 

anyhow....tomorrow I'll work on that line by line description of the vbxe init.

 

 

 

VBPLAY.ATR

Edited December 18, 2022 by Mark2008

[Mark2008]

an attempt to discuss at length a version of initgame.bas

 

 

@Yaron Nir

 

 

initgame-comments.txt

[Yaron Nir]

@Mark2008 fantastic work!!!!!! i took a glance at the text file and it looks great.

i will read it more thoroughly in the coming days.

thank you very much for this hard work. it is much appreciated.

i will be sure to post my follow up questions here in case something will come up

cheers and happy holidays

 

[Yaron Nir]

P.S - i would switch to ASM as basic is super slow. looking at that video you've made, the vertical movement of the plain has minor glitches and i guess it is due to the slowness of basic....

once i will finish working on my dragon master game, i will move to write a VBXE game in assembly. i will post some of my progress in these forums... 

[Mark2008]

2 hours ago, Yaron Nir said:

P.S - i would switch to ASM as basic is super slow.

 

Yes, this is an interesting subject.  The original game is from Compute! October 1983 - written in TI Extended Basic, to demonstrate the sprite capabilities of the Extended Basic cartridge.

 

TI Extended Basic is also super slow, and what most people found about the sprite capabilities is they were practically unusable.  That is because you had these machine language subroutines available for sprites, say "call motion", and "call coinc", but if you sent sprites in motion - which are now moving on a predefined velocity, independent of yoru program, and then tried to detect a collision, the issue was that basic was so slow, that by the time your basic program knew of the collision, the sprites had already moved so far on the screen, that it made no sense to the game.

 

However, the author had written a successful game, in basic. He did so by creating a slowish landing game.  The demo was just written quickly to show some movement - but the rise and fall of the plane in the demo is actually a dramatic altitude shift for the plane - the plane movement in actual game play will not be fast and it takes quite a bit of time to work up a big sink rate.

 

However the VBI routines already control the movement of the  stripe on the bottom, and the control tower, and not yet, but will also have to control the animation of the propeller.

 

 

Even the X,Y position of the plane math that calculates the memory location of the BCB will have to switch to the VBI routine.

 

 

So yeah, in a sense I need the same machine language routines as the original used - only the original game called routines on the TI extended basic cart, I'll have similar routines in the VBI.

 

But, other than that, the original was in basic, I probably have even more speed available than TI basic, and cross my fingers, it'll approximate the original game, in alitrra basic.

 

But mostly I do not write in BASIC for projects, but rather PL65, PL65 is meant to be an assembler replacement and fully supports inline assembler.

Edited December 20, 2022 by Mark2008

[Yaron Nir]

@Mark2008whatever works for you!

keep up the good work...

 

[Mark2008]

 

 

I had said next post is finished game, but instead I'm posting a somewhat uninteresting progress update.

 

What has occurred - VBI routine is expanded.  It now handles all propeller animations, correctly handles the paint stripe movement, to slow down as airspeed slows down. Now correct resets the DLI index, and the DLI now handles 2 color changes.  It is now also practically the entire page 6 in length.

 

As was discussed, and it's clear - the plane animation must be in the VBI, to be smooth.  I have mapped that out - I will store the ML in a string, in order to expand beyond page 6. 

 

But, meanwhile, I'm finishing out the port of basic code from TI to Atari.   Crash sequence is coded (in video).  It's a bit of old fashioned spaghetti code, but anyway, I will say I need to work on the bounce sequence, the stall sequence, and the landing sequence, handle complications.

 

When basic is done, I will go back to finishing the VBI.

[Mark2008]

Here is something -

 

TI-99/4A Game Shelf Entended BASIC Games (tigameshelf.net)

 

The author of TI Games Shelf, reviewed Runway 180 and stated:  "My absolute best was a score of 880 with 83 yards left. "

 

The version he offers for download, though, states that it was modified by Ray Kazmer on 3/89 to make landings easier.

 

Now, being somewhat familiar with the code, I suspected Ray simply changed the allowable sink rate, and indeed he has done changed the allowable range, but it looks like there are other changes as well.

 

But, my score for the Ray Kazmer version is 1360, not 880 - not because of some great skill but because again - based on the code, I realize there is an unusual path to get a much higher score. 

 

The question for me now is, did the original Compute magazine, unmodified game have that path.  I frankly used the TI games shelf version for the convenience of downloading it, but now wish to be true to the original not a user modified version.

I don't think anyone needs the game to be easier, to be frank, for the people willing to try the game, they just want a lark - a short, fun game, that should be hard.  Once you figure it out, it isn't fun any more.

 

 

 

[Mark2008]

This is the complete game, although I have not rewritten the VBI for smooth animations.

This just means all the paths in the game, like bounce, stall, complications, liftoff, another attempt, 5 attempts message, have been ported.

 

And it is playishable, and is a demo of VBXE, which was the original point.  So - final post to this thread, is the game, attached - in basic.

 

However, I will eventually include smooth VBI animations for the plane movement and tweak some timings, so it'll probably get another release someday - but I'll just post it as a game at that point.

 

To play:  set your emulator to VBXE, NTSC and Altirra BASIC.

 

 

 

VBPLAY.ATR

[Mark2008]

Oh my.... the instructions say the fire button takes out the landing gear, and I think I programmed it to check for "Q" to deploy the landing gear.

Well that won't work.......ok, there will be another upload after all....anyway....use the Q keyto deploy the landing gear, if you want to try this version.

 

it's because my ti-emulator used the q key as the fire button.....doh!

Edited December 30, 2022 by Mark2008

[pps]

Thanks for this nice tutorial game. I realy think this thread is a good idea and hope some other people are inspired now to make some codings for VBXE.

 

Strange: I can't see any aircraft with any setting of VBXE & ATARI I tried in ALTIRRA. Switching to ALTIRRA  BASIC and OS did the job

Edited December 30, 2022 by pps

[Mark2008]

7 hours ago, pps said:

Thanks for this nice tutorial game. I realy think this thread is a good idea and hope some other people are inspired now to make some codings for VBXE.

 

Strange: I can't see any aircraft with any setting of VBXE & ATARI I tried in ALTIRRA. Switching to ALTIRRA  BASIC and OS did the job

oh wow, do I have a dependency on both altirra basic and altirra os....I guess I need to update the readme on github. 

 

While I'm here I may as well upload the latest in case anyone finds this thread in the future. (this merely has the joystick button working)

 

I do plan on finishing the game such that it doesn't require this long list of dependencies - altirra os & basic & ntsc.... but the further I go along to smoothing out animations and making a regular xex the less useful it is as a tutorial, I mean those things will hide away the code and nobody needs to see my assembler, it's not coming from any particular experience, just hacking about.

 

anyway, thanks for the feedback...I have in mind another vbxe game....I wonder if someday I can actually just write it in secret and then spring it on everyone, the best I seem to muster so far, is keep it from facebook and spring it on those guys.... 

 

 

VBPLAY (10).ATR

Edited December 31, 2022 by Mark2008

[Geister]

Do you combine your interests and use PL65 with VBXE?  I think the combination should make good use of the Video features of the board.  

 

I'd love to see a 1090 compatible version (plug and play) of the VBXE and think that Atari was really shorted by Atari dropping that expansion chassis.