[V9990] Q&A Official Thread

about going out of memory, in BASIC there is the style "one code per screen".
and one cant do much more in the slow original BASIC.
else one can do same style as the asm games, "one code for the whole game".
and the 9990 has big vram, maybe some things can be put in vram.

Yes, one big (or several smaller ones) BLOAD (actually, it will need a small ASM loader inside the binary file since -apart from PowerBASIC and GBASIC- no BASIC supports BLOADing files to V9990 VRAM) and then you're good to go. You can even use NestorBASIC to take advantage from the Mapper Support.

I sent Konamiman an email asking if there are any documentation for writting plugins for it, so we could work in V9990 support for NestorBASIC. Or, at least, if he has plans to support it himself. He didn't replied yet and since it's been more than a few days, I'm wondering if I insist.

Thanks, Kai!

Just to mention: Just managed to load a 3-plane image on Video9000 emulation (back frame=v9958, mid frame P1 layer B and front frame P1 layer A)

Since I'm using plain BASIC, I BLOADed .SC5 files on Screen5, then copied using VPEEK and OUTed it to V9990. SLOW.LIKE.HELL!
BUT, there some catchs to make VIDEO9000 transparent:
First, you have to set Video9000 bits 3 and 4 on control port, to tell Video9000 that the output is Genlocked and both V9990 and video input will be displayed
Then set bit 6 to on V9990 R#8, to tell V9990 to output on pin /Ys when some color is meant to be transparent.
Finnaly you have to change the pallete color meant to be transparent setting the MSB on red component of that color code, because on V9990 you don't have a fixed color code for transparent color.

something like that:

1)
OUT &H6F,24 (you normally set to zero)

2)
OUT &H64,8:OUT&H63,162 (you normally set to 130)

3) 
OUT &H64,14:OUT&H63,0 (i'm setting color 0 is transparent)
OUT &H61,128:OUT &H61,0:OUT &H61,0

I do not quite understand what you mean, and probably you did not understand me either, because it is not a nightmare at all, as a matter of fact it is quite simple.
For example:
If the nexus.bas recieves the order to prepare and load "stage1.bas", the nexus loads all the graphics and prepares all the data, and then runs" stage1.bas".
The same for the rest of the stages. Quite easy.
Each Stage*.bas is a copy of the first stage, but with slight variations in it.
For example, in the stage1.bas you can have a walking robot which shoots bullets and falls if it finds an edge, another robot which launches bombs and turns back when it finds an edge (instead of falling) and another robot which flies and drops bombs, all of them weak and easy to kill. (this is the first area of Life on mars, by the way)
To create another stage/area/set of enemies, I get this very same stage1.bas, I save it as "stage2.bas" and I modify the AI of the enemies so, instead of a walking robot, I make a plant which jumps every few frames, and I make the enemies slightly stronger and harder. Then I save again.
In another stage I modify one of the 3 enemies AI to be a running bird which will pursue you even if you evade it.
In another stage I modify one of the 3 enemies AI to be a zombie...
Etc.

On Nuts, there are 3 main engines:
One with no colisions with the floor and the level is a straight line (final fight style) but with pickable boxes.
Another with no colisions etc, but with pickable knives
Another with ground colisions and different levels of height, so you can climb objects and fall into pits, etc, but with no items.
Depending on the stage we play on, the nexus will load one of those 3 engines.
This is quite easy, really...

I think that what Manuel is saying is that if you detect a bug in the common code for all stage*.bas, then you have to correct all the stage*.bas and test them all again. That's the "nightmare" of code duplication.