中国DOS联盟

Actually, my main point is this passage:

Originally posted by zyl910 at 2006-7-11 15:20:
And now it's calling an interrupt.
The time is mainly consumed in the interrupt service routine.
That is, the bottleneck at this time is the hard disk read/write speed.

Originally posted by asbai at 2006-7-11 20:46:
Specifically, languages that use mechanisms such as garbage collection and automatic memory management; untyped variables; reflection, etc., are inherently inefficient. Such languages won't run fast even if directly compiled into machine code. Interestingly, they may even run slower. There is an article in the IBM Knowledge Base specifically measuring the efficiency of Java in various situations: Weighing in on Java native compilation (http://www-128.ibm.com/developerworks/library/j-native.html).

Since those factors affect program efficiency, why not bypass them? There are various optimization techniques, which must be combined with platform and programming language characteristics to make the best use of advantages and avoid disadvantages.

The garbage collection mechanism does affect performance, but it also has benefits.
First, write a linked list program using those purely compiled programming languages without using STL and other data structure libraries.
Then write the same program using Java, .Net (of course, not using their class libraries, but new-ing linked list nodes one by one).
Now fill in a large number of node data and see.
You will be depressed to find that those purely compiled codes are actually not faster than the virtual machine.
This is because the memory allocation functions of general programming tools call the operating system's memory allocation functions, and the operating system's heap allocation functions are not originally designed for allocating a large number of small objects. So many classic data structure textbooks recommend us to write our own memory allocator, specifically for memory allocation of small objects like linked list nodes. That's why STL is now advocated.
And the garbage collection mechanism was originally designed to solve such problems and can handle the allocation of a large number of small objects like this.


Actually, I don't like Java, .Net either because they are specifically designed for web services, so many test results are deceptive. But precisely because of this, I once carefully analyzed their performance. The result is that for those fields that current programming beginners are exposed to, Java, .Net have been optimized to the extreme, and they seem to be really fast. But for traditional fields, they naturally can't compare.

Last edited by zyl910 on 2006-7-11 at 22:25 ]

In my impression, BASIC has both interpreted and compiled types. GWBASIC and QBASIC are interpreted, and QuickBASIC is compiled. But GWBASIC can save the source program in an encrypted form with the /P parameter when saving, that is, what is seen is no longer a text file. I wonder if the "P code" mentioned by "zyl910" refers to this. QBASIC doesn't seem to have this function. I think QuickBASIC should be compiled into an independent executable file, and it doesn't need the support of the QuickBASIC environment when running. Since I haven't used it, that's just my thought. The compiled type should be like this. Anyway, let's ask our "qb45" to talk about it. Hehe.

Re: gogo
I don't know where the UDMA driver you found is downloaded from. There is indeed a UDMA for DOS driver that can only be used on VIA chipset motherboards because it was developed by VIA, but it's already very old and can't be used on my 694X motherboard. The UDMA driver I'm currently using is indeed developed by Jack Ellis as said by "johnsonlam". And in its instructions it says

This is a set of four DOS UltraDMA hard-disk drivers. All the drivers run UltraDMA disk(s) on PC mainboards using a "South Bridge" controller chip from Intel, VIA, SiS, ALi and other vendors.

I'm using UDMA.SYS instead of UDMA2.SYS. Now, I tried the latest improved program you made again (before your post on floor 30), and found that it can completely get the correct content of the desired sector in my memory configuration environment! And there's no any perceived delay. The previous delay I thought was still related to the error in your program. But I only tested reading, not writing. Hehe.
By the way, for this type of small program, I think the execution speed has little to do with the CPU speed, the programming language used, and even the algorithm. Even if there is, it's not something people can feel.
In addition, I roughly and vaguely looked at your conversion for handling with CHS mode when Int13h ext is not supported. If I understand it correctly, your conversion is based on assuming that the number of sectors per track is 63 and the number of heads is 255. Strictly speaking, this is not rigorous. How can you be sure that the number of sectors per track of all hard disks is 63 and the number of heads is 255? At least the possibility of such parameters on old hard disks (<8.4G) and new hard disks (>137G) is almost zero. Even for hard disks within this range, it can only be said that most BIOSes have such HS parameters, because it's very possible that due to various reasons, the CHS parameters of the hard disk or its partition table recognized by the BIOS do not appear as the parameters recognized in LBA mode. At this time, if you still use the dead parameters of H=255 and S=63 for conversion, it's very possible that the sector read or written is not the desired sector.

TO DOSforever:

Regarding UDMA:
To get the same problem as you, I specially downloaded some DMA DOS drivers and tried WENGIER's UDMA. DYS. After loading, everything is normal, and there are no sector read errors as you mentioned.
Downloaded a UDMA2, which is said to be only for VIA.
I don't know which UDMA you are using?

