Wrong version of command

Ascended (8233)

01-10-2009, 04:19

This is what I get every once in a while from my dearest DOS2. First off, some data:

Hardware:
MSX turboR FS-A1ST/256kB
- Moonsound in slot 1
- Gouda V5 slot expander in MSX slot 2
\-- Nothing in slot 2-0 (this one is broken)
\-- ATA-IDE in slot 2-1
\-- 1024kB memory mapper in slot 2-2
\-- Nemesis2 in slot 2-3

Software:
MSX-DOS kernel version 2.30
MSXDOS2.SYS version 2.30
COMMAND2.com version 2.41
%SHELL% = A:\COMMAND2.COM
%EXPERT% = ON

The problem occurs when I run some program, terminate it and return to DOS. For example MultiMente works just fine. Compass works just fine (in combination with switching from/to NestorBASIC, this goes totally wrong, but that's got something to do with poor memory management from either NBASIC or Compass). AGE works just fine.

But when I e.g. use MicroMusic, I use this batch file:

MEMMAN _SYSTEM@TL MMUSICSH@

I can then invoke the MMusic TSR by pressing SHIFT+SELECT, do some stuff, and then ESC to leave. Then, the aforementioned problem occurs:

*** Wrong version of command
Insert COMMAND2.COM disk in drive A:
Press any key to continue

What's happening here? What can I do about it? I've googled around and found solutions involving FIXDISK and FIXBOOT, neither helps. FIXDISK doesn't even work on harddisks. Much obliged

Entrar ou registrar-se para comentar

Por RetroTechie

Paragon (1563)

02-10-2009, 01:55

If I'm not mistaken, it works something like this: when a program is run under MSX-DOS, the COMMAND(2).COM occupies a memory area that is also available to the program that is run. Some programs may not touch that memory, exit and poof... back at the command prompt. But sometimes a program may use (=overwrite) that memory, and then MSX-DOS will try / must reload COMMAND(2).COM. From your post I read that the MMusic TSR does this. How MSX-DOS knows that in-memory COMMAND(2).COM was overwritten? System variable? Checksum on memory area? Dunno...

Anyway: you don't normally get told, but the message "Insert COMMAND2.COM disk in drive A:" tells you that this has just occurred, a -failed- attempt was made to re-load COMMAND(2).COM, and you're asked to supply it on a disk in drive A: to try again. The "*** Wrong version of command" message probably means that a COMMAND(2).COM was found (and loaded), but was a different version than what was loaded before. Why this is a problem? Again: dunno... perhaps another version might use different data structures for some things etc., and (for example) corrupt data when versions are changed between running .COM files. For a Disk Operating System, data corruption = file corruption (very bad).

In short: check the SHELL and perhaps PATH environment variables, see what copies of COMMAND2.COM they might lead to, and what versions those files are. In particular: are those file(s) all the same? If not, you might want to copy over / delete some of those file(s), or set those environment variables correctly (eg. in REBOOT.BAT). Where a correct setting would be: on re-load, first found COMMAND2.COM file = same version / file as the COMMAND2.COM that was loaded when booting MSX-DOS(2).

Note that changing disks might cause the same problem - for example if you boot from a floppy, change disks (also containing another COMMAND2.COM), and run a .COM file on it.

Por [D-Tail]

Ascended (8233)

03-10-2009, 01:37

RetroTechie, thanks for the elaborate answer! Not being a complete noob myself at all, I figured just about the same as you. That's why I put the %SHELL% variable in my starter post. %PATH% in my case always starts with "A:\", the end could possibly differ at times. So unless I'm really overlooking something, it should work just fine. By the way, I checked all %PATH% instances to see if there was any COMMAND2.COM to be found. Result: only on the root of drive A:. I'll try to force some stuff in the REBOOT.BAT and see if that works out. In any case, I recall not having this kind of problem with MSXDOS 2.20 (that is, the version of the SYS and COM files). But it could very well be that this problem is version independent. And I'm too lazy to check if #2.20 does the trick. I'm too fond of #2.41

By the way, I also have a problem running Bombaman from harddisk. I get the message "TPA size too small", of which I heard had something to do with my COMMAND2.COM version. #2.20 would be the solution as #2.41 requires more memory, but I simply refuse to downgrade. Is there any other solution?

Por RetroTechie

Paragon (1563)

03-10-2009, 02:10

Well perhaps starting with [CTRL] pressed (I don't think that helps much under DOS2), or perhaps even with [SHIFT] to disable floppy drive(s), in case the ATA-IDE doesn't also disable itself then...

Btw: are you loading everything from A: (harddisk, I assume) ? First boot from same drive? Do you change default drive at any point, eg. when running that MEMMAN batch file?

TPA = Transient Program Area. This is the free RAM (from the ordinary Z80's 64K) that MSX-DOS uses to load .COM files in (and remainder used by those .COM files to do stuff)

Por OeiOeiVogeltje

Paragon (1309)

03-10-2009, 10:58

hmm
bombaman runs fine from CF here
also command 2.41
no SHELL stuff in my autoexec.bat though (if that makes a difference)

Por Arjan

Paladin (714)

03-10-2009, 13:19

Oh yeah, the dreaded "TPA size too small"... heard you moaning about that before

Bombaman uses the memory area $0100-$d400 (+4 additional 16k pages). If the stackpointer is below $d400 you'll get that message and Bombaman quits.

With kernel version 2.20, msxdos2.sys version 2.20 and command version 2.41 the game would run just fine, if I just had more than 128k memory In my config the TPA is 54790 bytes (you can check it with the MEMORY command), which means programs can use the area $0100-$d706. I don't know if there are any tricks to increase the TPA size.

Por [D-Tail]

Ascended (8233)

03-10-2009, 14:02

I load everything from hard disk yes. You may have found that other topic that I started just before this one, bottom line: for some reason, my hard disk started to work again. Maybe it was dust in the motor or something.

Anyhow, back to the MEMMAN/COMMAND2 subject: the problem seems to be the combination of COMMAND2 [2.41] and MEMMAN. Using COMMAND 2.20 or #2.32 (stupid HPN version) the thing just works. Maybe it's got something to do with environment variables: %_CWD% is in my prompt, and when COMMAND 2.41 tries to display that, it breaks down. About the TPA size: I'll find out

Por [D-Tail]

Ascended (8233)

03-10-2009, 14:03

Hmm, and I meant to post this message 12 hours ago. Forgot to hit the 'submit' button I guess

Por [D-Tail]

Ascended (8233)

03-10-2009, 14:05

Then my next question: what exactly is different in MSXDOS.SYS 2.30 (#2.31, #2.32) as opposed to MSXDOS.SYS 2.20, apart from the version number?

Por [D-Tail]

Ascended (8233)

03-10-2009, 14:18

Hmm, weird... Just tried Bombaman again with Kernel/SYS 2.30 and COM 2.41, and no message about the TPA size being too small... This is really weird.

Por konamiman

Paragon (1044)

19-02-2010, 14:49

This problem is generic to all TSR programs that install themselves (or part of) in page 3. To do that, a jump to BASIC and a return to DOS (via siumlated CALL SYSTEM) must be performed. The problem is that for some reason, the SHELL variable is set to the name of the program that performed the CALL SYSTEM. Manually reverting it back to COMMAND2.COM makes the error disappear.

So there must be a way to avoid the SHELL item to be changed, maybe by reading it at program start and restoring it after the CALL SYSTEM.