53 replies to this topic

[Rybags]

I spent several hours yesterday and today working on this.  It's a VBXE enhanced version of a game I wrote back around 25 years ago.

It's in Basic + Assembler - probably should have given it a different name given that there's an arcade/home game of the same name.

It will also work on non-VBXE equipped hardware or via emulation, of course with somewhat reduced amount of colour.

 moonshut.zip   5.13K   118 downloads - note:  the original upload was in error, this is now the proper file

(extract to a H: directory or run via APE from a HDD Mirror.)

Edited by Rybags, Sun Dec 20, 2009 11:25 PM.

[Heaven/TQA]

cool... it seems really top notch code...

i am still searching for some time to enhance Gridrunner... can you tell me how you test for VBXE hardware and how did you use the enhanced colors?

never played with the color ram and would like to enhance bits and pieces and do some test code in turbo basic first...

[Rybags]

VBXE test is straightforward... just check $D640.  $FF = nothing there.  Then check $D740, same story.

Colour RAM is easy too - just an XDL with 24 blank lines followed by colourmap, cell size 8x8 repeat 191.

Addressing colour RAM is by 4-byte boundary since you have 4 bytes per cell.

In this instance I only use the ability to change PF1 colour (with independent PF1/2 colour set).  Of course you have other stuff like PF0, PF2, the ability to have PF2 replaced by PF3 in 1/8th cell stripes, and the ability to switch from hires to multicolour mode on a per cell basis.

I'm tossing up ATM whether to do another game enhancement - likely an old commercial game, or whether to start something afresh in 100% Assembler.

I toyed with the idea of enhancing Nautilus - but really that game looks good out of the box.

[Larry]

Looks very nice in the VBXE.

It also reminds me quite a bit of my first (and last) video game -- "Treasure Quest" -- also a BASIC/assembler hybrid. (What an original title!) In my game the player commanded a submarine that had to pick up scattered "treasures" while avoiding deadly obstacles and depth charges from patrolling destroyers overhead. The wild success    of my game after hours and hours of work and frustration was instrumental in confirming my previous choice of a "day job."

-Larry

Rybags, on Sat Dec 12, 2009 11:42 PM, said:

I spent several hours yesterday and today working on this.  It's a VBXE enhanced version of a game I wrote back around 25 years ago.

It's in Basic + Assembler - probably should have given it a different name given that there's an arcade/home game of the same name.

(snip...)

[drac030]

Rybags, on Sun Dec 13, 2009 2:08 AM, said:

VBXE test is straightforward... just check $D640. $FF = nothing there.

Many XE computers, when there is nothing on an I/O page, do not return $FF, but some flipping values ($00, page number, or sth like that). So your test is likely to fail on such a machine which does not contain VBXE.

You should first try out the page $D6 for MEMAC B registers (i.e. try to enable MEMAC B bank $00 and see if the memory has changed under $4000), and if this succeeds, read out VBXE core revision (if this is relevant). If this test fails on $D6, rerun it for $D7.

[Rybags]

I thought only the 400/800 did that when nothing was present.

I think I did my asm stuff that way too.  Maybe MEMAC is the best approach - the danger of expecting specific values at Dx40/1 is that they can change in future core versions.

[Heaven/TQA]

so what is the piece of code for valid testing VBXE machine?

[drac030]

Example: http://atariki.krap.....09_i_starszych

This code is for older (i.e. beta) cores. For core 1.20 you have to assume MEMAC_B_CTL = $5D. jsr _vbxe_detect returns C=0 when VBXE is present, and the I/O page number is at _vbxe_write+2.

Edited by drac030, Tue Dec 15, 2009 9:14 AM.

[Thelen]

Cool to see a overlay to get these colours !

[Godzilla]

That's a fun game, thanks for sharing!

[Heaven/TQA]

boy.... coding on a real hardware is so oldschoolish... i am always typing wrong... but it is like bicycle riding... you never forget that...

but 1084, 40 collums plus macro ass xe vs eclipse ide... well... but at least i have connected my sio2usb interface so i can boot quickly my working environment...

[Heaven/TQA]

Rybags, on Sun Dec 13, 2009 2:08 AM, said:

VBXE test is straightforward... just check $D640.  $FF = nothing there.  Then check $D740, same story.

Colour RAM is easy too - just an XDL with 24 blank lines followed by colourmap, cell size 8x8 repeat 191.