Regarding sector conversion:
That's right, I just handled it with the parameters H=255, S=63. Of course, there may be incompatible situations, and I have also considered that..
In fact, the more complete way is, of course, to first obtain the hard disk parameters and then read and write according to this parameter.
However, the practicality of this H=255, S=63 is still very wide. Most old hard disks support it, and new hard disks also support it (because the controller of new hard disks can translate various reading and writing methods).
However, if the old hard disk is set to an incompatible H=255, S=63 mode, then there will be problems..
I'll improve it when I have time..

Regarding the problem solved by my improved program:
It has indeed been improved and updated several times (solved several bugs), but currently, I don't know which code change has solved your this problem..

Just now, I solved the bug that the basic INT13 error prompt was not displayed.. Very happy, I can display the error reason when installing a bad hard disk!..
Really want to try with your UDMA..
Isn't it WENGIER's UDMA. SYS?

Last edited by GOTOmsdos on 2006-7-12 at 01:52 ]

Reply to Brother zyl910:

Since those factors can affect program efficiency, why not bypass them. There are various optimization techniques, which must be combined with the characteristics of the platform and programming language to make the best use of advantages and avoid disadvantages.
■ Hehe, let you laugh, actually I just have a feeling. I remember that you said that if assembly doesn't use extended instructions like MMX and SSE, it has no advantage in efficiency compared with VC, and also gave an example of image processing using a completely different algorithm. At that time, I wanted to say that it was because your algorithm was extremely brilliant compared to the opponent, not a fair comparison between languages. ;)

Garbage collection mechanism does affect performance, but it also has its benefits.
First, write a linked list program with those purely compiled programming languages without using STL and other data structure libraries.
Then write the same program with Java, .Net (of course, not using their class libraries, but newing linked list nodes one by one).
Now fill in a large number of node data and see.
You will be depressed to find that those purely compiled codes are actually not as fast as the virtual machine.
This is because the memory allocation functions of general programming tools call the operating system's memory allocation function, and the operating system's heap allocation function is not originally designed for allocating a large number of small objects.
■ What compiler are you using? How can it have malloc and new without small heap?
■ There seem to be no pointers in .net. If you implement a linked list with it...

So many classic data structure textbooks will recommend us to write our own memory allocator, specifically to handle the memory allocation of small objects like linked list nodes. That's why STL is currently advocated.
■ All containers in STL use the standard operator new to allocate space. For list, it's calling once per object. There's no advantage over the code written by ourselves in this regard. There's only one exception, which is the pool allocation strategy in sgistl, but that strategy is just an alternative allocation strategy, not enabled by default, and is not C++ standard compliant.
■ STL is advocated because it provides an efficient, extensible, and standardized design framework for algorithm-oriented programming ideas (generic programming).
■ The main purpose of the classic textbooks recommending writing your own memory pool back then was not just the O(1)+ allocation efficiency, but more importantly the memory fragmentation problem. This problem has been solved in all systems using paged memory management. And there are small heaps in the standard libraries of all modern compilers. :)

And the garbage collection mechanism was originally designed to solve such problems and can handle the allocation of a large number of small objects like this.
■ The garbage collection algorithm of interpreted languages is accompanied by large-scale memory scanning. Are you talking about pre-allocation and small heap?
■ The efficiency of garbage collection is so low, and its memory overhead is so high. In C, even if each memory allocation directly applies for memory from the operating system without the help of small heap, its efficiency should be better than garbage collection. Of course, there are two issues to consider here:

■1. How long the program runs: Garbage collection is a polling mechanism. Garbage collection will start in 2 situations:
1. Memory is exhausted - scan the entire memory segment to release unused storage.
2. The polling interval expires - scan all used memory segments to release unused storage.
Because it is accompanied by a large number of scans, the efficiency of garbage collection is quite low. However, for an application that doesn't run for a long time and has a small memory overhead, because the above two points are not met, the inefficiency is not noticeable.

■2. The operating system in use: For systems like DOS that have poor memory management, when allocating a large number of small amounts of memory without the help of small heap, it may indeed be relatively slow. But now there are very few standard libraries without small heap, and the paged memory management mechanism of modern operating systems is much more efficient for such situations.

Actually, I don't like Java, .Net either, because they are specially designed for Web services, so many test results are deceptive. But it's because of this that I once carefully analyzed their performance. The result is that for the fields that those beginner programmers are exposed to, Java, .Net have been optimized to the extreme, and they seem to be really fast. But for traditional fields, they can't compare, of course.
■ Hehe, I think that for beginners, the main mistakes all occur in algorithms and program logic. :)

