Kapooka - homebrew logic game

Talk about programming of homebrew games only.
User avatar
mr_bogus
Posts: 24
Joined: Fri Jun 13, 2008 8:40 am

Kapooka - homebrew logic game

Post by mr_bogus » Sat Jan 09, 2010 10:35 am

Hi,

Here's a logic game I originally wrote for linux, and have now ported to CreatiVision. It's like a cross between Pengo and Sokoban, you push the blocks around to get to the exit. Use joystick to move, and fire button to restart current level.

Original game was here: http://kapooka.sourceforge.net/ but linux version no longer works.

I have attached a zip file, containing both the formatted code, and the debug version (debug has blank lines, and should be easier to follow).

Have fun and if you would like to create any other levels, we can add them to the game (just add DATA toward the end of the code)

-Paul
You do not have the required permissions to view the files attached to this post.
User avatar
MADrigal
Site Admin
Posts: 1189
Joined: Sun Sep 15, 2013 1:00 pm
Contact:

Re: Kapooka - homebrew logic game

Post by MADrigal » Sat Jan 09, 2010 10:50 am

This new version is really great, man! :-)

I applied a small fix to listings, making them readable on Windows notepad too (you probaably saved them on Linux, and there were no line-end characters).

I'm sending the new files via email now.

Of course I played the game and yes, now it loads all 11 levels correctly without any "error 19". :)

I please you to write a small introduction to it, which you'll include in the zip archive. I'll gladly put it on the CreatiVEmu website "basic listings" page. :)

Thanks *VERY* much for all the effort! The game is truly beautiful!!
User avatar
mr_bogus
Posts: 24
Joined: Fri Jun 13, 2008 8:40 am

Re: Kapooka - homebrew logic game

Post by mr_bogus » Sat Jan 09, 2010 1:38 pm

Thanks for the help with POKEing 1195 & 1197 Luca! I have made the name consistent and added more information to the readme file.

New version is attached :)
You do not have the required permissions to view the files attached to this post.
User avatar
MADrigal
Site Admin
Posts: 1189
Joined: Sun Sep 15, 2013 1:00 pm
Contact:

Re: Kapooka - homebrew logic game

Post by MADrigal » Sat Jan 09, 2010 2:36 pm

Just sent you an email with minor fixes to the "readme" and the "debug" listing.

Thanks very very much for the nice Hanukka gift! ;)
User avatar
MADrigal
Site Admin
Posts: 1189
Joined: Sun Sep 15, 2013 1:00 pm
Contact:

Re: Kapooka - homebrew logic game

Post by MADrigal » Sat Jan 09, 2010 6:05 pm

The updated version is finally online on the website.

thanks for this great addition, Paul!!! ;)
User avatar
carlsson
Posts: 507
Joined: Fri Jun 13, 2008 7:39 am
Location: Västerås, Sweden

Re: Kapooka - homebrew logic game

Post by carlsson » Mon Jan 11, 2010 10:16 am

Nice, it makes me slightly more eager to have another attempt with creatiVision Basic. Previously I found my way of thinking and programming hit too many of its limitations.
User avatar
MADrigal
Site Admin
Posts: 1189
Joined: Sun Sep 15, 2013 1:00 pm
Contact:

Re: Kapooka - homebrew logic game

Post by MADrigal » Tue Jan 12, 2010 12:34 am

Well CV BASIC is quite crap because of nasty limitations (very slow, very few RAM space for listings) but it has a few positive features as joystick, video and sound management.

Coding games for CV BASIC is not hard in my opinion, it deserves a try. :)

I suggested Paul to update Kapooka by adding sound effects and tunes. Can't wait to try the updated version with sounds! ;)
User avatar
mr_bogus
Posts: 24
Joined: Fri Jun 13, 2008 8:40 am

Re: Kapooka - homebrew logic game

Post by mr_bogus » Tue Jan 12, 2010 9:12 am

I wish there was a way to directly PEEK/POKE the character memory referenced by the screen, rather than using an array + plot. This would speed up many games, and the ability to read the screen's character memory would simplify extra array (or in the case of Kapooka, finding a contiguous block of memory by trial and error, then using this to store the level).

