Weird problem with PSET - help please

Ambassador (5645)

22-12-2014, 18:24

The game I'm making has an 'overworld' mode and a 'battle' mode.
As entering the battle mode means loading between NBASIC blocks and so, losing my variables, I have a system in which they're stored in VRAM. This includes the last position of the player on the map.

At the start of the 'main' program (the overworld), the coordinates on the map (which are MX and MY) are read from VRAM, like so:

I tested it thoroughly and this works correctly.
Now, the problem is, when I convert the values and try to write to VRAM, something goes wrong:

The values all check out; the calculation is correct, but the PSET commands only place black (color 0) points, while the variables do hold the right numerical value.

Por JohnHassink

Ambassador (5645)

22-12-2014, 19:21

Correction: it's not the PSET command that goes wrong, but the values of the strings and variables are empty...

Por meits

Scribe (6530)

22-12-2014, 19:23

Couldn't you just try and poke your variables into (v)ram and peek them afterwards?

Por JohnHassink

Ambassador (5645)

22-12-2014, 19:26

Never mind, I was doing CALL TURBO OFF before conversion.

Por JohnHassink

Ambassador (5645)

22-12-2014, 19:27

I considered using PEEK and POKE, but I have no idea which addresses to POKE it to.

Por meits

Scribe (6530)

22-12-2014, 20:13

I'd vpoke as high as possible, or on a page where you don't have graphics...

Por Grauw

Ascended (10681)

22-12-2014, 20:17

If you use VPOKE / VPEEK, you can store bytes (0-255).

If you want to store larger values than a byte, get the low byte like so: L = X MOD 256, and the high byte like so: H = X \ 256. Combine them back like so: X = H * 256 + L.

In screen 5, pages start at &H0000, &H8000, &H10000 and &H18000, and one line takes 128 (&H80) bytes. There is free memory at the bottom of every screen, at some point the palette is stored which might get overwritten, but the ends of each page (e.g. &HFFFE, &HFFFF, etc.) should be quite safe for temp variable storage.

Por anonymous

incognito ergo sum (116)

22-12-2014, 20:57

Thanks for your help guys. I've solved the issue now, but I'm going to look into VPOKE / VPEEK as well.

Por ARTRAG

Enlighted (6914)

22-12-2014, 22:22

As you have 212 lines on the screen, the invisible area in VRAM (area covered by the border) starts at:
- address 212*128 = &H6A00 (for page 0)
- address (256+212)*128 = &HEA00 (for page 1)
- address (512+212)*128 = &H16A00 (for page 2)
- address (768+212)*128 = &H1EA00 (for page 3)

Note 1: as you cannot use numbers on 17 bits in vpeek and vpoke, for page 1, 2 and 3, you have to use the command:
set page ,X (page active but not displayed)
and refer to addresses of page 0 within page X

Note 2: the VRAM area under the border is also used by sprite definitions and sprite attributes.
When you display a given page, the basic activates also the sprites in that page.
This means that if you overwrite the sprite data and than you do
set page X,X (page displayed and active)
you could see some garbage sprites.

Por AuroraMSX

Paragon (1902)

22-12-2014, 23:01

Wouldn't it be easier (and more efficient) to CLEAR a small buffer in RAM (not VRAM) and POKE/PEEK (not VPOKE/VPEEK) the values there? Alternatively you could set the start address of your BASIC program to e.g. &H8080 and POKE/PEEK below there...

Por JohnHassink

Ambassador (5645)

22-12-2014, 23:14

Well, I'm using NestorBASIC so I guess I'm kind of restricted in terms of addresses to put stuff on.