Nextor: the whole story

Page 3/6
1 | 2 | | 4 | 5 | 6

Par msd

Paragon (1375)

Portrait de msd

05-08-2011, 00:37

and that can use the bigger mapper on the machine

You mean on turbo r and panasonic 2+ it doesn't select external mapper, but always internal as primary?

Par SLotman

Paragon (1215)

Portrait de SLotman

05-08-2011, 02:41

Yeah. Very annoying to have a 4Mb external mapper, and have to use DOS1/MemTr to get some games to work on it Tongue

Par sd_snatcher

Prophet (3131)

Portrait de sd_snatcher

05-08-2011, 15:18

@SLotMan

But what games use more than 512KB of memory-mapper?

And this means those games are clearly bugged, as they assume that there can be only a single mapper on the system.

Par sd_snatcher

Prophet (3131)

Portrait de sd_snatcher

05-08-2011, 15:46

@SLotMan

Also, there's a detail on the Turbo-R achitecture maybe you don't know: There a HUGE speed penalty for acessing the external slots (external memory-mappers included, off course). By HUGE I mean that the R800 is slowed down to a performance a little better than a Z80B/5.37MHz (and slower than a Z80C/7.14MHz).

This means that if you chose that the bigger memory-mapper will always be selected, simply connecting an external memory-mapper on your Turbo-R will mean that it will be slowed down without choice. With the current behaviour, at least you have the option to select the slower mapper only when you need it.

Par SLotman

Paragon (1215)

Portrait de SLotman

05-08-2011, 18:55

@sd_snatcher: I know about all that - but even then - for example, to run Metal Gear 2 on my ST with internal 256kb, is very problematic! No way to run it from IDE, ROMLoad doesn't load anything bigger than 256kb, my MegaRAM is only 256k also (so I can't use ExecROM) - the only solution is to boot from disk on DOS1, run the "memTr" program, go to basic, insert the MG2 disk, then do a call system!

The bigger memory mapper will slow down the tR - but only if it is connected Wink
Much less hassle than the 'procedure' to run Metal Gear...

Par PAC

Guardian (5396)

Portrait de PAC

05-08-2011, 20:00


And why I started my own project, you may ask? Because in three years I haven't received a project plan, a roadmap, a work schedule... NOTHING. I don't even know what were the planned features for MSX-DOS 2.50. I think that the project is pretty much dead. Anyway, the only modifications the sources I received had relative to version 2.31 were the FAT16 support (and apparently incomplete, I had to modify a couple of things to make it work) and some small optimizations scattered through all the source files.

Time ago I heard something related with a new MSX-DOS2 and Tsujikawa was involved, maybe we should ask him what happened and if he is plotting something new now. Tongue

Par sd_snatcher

Prophet (3131)

Portrait de sd_snatcher

05-08-2011, 20:27

@SLotMan

No offense intented, but...

1) Man!!! Why haven't you expanded your ST to (at least) 512KB yet?!? 256KB is too little memory for a Turbo-R. Bring it to Jau on the end of the year, and someone can easily expand it to you. You just need to buy two 44256 DRAMs. If you don't have those, I have some and can sell to you on Jau if you wish.

2) It's also possible to expand your MegaRAM to 512KB. What brand are yours? Most DDX's are very easy to expand, while CIEL ones require a more deep surgery. You'll need another pair of 44256 DRAMs and a 74LS670 chip, which I can also sell to you if you don't have any.

Par Ivan

Ascended (9139)

Portrait de Ivan

05-08-2011, 22:18

@konamiman: amazing story!

Par sd_snatcher

Prophet (3131)

Portrait de sd_snatcher

10-08-2011, 04:25

@KonamiMan

Those are some features/enhancements I would like to request:

- Maximize the available the TPA memory, by moving error messages and other not frequently used data to the memory mapper pages. Only the data indispensable for the program interface should remain on the lowest 4 mapper pages.
- Support for more than 8 drive letters. AFAICR, the CP/M supported at least 16 drives.
- Support for Network drives, without direct access to the filesystem (could be network shares, or i.e. Nowind without diskimages)

Par konamiman

Paragon (1050)

Portrait de konamiman

10-08-2011, 08:35

Maximize the available the TPA memory[/url], by moving error messages and other not frequently used data to the memory mapper pages.
Error messages are not in TPA, they are in a ROM bank in the kernel. TPA contains only MSXDOS.SYS and work area buffers and variables (most of which can't be moved for compatibility reasons).

EDIT: I see that there are indeed some messages in MSXDOS.SYS. But these are just the "Abort, retry, ignore", "Press any key to continue" and a couple more.

Support for more than 8 drive letters. AFAICR, the CP/M supported at least 16 drives.
I did some experiments with this, but the problem is that old kernels (including those associated to FDD drives inside the computer) assume a maximum of 8 supported drives and will not work if 8 drives or more have been already allocated when their initialization code is invoked. However the FAT16 support should imply that you do not need so many drives as before, and when using device-based drivers you have complete freedom fot assigning drives to devices however you want.

Support for Network drives, without direct access to the filesystem
This will be possible when I implement the RAM loadable drivers and the filesystem drivers features. But please be patient as these are not trivial to implement, especially the second one.

Page 3/6
1 | 2 | | 4 | 5 | 6