accelerating the 'DIR' command in msxdos.

Door Leo

Paragon (1236)

22-01-2003, 22:04

Has anyone ever tried to accelerate the 'DIR' command , it is so slow, what a pain !

I was thinking if it was possible to use the base register in the VDP that points on the

begining of the table that describes the screen texts to accelerate the scroll.

I guess even not using such a trick, it is possible to accelerate it because I suspect to be

programmed in way to be 'very compatible' but very slow ( many redirections , writing

characters one by one ..., maybe inherited from CPM os)

Is there a patch for command2/command.com, somewhere ?

I know it works like in PC with sub function 09h and a call 0005 or other adress, would

it be possible to hack the first 100bytes of command.com ?

Or any clue on how to redirects the function that prints out characters ?

Leo

Aangemeld of registreer om reacties te plaatsen

Van anonymous

incognito ergo sum (116)

23-01-2003, 01:17

On a turboR it's VERY fast, because it caches the directory. On a normal MSX2/2+ MSX-DOS (v1 or v2) must check the directory sector each time, because these computers do not have a Disk Change signal in the floppydrive.

And the R800 speed improves greatly the speed of the display. Sometimes so fast that I cannot press CTRL-S (for pause) fast enough ^^;

Also modifying you MSX2/2+ with a 7MHz print improves greatly. Ofcourse this also means that the Z80 code of the DIR command is not very optimized. I wouldn't be surprised if it used the BDOS character-print.

Somebody could write a FDIR (Fast DIR) COM or TSR, although maybe someone already has...

Van Grauw

Ascended (10558)

23-01-2003, 02:34

I have done it. It didn't support forwarding et al, but it certainly mattered *a lot*, it was cool to see the awesome speed increase . Ofcourse the way I did it was a huge hack, so definately not fit for release. However DOS3, on which I am working (well not right now, but it's a project of mine ), will feature decent display routines.

By the way, the speed being unbearable on 3.5MHz, on 7MHz (which I use) it is indeed generally just acceptable. The disk access is definately not the limiting factor, the reason for it is that the BDOS changes the stack and does an interslot call for *every* character output to the screen. In DOS2, a string output is *exactly* the same as a loop outputting seperate characters to the console (string output isn't even implemented in the kernel!). In addition to that it also does other stuff which could also be optimized.

I doubt it is command.com which is not optimized. Optimizing the whole thing by patching it is not exactly easy, the best way would probably be by extending MSXDOS2.SYS, however you would need to write a fully functional character display routine using the current BIOS system variables, which is actually not *really* hard, but the tough thing is to implement DOS2 functionality, and implementing the redirection stuff for example. In other words, it is quite a hard job, and actually has to be done on DOS2 kernel level.

In DOS3 I will use buffers in RAM from which I update (I need them anyway since it's multitasking so there will be more than 1 console at the same time), and on the MSX2+ it will use VDP command for scrolling in screen 0. For string outputs I will only set the VRAM position once and output all characters to the console subsequently. Also I will make a more direct, faster interface between the several parts of the OS (without requiring interslot calls for every character hehehe), and lots, lots of block-level functions.

~Grauw