Challenge: Increasing TPA memory on MSX-DOS2 & Nextor

Page 1/2
| 2

By sd_snatcher

Prophet (3473)

sd_snatcher's picture

13-07-2011, 00:35

Here's some challenge to the MSX-DOS (CMD-2.44 & Nextor included) hackers:

Try to release more free user-memory by moving as much as possible parts of the MSX-DOS2 to higher memory-mapper pages, even if this raise the requirements to 256KB of RAM, like Nextor DOS already requires.

I'm asking this because I'm releasing many HDD version of MSX games, and I always stomp on the same problem: the MSX-DOS2 leaves too little memory free on the base CP/M user memory, or leave some structures at too low addresses.

I released RunDOS1 as a quick hack to workaround for this problem, and it does quite a good job, but:

1) It's cumbersome to ask the user to use a second tool to do the job. And the loaded MSX-DOS1 has a lot of limitations, like missing subdirs. It's not possible to quit it without a reset too.
2) RunDOS don't raise the BDOS-F37Dh, and this causes problems on many games

I did some comparisons on the addresses of each one uses, and those were the results:

                CPMTBL0000h	BDOS0005h	BDOSF37Dh
- MSX-DOS1.03 = DC03h		D606h		F331h		(s/ CTRL)
- MSX-DOS1.03 = E203h		DC06h		F331h		(c/ CTRL)
- MSX-DOS2.20 = DE03h		D606h		EB0Fh
- MSX-DOS2.31 = DD03h		D506h		EAE1h
- MSX-DOS2.41 = DD03h		D706h		EB0Fh	(kernel v2.20)
- MSX-DOS2.41 =	DD03h		D706h		EAE1h	(kernel v2.31)
- MSX-DOS2.44 =	DD03h		D706h		EAE1h	(kernel v2.31)
- RUNDOS1     = E603h		E006h		EB0Fh   (kernel v2.20)
- RUNDOS1     = E603h		E006h		EAE1h   (kernel v2.31)
- Nextor2.0a1 = DE03h		D906h		EABBh

The clear winners up to now are unfortunately the oldest fellas: Both MSX-DOS1.03+CTRL and RUNDOS1.

The challenge would be to push those addresses at least as high as the MSX-DOS1.03+CTRL has. This would eliminate a lot of compatibility problems and instead of putting workarounds on a lot HDD ports (saving the important parts to the VRAM and restoring on disk-I/O, i.e.), it would just be a case of recommend the use of a newer version of MSX-DOS2 & Nextor.

Login or register to post comments

By msd

Paragon (1461)

msd's picture

13-07-2011, 11:05

Which version of msxdos2.sys did you use. Msxdos2.sys version 2.31 uses 256 bytes more than v2.20. You don't need to use that version in combination with command 2.40

By sd_snatcher

Prophet (3473)

sd_snatcher's picture

13-07-2011, 14:22

@msd

Thanks for the tip! I'll test it, but probably it will not be enough: The TPA will end at D806h and the F37Dh jump will still point to EAE1h. Both are still much lower than the MSX-DOS1.03+CTRL.

By MicroTech

Champion (385)

MicroTech's picture

14-07-2011, 10:33

Maybe just a nonsense... but if you are able to "switch" from DOS2 to DOS1 with RunDOS1 then couldn't you also switch back?
You could reserve a mapper segment to be used in page3 for DOS2 and another for DOS1, and use a .com executable to switch between the 2 configurations... probably Im' just deliring Tongue or I didn't understand what you really need Eek!

Did you reverse engineereed MSXDOS2.SYS?

By sd_snatcher

Prophet (3473)

sd_snatcher's picture

14-07-2011, 14:47

@MicroTech

RunDOS1 was a quick hack to workaround the problem. It doesn't worth investing too much.

I didn't reverse engineered the MSXDOS2.SYS, as I already have too many projects going on. Smile

By sd_snatcher

Prophet (3473)

sd_snatcher's picture

14-07-2011, 15:00

I had a quick look into the space used by MSX-DOS2.SYS on the lower 64KB. It seems that there are a lot of strings that could be moved to higher mapper pages without breaking compatibility. Those strings are error messages, the text output by the VER command etc. It's nothing that would impact normal processing speed.

By MicroTech

Champion (385)

