[V9990] Q&A Official Thread | MSX Resource Center (Page 7/23)

Paragon (1428)

03-03-2016, 23:34

ok, I should clarify this point ASAP.
It is not a matter of how turbo basic is loaded.
After I do the bload"xbasic.bin",r I still have the same amount of memory as I had before (23414 on a regular msx2 with dos 1.0, a bit more after using a few tricks, so I end up having 24800 k approx of basic memory).
After loading the music and sound effect replayers I end up with less than that (22 or 20 k depending on the sound support)

You should know that Turbo basic uses this free memory to both store the uncompiled basic code, AND the compiled code!
So a 7,5k basic code will requiere 12 or 13 k to store the compiled version (if you compile the full 7,5k basic code), thus using ALL basic available memory.
This and only this is the main handycap of Turbo basic! it stores the Basic original code AND the compiled code in the same work area, making the biggest turbo block possible about 7,5k (or less if you use certain ASM routines)

It is unthinkable for me to run out of memory with 24,8k of memory (it never happened to me) but just try to create a full game engine with lots of features at a reasonable speed with 6 or 7 k. After a few years you will end up being a genious of simplifying routines to make it happen.
I am aware that anyone who does not program on turbo basic to create games (99,9% of msx coders?) cannot grasp how really SMALL 7 k of basic code really are.
You need to get really REALLY smart to make a game with so many features with that work space. Belive you me. (if you don ot belive me, just try it )

Par Kai Magazine

Paragon (1428)

03-03-2016, 23:35

Grauw wrote:

As far as I understand, the .BIN-versions of Basic-kun also don’t consume Basic memory (they run in the unused lower 32K RAM), so there you also have 23K free.

However, Basic-kun compiles the turbo blocks to assembly code in the same 23K as the Basic-program. So that 7.5K limit means that it generates 15.5K assembly code, and if the Basic program would grow any bigger than 7.5K it won’t have enough memory anymore to compile the turbo block.

Correct me if I’m wrong, but that is my understanding.

Grauw, that is absolutelly correct. I saw your message after I published mine. You were faster (and clearer) than me

Par zPasi

Champion (499)

03-03-2016, 23:37

Grauw wrote:

As far as I understand, the .BIN-versions of Basic-kun also don’t consume Basic memory (they run in the unused lower 32K RAM), so there you also have 23K free.

However, Basic-kun compiles the turbo blocks to assembly code in the same 23K as the Basic-program. So that 7.5K limit means that it generates 15.5K assembly code, and if the Basic program would grow any bigger than 7.5K it won’t have enough memory anymore to compile the turbo block.

Correct me if I’m wrong, but that is my understanding.

I know that the compoled code aaldalsoldo eats memory. But at least the versions I have, the cart version leaves more memory for the basic code.

(Damm this doesnt work right on the ipad)

Par Grauw

Ascended (10768)

03-03-2016, 23:44

Doesn’t it all depend on the Basic code that you’re compiling?

Some Basic statements will no doubt generate more compact assembly code than others.

Also, compiled code memory usage is per turbo block. If you have many small turbo blocks, you can have a larger Basic program as a whole than with a single large turbo block.

Par tvalenca

Paladin (747)

04-03-2016, 01:14

Grauw wrote:

As far as I understand, the .BIN-versions of Basic-kun also don’t consume Basic memory (they run in the unused lower 32K RAM), so there you also have 23K free.

However, Basic-kun compiles the turbo blocks to assembly code in the same 23K as the Basic-program. So that 7.5K limit means that it generates 15.5K assembly code, and if the Basic program would grow any bigger than 7.5K it won’t have enough memory anymore to compile the turbo block.

Correct me if I’m wrong, but that is my understanding.

Really? That's a HUGE downside!

Par hit9918

Prophet (2932)

04-03-2016, 12:31

code size, hunt for things that are same every level.
do you have the objects rack? this one

	for i = 0 to racksize
	on objectid[i] gosub 100,200,...
	next
	...
	
