Weird problem with PSET - help please

Pagina 1/2
| 2

Door JohnHassink

Ambassador (5407)

afbeelding van JohnHassink

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.

Aangemeld of registreer om reacties te plaatsen

Van JohnHassink

Ambassador (5407)

afbeelding van JohnHassink

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... Question

Van Meits

Scribe (5487)

afbeelding van Meits

22-12-2014, 19:23

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

Van JohnHassink

Ambassador (5407)

afbeelding van JohnHassink

22-12-2014, 19:26

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

Van JohnHassink

Ambassador (5407)

afbeelding van JohnHassink

22-12-2014, 19:27

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

Van Meits

Scribe (5487)

afbeelding van Meits

22-12-2014, 20:13

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

Van Grauw

Ascended (8387)

afbeelding van Grauw

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.

Van anonymous

incognito ergo sum (109)

afbeelding van anonymous

22-12-2014, 20:57

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

Van ARTRAG

Enlighted (6236)

afbeelding van ARTRAG

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.

Van AuroraMSX

Paragon (1901)

afbeelding van AuroraMSX

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...

Van JohnHassink

Ambassador (5407)

afbeelding van JohnHassink

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.

Pagina 1/2
| 2