MicroTech's picture

14-07-2011, 17:47


I didn't reverse engineered the MSXDOS2.SYS, as I already have too many projects going on. Smile

Too little time to pursue all these interesting stuffs... Crazy


I had a quick look into the space used by MSX-DOS2.SYS on the lower 64KB. It seems that there are a lot of strings that could be moved to higher mapper pages without breaking compatibility. Those strings are error messages, the text output by the VER command etc. It's nothing that would impact normal processing speed.

Moving strings in another segment requires also modifying code that references it.
... maybe you should first feed MSXDOS2.SYS to IDA Disassembler... Wink

By konamiman

Paragon (1143)

konamiman's picture

15-07-2011, 12:17

With Nextor running in MSX-DOS 1 mode you will have even less free memory than with a real MSX-DOS 1. That's because Nextor keeps a table on page 3 with information about the drive to device and partition mapping for all the drives assigned to device-based drivers (in normal mode this information is stored in the code segment). Anyway it is just 8 bytes per drive plus one byte with the table size, so at most 65 bytes.

By sd_snatcher

Prophet (3473)

sd_snatcher's picture

15-07-2011, 15:16

konamiman! Big smile

1st, thank you so much for creating Nextor! It's a great initiative for the MSX system and, being non-MS/ASCII code, I believe it will an espetacular piece to complete the efforts being done by the C-BIOS team. It means that they will not need to develop a diskBIOS anymore, since yours is already alive and kicking.

That said, I think you can reduce Nextor's memory consumption by moving all the text strings from RAM to the ROM. This will free more than 200 bytes of memory, which will more than compensate the 65 bytes used by the extra tables. In your case you can move them to the ROM to avoid using extra mapper RAM.

IMHO, there will be no major disadvantage of doing this, because:

1) Those strings are rarely printed. The performance impact will be minimal
2) The Nextor ROM will be used only on new devices. This means they will have flash instead of EPROM and the text of the strings can be updated if needed.

By sd_snatcher

Prophet (3473)

sd_snatcher's picture

15-07-2011, 20:46

@konamiman

From the Nextor documentation:


The Nextor version of MSX-DOS 1 does not provide any additional functionality to users or developers relative to the original version, however it has been modified internally so that it can access devices attached to Nextor drivers.

1) Please take a look at Adriano's Fast!DiskROM for enhancements on the MSX-DOS1 kernel. He did an awesome work on this ROM, and improved a lot of the DOS1 kernel. The free space on basic is 25KB, regardless of how many drives are being used.
2) Have you developed a MSX-DOS1 compatible kernel from scratch also? Or is it the standard MSX-DOS1 kernel that is embedded there?

By sd_snatcher

Prophet (3473)

sd_snatcher's picture

16-07-2011, 00:26

I updated the table with more testing results:


                CPMTBL0000h	BDOS0005h	BDOSF37Dh
- MSX-DOS1.03 = DC03h		D606h		F331h	(w/o CTRL)
- MSX-DOS1.03 = E203h		DC06h		F331h	(w/  CTRL)
- MSX-DOS2.20 = DE03h		D606h		EB0Fh   (all v2.20)
- MSX-DOS2.31 = DD03h		D506h		EAE1h   (all v2.31)
- MSX-DOS2.41 = DD03h		D706h		EB0Fh	(krnl v2.20, sys v2.20)
- MSX-DOS2.41 =	DD03h		D706h		EAE1h	(krnl v2.31, sys v2.31)
- MSX-DOS2.44 =	DE03h		D806h		EAE1h	(krnl v2.31, sys v2.20)
- MSX-DOS2.44 =	DD03h		D706h		EAE1h	(krnl v2.31, sys v2.31)
- RUNDOS1     = E603h		E006h		EB0Fh   (krnl v2.20)
- RUNDOS1     = E603h		E006h		EAE1h   (krnl v2.31)
- Nextor2.0a1 = DE03h		D906h		EABBh   (DOS2 mode)
- Nextor2.0a1 = DC03h		D606h		F331h   (DOS1 mode w/o CTRL)
- Nextor2.0a1 = E203h		DC06h		F331h   (DOS1 mode w/ CTRL)
- Fast!DiskROM= E403h		DE06h		F331h	(MSX-DOS v1.03)

Page 1/2
| 2