100	'bullet move. id = 1 is bullet
110	x[i] = x[i] + dx[i]
120	y[i] = y[i] + dy[i]		'columns of the rack, x,y,dx,dy,hitflags,whatever.
130	return
200	'turtle move. id = 2 is turtle
210	....
230	return

that is practicaly all that is to a game.
one got constructor and destructor and move codes for things.
some trigger list runs the constructors.

an elevator too could be an object.
an object which does push the player.
some logic outside the player code.
and then a trampoline too is code outside the player code.
the player code stays more lean.
a feature takes only time when it is onscreen.
and when it is not in level2 then one can easily snip it from level2.bas.
"things only take time when onscreen, only take codesize when in the level".

have another list where objects are noted straight in that list without bubbles.

	for l = 0 to movelistsize - 1
	i = movelist[l]			'i = index in objects rack
	on id[i] gosub 100,200,300,...
	next
	'now all movable things have moved

this needs two functions to add and remove an object from this list.
any object can get constructed anywhere in the rack, the rack memory can be used by all object types.
when one has multiple enemy types then this saves object rack RAM and speed.

when needed you can specialize more things to such a list.
the first candidate is playerbullets. because of the exploding loop amounts of collision detection.

Par hit9918

Prophet (2932)

04-03-2016, 12:31

by the way do you have trigger lists in DATA lines?
such kind of stuff can go to vram.
a vram adress setup is like a RESTORE.
an INP from VDP port is like READ a byte.
a kilobyte is an itching amount in BASIC RAM while in vram it is nothing.

mhm I wonder, I heard something about 7k budgets, where have the level maps of BASIC games been?
that needed an USR to make tile test and such?
looks like another candidate for 9990 vram.
how much kb does the gfx9000 have? I cant see it in wiki.
I dont know about the plenty different BASICs, mapper support and whatnot.
I imagine best is the fastest BASIC compiler + 9990 vram.

Par hit9918

Prophet (2932)

04-03-2016, 12:51

oh, I have forgotten that I already posted some of that.
much action in the thread, I got to read.

Par AxelStone

Prophet (3199)

04-03-2016, 13:17

syn wrote:

I disagree. The coding language itself isnt the problem. The downfall is content, as in creating original graphics, music, gamedesign etc etc. At least from what I have seen, most "big" projects that get delayed/forgotten is due to lack of content, while the coding itself is mostly done. Look at Xtazy, the gaming engine was somewhat complete (gfx, music, hitdetection etc). Two working levels. Imo It is content creation that makes ppl lose their motivation often (because they prefer to code or whatever)

The reason people keep making small msx1 games (other than nostalgia/preferring msx1) is that they somehow think msx2/2+/tr/gfx9000 games should be epic/big/megaprojects, while instead they could have just made a small puzzlegame for those platforms.

I suposse it's a mixture of both. ASM is not a friendly language, coding in ASM takes more time that coding in BASIC for example, and this translates into fatigue. If you are planing a game development during 1 year, in BASIC you can use 6 months for coding and 6 months for create content. In ASM the requeriments are higher and you could need 10 months to make the engine, so you are tired and don't have the strenght to create content.

I think that MSX has lacked alternatives: use BASIC (simplest language) or ASM (hardest language) with no middle option. Fortunately thanks to the work of people like Javi Lavandeira and it's wonderful articles Relearning MSX , we start to have alternatives as MSX-C with great potential for games or even apps. I'm trying it and I'm really pleased with the MSX-C (still learning of course).

It should be really great a similar serie for "Relearning Turbo Pascal" (another great language), in order to get the widest possible range of options for developers. I'm sure that we could see very interesting things made in C/Pascal :)

Par hit9918

Prophet (2932)

04-03-2016, 13:25

Quote:

If anyone would be kind enough to assamble them in such a way I can bload them from basic and use them with DEFUSR, we could have acces to the GFX9000 graphic commands from Basic

how many kilobytes would that need?
A hand full of gosubs that do some OUT for vpoke, copy, set_scroll can serve a whole game.
The scroll X register bits are laid out unhandy?
This is NOTHING compared to all the burden on MSX1 and MSX2.
The many problems discussed in those threads dont happen on 9990.