Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Back to the future: FLAC 1.4.2 for MS-DOS (Read 6336 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Back to the future: FLAC 1.4.2 for MS-DOS

Reply #25
Just for reference, Intel introduced it's Pentium before I walked this earth, so I'm not totally sure on the details.

[...] 32-bit DOS extenders to extend memory addressing AND arithmetic to 32-bit.
Well, thanks for making me feel old. A DOS extender is only necessary for 32-bit addressing; it's possible to do 32-bit arithmetic without one.
Are you sure? That doesn't seem to make sense: how would an application access a 32-bit register to do arithmetic on from a 16-bit OS? 32-bit arithmetic can be emulated that way, but that is very slow. Here's something written on the subject, I don't know how reliable that is: http://wiki.freedos.org/wiki/index.php/DOS_Extender

Quote
When running 32-bit DOS applications using the DOS Extender, the CPU runs in Protected Mode (a special mode of 80386 and higher CPUs that allow use of advanced features including access of 4GB of memory, 32-bit registers, memory paging and protection, etc). This is different from Real Mode, which is the standard mode for 80286 and higher CPUs, and the only mode of 8086/8088 CPUs.
Music: sounds arranged such that they construct feelings.

Re: Back to the future: FLAC 1.4.2 for MS-DOS

Reply #26
Another question: decoding shouldn't need floating-point - but maybe it is non-trivial to do away with that?

Re: Back to the future: FLAC 1.4.2 for MS-DOS

Reply #27
libFLAC can be specifically compiled without needing floating-point math. This was done mostly to make porting to embedded architectures easier. In the decoding part of this library, there are only two uses of floating point in seeking, and these are replaced with (less accurate) fixed-point approximations when necessary.

However, the flac command line tool is not programmed like that, because those tools aren't really useful in embedded environments. It uses floating point calculations in a few places for convenience. For example, to calculate the completion percentage and the compression ratio. These are trivial to replace, but there is no alternative code currently.

So, an FPU is necessary with these compiles, but a soft FPU will probably not harm performance much on decoding.

edit: apparently building this with an FPU-emulator (only used when necessary) is rather easy. http://www.delorie.com/djgpp/v2faq/faq11_1.html
Music: sounds arranged such that they construct feelings.

Re: Back to the future: FLAC 1.4.2 for MS-DOS

Reply #28
Just did some tests on an Intel Pentium 200MHz with Windows 98. A label on the PC marked it as a P54C running on 200MHz, but according to Wikipedia it is actually a P54CS. It was introduced in June of 1996 and if memory serves me right, the computer originally came with Windows 95 instead of 98.

Results for Nine Inch Nails - HYPERPOWER! from the album Year Zero. The track has a playback length of 102 seconds and is CDDA (stereo, 44.1kHz, 16-bit PCM).

Decoding of file compressed with preset 0: 10 seconds (10x realtime)
Decoding of file compressed with preset 8: 13 seconds (8x realtime)
Re-encoding file with preset 0: 24 seconds (4x realtime)
Re-encoding file with preset 8: 197 seconds (0.5x realtime)

I've also taken a 24-bit file with a length of 10.000.000 samples. While it was 44.1kHz, I'll calculate realtime numbers as if it was 96kHz, as to emulate a 96/24 file. The file has a 'length' of 104 seconds then.

Decoding of file compressed with preset 0: 28 seconds (4x realtime)
Decoding of file compressed with preset 8: 43 seconds (2x realtime)
Re-encoding file with preset 0: 83 seconds (1.2x realtime)
Re-encoding file with preset 8: 600 seconds (0.2x realtime)

So, apparently, an old original Pentium clocked at 200MHz can decode high-res FLAC fine in realtime.
Music: sounds arranged such that they construct feelings.

Re: Back to the future: FLAC 1.4.2 for MS-DOS

Reply #29
Are you sure? That doesn't seem to make sense: how would an application access a 32-bit register to do arithmetic on from a 16-bit OS?
Yes, I'm sure. Applications can access 32-bit registers using the operand size override prefix (0x66). Assemblers that support i386 instructions will automatically add this prefix when writing code to access 32-bit registers from within a 16-bit OS. There's no way for an OS to prevent applications from using this prefix.

Here's something written on the subject, I don't know how reliable that is: http://wiki.freedos.org/wiki/index.php/DOS_Extender
It's not entirely accurate, but there aren't many applications that use 32-bit registers without also using 32-bit addressing. If you use 32-bit registers, your program requires a 32-bit CPU, so you might as well use 32-bit addressing too. (32-bit addressing is a lot more convenient than 16-bit addressing.)

Another question: decoding shouldn't need floating-point - but maybe it is non-trivial to do away with that?
At least the decoding speed indicator requires floating-point. I'm not sure if silencing it will avoid all of the floating-point code paths. There are also ways to tell the CPU to silently ignore floating-point instructions when a FPU isn't available, but then FLAC might misbehave when it sees gibberish results in its floating-point math.

Re: Back to the future: FLAC 1.4.2 for MS-DOS

Reply #30
Are you sure? That doesn't seem to make sense: how would an application access a 32-bit register to do arithmetic on from a 16-bit OS?
Yes, I'm sure. Applications can access 32-bit registers using the operand size override prefix (0x66). Assemblers that support i386 instructions will automatically add this prefix when writing code to access 32-bit registers from within a 16-bit OS. There's no way for an OS to prevent applications from using this prefix.
Interesting. It is rather clear the migration from 32-bit to 64-bit went very differently compared to the migration from 16-bit to 32-bit. No need for a new OS with the right kernel and an enormous amount of DLLs for both 64-bit and 32-bit environments (so called WoW64) just set the right prefix.  :))
Music: sounds arranged such that they construct feelings.

Re: Back to the future: FLAC 1.4.2 for MS-DOS

Reply #31
Interesting. It is rather clear the migration from 32-bit to 64-bit went very differently compared to the migration from 16-bit to 32-bit. No need for a new OS with the right kernel and an enormous amount of DLLs for both 64-bit and 32-bit environments (so called WoW64) just set the right prefix.  :))
You definitely needed a compatible OS to use 32-bit registers! DOS was compatible because it was single-tasking. You couldn't get away with that on something like 286 Xenix.

In retrospect, making 32-bit registers available in 16-bit mode was a very odd choice...