■ Almost forgot an important note: Actually, I like java and basic very much, and have a special affection for basic (most people start learning programming with basic). There's no intention to belittle any language here. Each language is born to solve different problems (but I'm quite disgusted with .net, heh heh). Here I just want to say that in a fair comparison, it's improper to say that the running efficiency of basic, java can reach the level comparable to C/C++.

Of course, from another perspective, comparing only efficiency is also unfair. Time and space efficiency are not the strong points of these languages. Ease of use, fast construction, strong portability, rich function/control libraries, etc. are their strong points.

Last edited by asbai on 2006-7-12 at 07:56 ]

BASIC can be either interpreted or compiled. GWBASIC and QBASIC are interpreted, while QuickBASIC is compiled. I'm using QuickBASIC 4.5, so I chose the online name qb45. I'm just an enthusiast. When I chose the language, I was also hesitant. Since I have a job and only do programming as a hobby, I didn't want to make it a career, so I chose the simplest QB.

Netizen zyl910 is very right. It does compile to P-code.

For a user, there can be said to be no obstacles. From the user's perspective, QB can compile into an independently running EXE file or a program that requires the QB library to run. The Quick series of BASIC supports interrupt calls and embedded machine code, which is sufficient for an amateur enthusiast like me.

I find that the programming language is not the main limitation. A deep understanding of computer principles, hardware, and the file system is what enables making some low-level application software.

I hope everyone can take a look at my photos and resume. Thanks everyone.
http://www.programfan.com/club/showbbs.asp?id=82092

Thanks to GOTOmsdos for the great stuff!!!

Last edited by wang6610 on 2006-7-12 at 20:46 ]

Originally posted by qb45 at 2006-7-12 08:38 AM:
BASIC has both interpreted and compiled versions. GWBASIC and QBASIC are interpreted, while QuickBASIC is compiled. The version I use is QuickBASIC 4.5, so I gave myself the online nickname qb45, er..

It's better not to promote your that page. It's beneficial to both yourself and others.

I completely agree with the view of the person above. Regarding the matter of "wheels", stay away as far as possible. Why bother? It doesn't matter to yourself, but it also affects family members. And I haven't heard that Hong Zhanhui is related to this!

The program has been updated significantly.

Please refer to the supplement in the main post for the updated content.

Last edited by GOTOmsdos on 2006-7-13 at 00:05 ]

The program has been updated, and it is estimated that it can be compatible with old hard drives! It has also added the function of reading and writing "non-1.44mb" floppy disks. The instructions are in the main post...

Last edited by GOTOmsdos on 2006-7-13 at 18:48 ]

Although it has been updated to be able to read and write old hard drives and old floppy disks (non-1.44MB format), but I don't have these antiques myself, so I can't test. If anyone has the opportunity to come across them, you can give it a try and see how it runs. If everything is normal, that's of course good. If there are problems, post the errors so that they can be solved.

I just discovered that my this program can be used as a mini version of GHOST and HD-COPY.
The reason it's called a mini version is because:
For GHOST:
This program has no file compression function (or volume splitting function), so it can only handle files within 4GB at most (that is to say, if the partition you want to handle is within 4GB, you can try this program. Of course, you must know its start sector position and total number of sectors. Also, if it's FAT16, it can only handle within 2GB)
For HD-COPY:
HD-COPY has many other functions, while this program only has the read-write main function.

Last edited by GOTOmsdos on 2006-7-17 at 17:05 ]

Haha, in the future, using this thing I wrote will solve the problem of extracting images or making images! So cool!

Just cleared all the commented-out code just now, sorted out the code, added comments, and aligned it using VC's alignment function. It looks cleaner. Updated.

I found a bug in this program when getting parameters of old hard drives. This bug caused failures in reading and writing old hard drives.

It has been corrected.

Original bug as follows:
cylinder=regs.h.ch+1; /* The CH +1 in the register is the number of cylinders. It should be that the high 2 bits of CL are the high 2 bits, and the 8 bits of CH are the low 8 bits */
sector=regs.h.cl; /* The CL in the register is the number of sectors per track. It should be the low 6 bits of CL */

Changed to:
cylinder=((((unsigned int)regs.h.cl)>>6<<8) | regs.h.ch) + 1;
sector=regs.h.cl & 0x3F;

When taking values, instead of using pointers or even general operations, efficient and fun bit operations are used.

Now reading and writing old hard drives can work. If you have an old hard drive, you can try it out. I don't have one myself yet.

Last edited by GOTOmsdos on 2006-7-20 at 20:52 ]

Remove

Last edited by GOTOmsdos on 2006-7-22 at 14:58 ]