Diamond Hunt

[Boray]

Hey, I just tried your programs on real vic-20s, and guess what? They don't work! I tried Diamond and Autobaun on my 2-prong vic and on a CR vic. (Both PAL) Didn't work on any of them. The graphics just looked strange. It looked more strange on the 2-prong and there the screen went blank sometimes. One the CR it just looked like you had the wrong charterset poke....

/Anders

[Boray]

I have found the problem. You use POKE 36869,72 where you should use 36869,200. Or use a poke that works on both expanded and unexpanded vics: POKE 36869,(PEEK(36869)AND240)+8. With 72 you put the screen memory (video matrix) at some unallowed position. So there must be a VICE bug here. Have you tried your programs on a real vic-20?

Now when I tried to find your homepage (with google), I found VicMemorySaver.zip on http://www.kdef.com/geek/vic/
Seems you used POKE 36869,72 there too...

From your doc:
>NOTE: This method is not useable by tape drive users because,
> unfortunetly, the disk drive doesn't have a buffer in
> the computer.

Of course you can use the tape buffer for graphics with tape only as well, if you poke them in there from the main program.

Anyway, I thought you should know that your programs doesn't work...

Kind Regards,
Anders

[carlsson]

Admittingly, I have never quite understood the VIC-I addressing, and in particular not how it works once it is inside VIC-20. This looks like a nice, believable and not too technical article:

http://www.atarimagazines.com/compute/i ... _Video.php

Based on that article and PEEK(36866)AND128=1, I get the following values:

POKE 36869,72 = screen: vblk 4.5 ($9200), char: vblk 8 ($0000)
POKE 36869,200 = screen: vblk 12.5 ($1200), char: vblk 8 ($0000)

$9000 equals the address of the VIC chip itself, and $9200 would be unconnected I/O space. It may be true that the VICE emulation treats $9000 and $1000 as the same value, such screw-ups in emulation have happened before.

Update: Ayep, at least VICE 1.16 yields the same output for POKE 36869,240 and POKE 36869,112. Perhaps it was on purpose, thinking it is not possible to direct the video matrix to ROM or I/O space anyway. It is by the way among the examples Viznut made of possible unexplored video tricks, to make VIC chip read from odd locations and have CPU activity to draw an image.

[Mike]

I looked at the URL above, and it seems to be a good explanation how the VIC chip sees the RAM.

POKE 36869,255 leads to a wrap-around from block 15 to block 0 for the charset with inverse characters, this is what we use to print UDG's and normal characters simultanously.

VICE is very inconsistent in that regard. For example:

(unex. or +3K): POKE 36867,48 reveals an extra line below the screen. On real hardware, I see 6 additional POKEable characters (what I use for my TI$ clock), and then VIC wraps to block 0 and displays the definitions of '@' and 'A' in random colours.
VICE continues at address 8192...

(+8K or more): I use POKE36869,204 to let both charset and screen start at block 12 (address 4096), and use chars 16-255 for bitmapped graphics (160x192 pixels). Upon pressing C=/Shift:
- on real hardware, the charset appears on the right hand side.
- with VICE, RAM at 8192+ is displayed!

... however, for some unknown reason, the wrap-around *works* on VICE with POKE36869,255 ... me thinks the developers programmed some conditional statements to get the most used cases right (but others are wrong). I might take a look at the xvic source to strengthen this claim (and maybe send a correction to the VICE team).

Michael

[carlsson]

Yeah, I just sent a bug report linking to that Butterfield article, regarding unconnected space. I have a copy of the source too, and maybe several of us could look into it if there are obvious fixes to make it behave better.

The addresses as far as VIC-I is concerned seem to be 14-bit, and then the glue logic dispatches these addresses into different parts of VIC-20 memory map if I understood correctly.

We all know that an external 3K expansion is not accessible by the VIC chip, but what about the unused I/O blocks? There are a few expansions, like the Rabbit tape turbo, various speech cartridges and perhaps the 40/80 cartridge, which map into those I/O blocks. Would it be possible to map a RAM expansion into it, and somehow fool the VIC chip into using it for video matrix or similar, or is the bus separation preventing this too?

[Mike]

I took a look at the sources, and there we have the function: void vic_update_memory_ptrs(void), in the file \src\vic20\vic.c

It looks the VICE team used a correct way to calculate both screen and charset *base* pointers... but they don't handle the wrap-around correct;

except in the case POKE 36869,255 (as I wrote above): here (emulated) memory "before" the original charset is used, which then takes care about the wrap-around. There is an if-clause which checks for char_set being at $1E00.

The correct solution of course is to create a *complete* copy of what the VIC chip actually sees. The VIC chip can only see at most 4K ahead, so the only thing that needs to be mirrored for the wrap-around actually *is* the char-set:

Code: Select all