I will try putting in sound next chance I get, my main concern is slowing down the game. However the 2nd book of programs mentions a POKE command to start/stop a sound, so that may be an idea, running other instructions/s between, rather than freezing everything while the "SOUND" command plays.
User avatar
carlsson
Posts: 507
Joined: Fri Jun 13, 2008 7:39 am
Location: Västerås, Sweden

Re: Kapooka - homebrew logic game

Post by carlsson » Tue Jan 12, 2010 11:59 pm

I fiddled a bit with that in .. oh dear, was it december 2007?! I was almost certain it was in 2008, but anyway...

I never got it to work, but in the Second Book of Programs for the Wizzard, there is this example:

10 PRINT PEEK(12289)
20 POKE 219,193

After execution, one should type some text, type CLS, press reset, type NEW followed by another PRINT PEEK(12289) and the text you typed before appears again.

Address 12289 equals to $3001, which is VDP_Status_Write. It is the register we will want to access twice everytime we want to set up the VDP pointer and a command.

The screen is divided into three segments of 256 characters (32x24). POKE 218 selects a position with the current segment while POKE 219 selects a segment as follows:

POKE 219,208 = lines 1-8, POKE 219,209 = lines 9-16, POKE 219,210 = lines 17-24
POKE 219,207 moves the cursor to top of the screen, equal to POKE 218,0:POKE 219,208.

The book says POKE 219 with values below 197 can result in strange displays. Now, in the example above it is set to 193 = $C1? I presume this is a different (earlier?) part of the VDP memory.

The interesting part is PEEK(12289). This register is said to be write-only, so I thought one needs to STA or similar to affect it. Perhaps Basic makes a read then stores back the value (in this case a failed read, so zero or bus noise?) to the address you PEEKed? I suppose it is pointless trying to POKE 12289 from Basic due to the vast number of possible VDP calls inbetween two POKEs. There does not seem to be any SYS, CALL, USR or similar functions. Otherwise one could have POKEd some unused CPU RAM with a short routine that sets up the VDP, reads some value and stores into a CPU RAM address accessible from Basic.

In any case, I found an old thread on AtariAge with a VDP Programmer's Guide that seems quite easy to follow. It even came with programming examples for Z80, 6502 and TMS9900. Unfortunately he who scanned the guide omitted the examples as he found them not required. Perhaps he is right, but it makes me wonder which 6502 machine TI would have designed programming examples for. (c) 1984 it says, by which time the creatiVision was on the market but I doubt they would include specific creatiVision programming examples in the guide.

If I understand correctly, to read from VRAM one would need to:

LDA #<address
STA VDP_Status_Write ; $3001
LDA #>address ; MSB = $00
STA VDP_Status_Write
LDA VDP_Data_Read ; $2000

Now what address is "address"? We know from above the logical screen begins at what looks like $D000. That is not a VDP address since it only contains 16K. According to the Barry Klein's third Wizzdom newsletter (probably also documented elsewhere), the creatiVision Basic defaults to the following VDP memory map:

$0000-$07FF: 2K character generator (for custom characters?)
$0800-$08FF: 256 bytes DATA area (?)
$0900-$0FFF: 768 bytes unused??
($0800-$0FFF equals a 2K sprite shape, but I tend to remember creatiVision Basic doesn't do sprites)
$1000-$12FF: 768 bytes video display (screen matrix)
$1300-$137F: 128 bytes sprite attributes (??)
$1380-$13BF: 32 bytes colour table
$13C0-$1BFF unused?? (2112 bytes)
$1C00-$3BFF: 8K Basic program
$3C00-$3FFF: 1K unused ??

Let us assume POKE 219 is stored with $C0 + high byte of address to the video matrix. It suggests the POKE 219,193 at the top would point the video matrix to $0100, in the middle of the character generator. It should be possible to investigate by setting up a large generator, then issue the PEEK(12289) followed by POKE 219,193 to see if the screen is filled with "garbage" that can be identified as ASCII representations of the binary data, if you follow me. Now, if the area between VDP $13C0 and $1BFF really is unused, in theory we should be able to e.g. POKE 219,216 to move the video matrix to $1800.

Barry also notices the CPU RAM is mirrored on every 1K between CPU $0000-$1FFF. Those POKE 1195 and 1197 thus probably just as well could be replaced by POKE 173 and 175? In Barry's newsletter he mentions POKE 170 and 171 for the same purpose. He also mentions the 192 we just added to VDP so that seems correct.

Once we are this far, to read what is located on position X,Y we would need this:

Code: Select all


; .X contains column, .Y contains row
    LDA #$00
    STA vh+1
    TYA
    ASL ; multiply rows by 32 = five shifts to the left
    ASL
    ASL ; accumulator at most 24*8 = 192
    ASL ; carry can be shifted after four ASL's
    BCC l0
    INC vh+1
l0: ASL
    BCC
    INC vh+1
l1: STA vl+1 ; low portion of the multiplication
    TXA
    CLC
vl: ADC #$00
    STA VDP_Status_Write ; $3001
vh: LDA #$00 ; will never be more than $02
    STA VDP_Status_Write ; MSB must be %00 anyway 
    LDA VDP_Data_Read ; $2000
    STA somewhere_you_can_fetch_it_from_Basic
Interesting theory, but I'm afraid it won't be doable unless we produce yet another modified Basic.

However the observation about PEEK(12289) and the possible possibility to move around the screen matrix intrigues me. Will it work, has it been done in Basic? While you obviously can't plot anything to an invisible screen, the idea of having two or more screens available to go back to may open up for interesting possibilities. Perhaps a disassembly of the Basic is in order, to at least clarify what PEEK really does.

One possible option might be if we can alter the DATA pointers. From the VDP memory map above, we see that the DATA area begins at $0800. Based on what we already learned, that equals $C800 => high=200, low=0. Actually addresses 1194 and 1196 are preset to 200 while addresses 1195 and 1197 are 0. In theory we could do this:

A=PEEK(1194)
B=PEEK(1195)
C=PEEK(1196)
D=PEEK(1197)
P=X+Y*24
H=INT(P/256)
L=P-256*H
POKE1194,H+192
POKE1196,H+192
POKE1195,L
POKE1197,L
READY
POKE1194,A
POKE1195,B
POKE1196,C
POKE1197,D

However this does not work, since Basic expects DATA in some sort of pattern or token. One gets ERROR 18 upon running this. Grmbl.. I thought I was close to a solution. Maybe I still am, just that I don't know how to finish this line of thinking.

An example program:

10 DATA2,6,2,6,7
12 DATA3,4,9
16 FORI=1194TO1197
17 PRINTPEEK(I);" ";
18 NEXTI
19 PRINT
20 READB
21 IFB<9THENGOTO16

It illustrates how 1194 and 1196 are constant 200 ($C8 - $C0 = 8), how 1195 is constant 16 (combined length of all DATA statements) and how 1197 is increased from 0 to 14. In order to trick READ into getting a value from the screen matrix, it seems to me that 1194 and 1196 must equal the segment (208-210), 1195 probably should be 1 and 1197 should be the X index within the segment.

While I haven't solved the problem, I observed that if I screw around with address 1194 and 1196, I can make the Basic program disappear from getting LISTed, but still is possible to execute. :lol:
User avatar
carlsson
Posts: 507
Joined: Fri Jun 13, 2008 7:39 am
Location: Västerås, Sweden

Re: Kapooka - homebrew logic game

Post by carlsson » Wed Jan 13, 2010 8:13 am

Before I fell asleep last night, I was thinking a bit more about what went wrong. Maybe it should be READ Y$ instead of reading a numerical value? But no, I just tried and it works as bad. I even went as far as trying to print a faked Basic line on screen:

10 CLS
11 POKE218,2
12 POKE219,208
13 PRINT"10 DATA2"
14 POKE1194,208
15 POKE1196,208
16 READB

It still ends up with ERROR 18. Perhaps what is stored in the DATA area isn't ASCII text like I remember the Basic program itself is stored, but rather the DATA statements get processed and stored in a different form? Double bah.

By the way, does any of the emulators have a monitor where one can read the contents of the emulated VDP RAM too? Would the MESS emulator offer such features?
Post Reply