Addressing colour RAM is by 4-byte boundary since you have 4 bytes per cell.

In this instance I only use the ability to change PF1 colour (with independent PF1/2 colour set).  Of course you have other stuff like PF0, PF2, the ability to have PF2 replaced by PF3 in 1/8th cell stripes, and the ability to switch from hires to multicolour mode on a per cell basis.

I'm tossing up ATM whether to do another game enhancement - likely an old commercial game, or whether to start something afresh in 100% Assembler.

I toyed with the idea of enhancing Nautilus - but really that game looks good out of the box.

Rybags... can you post the XDL from your source? i don't want to spend time debugging my own code while finding the way to adress the color ram...

[Rybags]

XDL is done by the Basic program at line 7040.  XDL itself is small, contained in DATA at lines 7060-7063.

24 blank, then 192 lines of 8x8 attribute cells in normal width.

I have a USR routine in ATR$ that paints attributes.

Calling format is USR(routine,startx,starty,value,offset [,step,number])
where startx,starty are screen x/y to paint first attribute.
value gets stored in attribute cell.
offset is value 0-3 to select which attribute cell to paint (PF0,PF1,PF2,control)
step is amount to add to attribute address each step, e.g. 4 to do horizontal line, 160 for vertical line
number is the number of cells to paint, e.g. 40 for a full horizontal line of text.

A MEMAC window is kept open at $8000 for access to the XDL and atrribute cells.  This program doesn't use any overlays, only attributes.

[Heaven/TQA]

ah, sorry.... have only watched the video and have not seen that the basic program was attachted...

[Rybags]

I made a gross error with the program uploaded - the XDL wasn't being pointed to properly so the colourmap won't work how it should on the version in the top post.

Don't know how I didn't pick it up before... I did powerdown but maybe VBXE didn't clear out properly.

This version should have all the proper features:

 moonshut.zip   5.13K   88 downloads

[Heaven/TQA]

thx. i am just playing around with vbxe and see how it can enhance Gridrunner (not the main game but the intro).

[Rybags]

Maybe for Gridrunner, you could just do a quick/dirty improvement of the actual grid.  Instead of just solid bars, use the 640 pixel mode and have progressive luma for a 3D look.

Leave GTIA priority on top, don't print the normal grid if VBXE is present, then just toggle the VBXE overlay on/off as needed.

[Heaven/TQA]

na... Gridrunner main part is completly done in Eclipse IDE and I don't spend days in converting the source back to Macro Ass XE and try to code on 40 collum/50hz/65xe... no thanks...

or did you use Atari++?

[Rybags]

I don't think the Atari++ VBXE version is very compatible?

I just did this enhancement on the real machine... the extra Asm stuff was about 10 minutes work on the PC, colourmap stuff is pretty quick to do, just check as you go along.

A grid would be pretty easy to do - just a set of blit commands would take care of it.

[Heaven/TQA]

yeah. btw... is there a chat available for us developers??? would be good integrated in the site like in facebook?

[Rybags]

There's the IRC channel... gotta get around to trying it out one day.

[andym00]

About the removing the Grid, from GridRunner.. Maybe you can just zero out the character for it in the character set to 'remove' the grid from the screen ?
GR would look cool with a VBXE background, and some other particle'y effects, ala GR++

[Heaven/TQA]

Andy... zero'ing out is a good point... that would work... as the core engine is still thinking there is a grid depending on the char value in screen ram.

I am hearing the guys moining that blowing a 3,5 kb game up to a "disc size" game...

[andym00]

Heaven/TQA, on Sun Dec 20, 2009 5:02 AM, said:

I am hearing the guys moining that blowing a 3,5 kb game up to a "disc size" game...

Ignore the nay-sayers I'd usually be the first to whine about a small 3.5K game like that bloating, especially since GR was single handedly responsible for me failing horribly at school that term, but I think it would be in the spirit of the game and the Llamasoft trippy nonsense.. And if you could do some nice VBXE grid(ish) background (that don't distract from the foreground, and are reactive to gameplay) I think even the beardy one himself wouldn't cry like a big girl.. For once

As long as it's got the original Vic-20 mode in there, and the VBXE stuff is an option (even with a VBXE detected) who's really going to complain ? I reckon only those for whom complaining is a professional pastime

[Heaven/TQA]

main challenge is not the code itself but to code on real machine with the "weird" keyboard layout, native assembler, etc...