New game for MSX1 (Transball)

Page 14/20
7 | 8 | 9 | 10 | 11 | 12 | 13 | | 15 | 16 | 17 | 18 | 19

Par Louthrax

Prophet (2439)

Portrait de Louthrax

12-09-2016, 23:14

Just a quick guess here: RAM might be faster compared to ROM on turboR, so if your code has active wait-loops it might make a difference in R800 mode ? (Assuming ODO loads in RAM and other ways load in a ROM)

Par ARTRAG

Enlighted (6933)

Portrait de ARTRAG

12-09-2016, 23:55

Not in z80 mode...

Par Imanok

Paragon (1199)

Portrait de Imanok

13-09-2016, 23:00

Flashing the rom in a flashrom, stage 5 works ok.

Where do you initialize the stack?

Par santiontanon

Paragon (1771)

Portrait de santiontanon

14-09-2016, 01:10

I did not check the position of the stack. When loading the game as a ROM, the memory addresses are used as: first 16KB for BIOS, next 32KB for the ROM, and the last 16KB for RAM. Do you think that when launching the game from MSX-DOS the system uses more space out of the last 16KB of RAM than I was expecting, resulting in some corruption?

Par NYYRIKKI

Enlighted (6033)

Portrait de NYYRIKKI

14-09-2016, 01:24

santiontanon: This indeed starts to sound like that ODO does not initialize stack and you don't initialize stack... Stack is very much lower in MSX-DOS (~$E800) than when starting from cartridge ($F380). I would anyway say that what ever the problem is, it is not your problem. ODO needs to be fixed, not your program.

Par kanima

Master (194)

Portrait de kanima

14-09-2016, 01:39

santiontanon wrote:

I did not check the position of the stack. When loading the game as a ROM, the memory addresses are used as: first 16KB for BIOS, next 32KB for the ROM, and the last 16KB for RAM. Do you think that when launching the game from MSX-DOS the system uses more space out of the last 16KB of RAM than I was expecting, resulting in some corruption?

Yes, DOS will use some space, as will almost any drive hooked up. So, if you have 2 disk drives then there will be less memory available for programs compared to when you have only 1 disk drive or none. I'm guessing an SD drive will also need some work space. I'd say the area 0xc000-0xd000 is probably almost always available (unless you have a crazy amount of drives and other extensions), 0xd000-0xd800 is getting questionable, and 0xd800-0xe000 is already really in danger of being used by the system.

Bottom line is, you should always check the available space when your game starts. Use the highest memory address that you know you'll need for your work area, add some 256 or 512 bytes for the stack space you might need and then compare whether the resulting address is lower than the current stack pointer. If it isn't, just give out an error that there's not enough free memory for your game to run (including an advice to unplug some drives/extensions).

Par Ramones

Champion (264)

Portrait de Ramones

14-09-2016, 09:24

NYYRIKKI wrote:

ODO needs to be fixed, not your program.

Hi NYYRIKKI. Sorry, I disagree with your statement. ODO can't initialise the stack, because the games using DOS will stop working.
If Transball does not use DOS, should initialise the stack. Remember:

DI
IM 1
LD SP,#F380
[your awesome code here]

Smile

Anyway, ODO is able of run game forcing boot. You can hold [CTRL] key, while the game is loading, to force reset. And Transball, magically, works. Smile

Par ARTRAG

Enlighted (6933)

Portrait de ARTRAG

14-09-2016, 09:13

no bug here
Odo could advise users about forcing reboot after load (maybe it does it already)
Trasball could force the stack at F380h due to the fact it does not need dos

Par NYYRIKKI

Enlighted (6033)

Portrait de NYYRIKKI

14-09-2016, 10:25

Ramones wrote:

Hi NYYRIKKI. Sorry, I disagree with your statement. ODO can't initialise the stack, because the games using DOS will stop working.

This is very simple: ROM games can't ever expect disk system to be present. If they need disk routines, they need to exit and init them self later though hooks when disk system has been initialized. (like ie. Konami Game Master does)

In theory it is nice idea if cartridge checks that it has enough stack space, but usually game cartridges are placed in slot 1 and in case of error there is very little the cartridge can do (except displaying error or defining the whole operating environment again by clearing hooks etc.) -> I find this relatively useless check and I don't expect many cartridges do that. In perfect world all programs would consider all the possible tricks that users can imagine using all kind of external programs, memory managers and such, but turning it to responsibility of developer is a bit overkill as: 1) I think it is reasonable expectation for ROM developer to expect that the ROM is first thing MSX executes after boot & init. 2) it causes extra work, needs extra space and even then MSX does not have mechanisms to protect it self from serious user errors.

Par Ramones

Champion (264)

Portrait de Ramones

14-09-2016, 10:35

NYYRIKKI wrote:

This is very simple: ROM games can't ever expect disk system to be present. If they need disk routines, they need to exit and init them self later though hooks when disk system has been initialized. (like ie. Konami Game Master does)

Of course, I agree. For this reason ODO can't initialise the stack. It is the responsibility of the game... Cool

Page 14/20
7 | 8 | 9 | 10 | 11 | 12 | 13 | | 15 | 16 | 17 | 18 | 19