Writing / Reading VRAM - noob questions

Resident (39)

14-12-2021, 10:31

Thanks a lot! Everything is going the right way at the moment. At the beginning, the entire architecture of the MSX seemed hellishly complicated, but everything becomes clear now

Quick questions:

1. If I don't have SP (stack pointer) set in the code, where is the stack by default in MSX1?
2. When I don't use a lot of WRAM (below 3-4KB), it is safer to use than C000 or E000? Because from what I read, MSX1 with 8KB WRAM start WRAM from E000? (cartridge code, start $ 4000, screen mode 1)
3. In general, is the beginning of WRAM eg E000-EFFF a safe place in MSX1? I don't know exactly what memory locations the BIOS uses to avoid conflicts.

Par Grauw

Ascended (10768)

14-12-2021, 11:20

siudym wrote:

1. If I don't have SP (stack pointer) set in the code, where is the stack by default in MSX1?

Stack pointer will be somewhere in the C000H-FFFFH region.

The area from F380H to FFFFH is taken for the system area, then below there is space that can be reserved by extended functionality, and below that is the stack. The most common thing to reserve space is the DiskROM if the machine has a disk drive. It takes up quite a chunk of space, way into the E000H-EFFFH range, or maybe even somewhere in DxxxH (not 100% sure).

So in a bare MSX system the top of the stack will be at F380H, but if there’s a disk drive it will be somewhere in the ExxxH region. This is why some cassette games don’t work when a disk drive is present, and the reason why the SHIFT boot key exists to disable the disk drive.

As far as I know, when you have a program in ROM format, if it boots straight into it and never returns from the INIT call, you can assume F380H and set the stack pointer there explicitly.

In general I don’t set the stack pointer manually, it should point to the top of usable space and everything above it should be in use for something else. I do have a check in most of my programs which checks if the stack pointer is high enough that I have enough work space left.

siudym wrote:

2. When I don't use a lot of WRAM (below 3-4KB), it is safer to use than C000 or E000? Because from what I read, MSX1 with 8KB WRAM start WRAM from E000? (cartridge code, start $ 4000, screen mode 1)

Speaking generally, C000H is the safest, speaking for a ROM which never returns from INIT call, E000H is also safe.

(I believe there is only one MSX1 with 8K RAM, and a RAM expansion is always easy to add, so to be honest supporting it is a bit of an exotic effort.)

siudym wrote:

3. In general, is the beginning of WRAM eg E000-EFFF a safe place in MSX1? I don't know exactly what memory locations the BIOS uses to avoid conflicts.

In a ROM, yes it is safe unless you return from the INIT call. For a COM program it’s not, because DOS means a disk drive is connected. For a BIN program, I would generally also assume a disk drive is connected and stay away from the high memory regions.

Par gdx

Enlighted (6215)

14-12-2021, 11:46

Look the memory map here for the stack. The pointer varies in this area and the top the stack is indicated by the system variable STKTOP

Par siudym

Resident (39)

14-12-2021, 22:11

So I will move the variables from E000 to C000 it will be safer.
There are two things left to deal with - some joystick or keyboard reading to be able to control the sprite. And generating some simple SFX sound.

The joystick is probably not particularly difficult, I found a topic like this: https://www.msx.org/forum/msx-talk/development/fast-joystick...

I think it will be more difficult with sound - are there also any BIOS CALL's? I can see GICINI, WRTPSG and RDPSG.

Par ARTRAG

Enlighted (6935)

14-12-2021, 23:01

You have to read the manual for AY8910 to see how audio works.
You can find it here (with many useful documents)

http://map.grauw.nl/resources/

Par aoineko

Paladin (1004)

14-12-2021, 23:10

For the joystick, it is indeed very simple (see GTSTCK).
For the keyboard, it is also rather simple but the data are arranged in a not very intuitive way (see SNSMAT). The keys are arranged by "row" and we get the information row by row. The easiest way is to use buttons that are on the same row like Space and the directional-keys that are in row #8.

For the sounds, it depends on what you want to do. If you want to play very simple sounds, it is possible to use the BIOS.
Otherwise, the best is to integrate a library to play music (e.g. pt3) and sounds (e.g. ayFX).

Par santiontanon

Paragon (1805)

15-12-2021, 00:02

Yeah, if you want to collaborate with an external musician, then of course, it's better to use an existing library to play any of the formats that is supported by existing trackers. But if you are going to do your own music, doing your own player is not too hard: just have a table with the notes of the song, and just go through that in a small function in the interrupt routine (called at every frame), that sends the right values to the registers to play the notes, and you are done. If you want to add effects, like fade-in/out/etc. then a bit more elaborate, but you can build it bit by bit!

Par siudym

Resident (39)

15-12-2021, 00:10

ld a,0/1/2 (cursor/joy1/joy2)
call GTSTCK
ld (joystick),a

Now the state of the bits in the joystick variable can be read and the objects can be moved depending on the state of the bit?

The order of bits is as follows:?
0-UP
1-DOWN
2-LEFT
3-RIGHT
.
.
6-BUTTON A
7-BUTTON B

At the beginning I would like to make some simple sounds (any). Music rather another time.

Par thegeps

Paragon (1189)

15-12-2021, 00:22

Ld a,0/1/2
Call gtstck
And a
Ret z; return if no move
Dec a
Jp z,up
Dec a
Jp z,upright
Dec a
Jp z,right
Dec a
Jp z,downright
Dec a
Jo z,down
Dec a
Jp z,downleft
Dec a
Jp z,left
Dec a
Jp z,upleft

A value changes from 0 to 7, each value is a direction
You can use
Cp 1
Cp 2
And so on and preserve A value, but if you don't nees so (and usually you don't) dec is faster

Par thegeps

Paragon (1189)

15-12-2021, 00:18

Buttons have to be check with gtstrg