Block   VIC address   CPU address   contents
0..3    0..4095       32768..36863  ROM char set
4..7    4096..8191    36864..40959  I/O (unusable)
8       8192..9215    0..1023       bottom 1K RAM built in.
9..11   9216..12287   1024..3072    unconnected (unusable)
12..15  12288..16383  4096..8191    main 4K RAM built in.
-----------------------------------------------------------
followed by (VICE only!):
-----------------------------------------------------------
16..19  16384..20479  32768..36863  ROM char set (mirror copy)

This would need 20K RAM for the complete VIC image. Also, the VIC RAM needs to be synced with the CPU RAM.

Anders, since you already contacted the VICE team, would you be so kind to include my thoughts above in a reply mail as soon as you're contacted by them?

Greetings,

Michael

Edit: I quick check revealed, that the wrap-around for the colour RAM doesn't work at all. For example, unexpanded VIC > POKE 36867,48 (reveals extra line) > POKE 37888,x changes the colour of 7th char on this line. This doesn't work with VICE, either.

Edit 2: Another question is, whether the VIC chip is still able to access its colour RAM over the "normal" bus. I cannot check this on a real VIC at the moment. This test program places the char-set into colour RAM:

Code: Select all

0 POKE 36866,22:REM force screen, char set at whole KB
1 POKE 36869,12*16+5:REM screen at 4096, char set at 37888
2 PRINT "{CLR}";
3 POKE 4096,0:REM place '@'-sign at top-left corner.
4 FORT=0TO7:POKE37888+T,T:NEXT

The left side of the char could be/should be junk (unconnected!), but if the VIC chip accesses its own colour RAM over the normal data bus, there will be a binary counter along in the char like this:

Code: Select all

%%%%0000
%%%%0001
%%%%0010
%%%%0011
%%%%0100
%%%%0101
%%%%0110
%%%%0111

% = junk(?)

Indeed this works with VICE (sans junk), as I've just tested, but does it do on the real hardware?

[GreyGhost]

Thanks For all the input on this program. These programming techniques where used by me on a real Unexpanded Vic20 back in 1990, and they worked fine. A few things i want to add:

First, this game was never meant to run on an unexpanded vic. (The Autobaun game on my web site also works with 8k or more expansion. This was so I could compile with Austro-compiler. This doesn't include the version of Autobaun I wrote for the 20 line game contest.)

And second, in the programs on the geek web site, I said this wouldn't work for tape drive users because it defeats the purpose of memory saving to use the main program to POKE data into the tape buffer. You've already wasted memory by putting the char data in the main program. And if you use it with a tape player as is, it will mess up all your data when your main program loads, unless you relocate the tape buffer to a different location(say screen memory(location 4096 with more than 8k) while the game loads).

And just one thought, with a 3k expansion, Why couldn't you access this memory using this same technique? The tape buffer ends close to where the 3k expansion begins. The only problem I see is that the characters wouldn't start at a nice round number. Moving the start of basic back to 4096 would also be involved. Or, add another 8k cart to it and the Vic will do this on its own(i think).

I'm no expert and with the problems with the game, I hope someone out there had as much fun playing it as I did programming it. Anyone got to a really high level yet?

Thanks for all the input.
Rob

[carlsson]

And just one thought, with a 3k expansion, Why couldn't you access this memory using this same technique? The tape buffer ends close to where the 3k expansion begins. The only problem I see is that the characters wouldn't start at a nice round number.

I'm not sure if you're referring to putting custom characters in the 3K expansion space, or something else. As you probably have figured out, the VIC chip can not access the expansion memory, so it would not work. If it works on your real VIC-20, it is because it has been hacked with an internal 3K expansion or something like that.

[GreyGhost]

All the discussion about video matrix/char table location, I went back and checked my notes for myself. On the Geek Site in the document in the Zip File I said I used:

POKE36869,248 <--on an unexpanded Vic20

I used this on a real Vic and it worked.

At the time of writing the 8k version, I didn't know much about location 36869. With the char data poked into the cassette buffer, I ran a for-next loop in Vice to change the value in location 36869 and waited to see the characters on the screen. Then I peeked 36869 and got 72.

I used the fomula in Chapter 5 of Computes First Book of Vic to check myself and sure enough you're right. The value should be 200. Thanks Boray for the heads up. I never ran the expanded versions on a real Vic.

Got to say though, Its cool you guys found a qwerk in Vice. Perhaps if they fix it, some vic game that never worked on the emulator right, might work.

Later

[GreyGhost]

OK, Here it is an all new version of Diamond Hunt.

http://robmurphysc.tripod.com/

Look for it on the Games Page.

This is Version 1.29. I've added animation to the player char and all the monster chars. You receive an extra man for every 4 levels completed. The error with the screen matrix has been corrected. This should work on a real vic 20.

Anyone find any other problems, just let me know.

A note: This version uses locations 664-743 for the extra monster animations. I animated the player char by poking values directly to its stored locations.

Have Fun,

[Boray]

Just tried it and it works great. Feels fast to play it. The only problem I can report is that the text on the info/score screen sometimes is very hard to read. (Another danger in developing on VICE ). I would change the text color there to something darker, for example black.

/Anders

[aneurysm]

i liked the game..