Maybe he's talking about an Athlon(64) X2 6000+? If that's the case it's not competitive with any i3 I've ever heard of and wouldn't even make my Lynnfield i5 750 sweat, never mind an Ivy Bridge. But it should manage 1080p video OK... Maybe a player upgrade is needed.
With respect, I think you're misremembering things. Doom I can almost believe, but busy scenes would still give it an occasional hiccup. Duke might have given playable framerates if you used its abominably ugly "low detail" mode in 320x200. But Quake was very unforgiving - you'd be lucky to manage 512x384 on a then-scalding Pentium Pro 150 with a decent video card. The included TECHINFO.TXT file warned that id Software wouldn't accept bug reports about slow performance on 486 chips. It just wasn't designed for them.
Um, wouldn't it make more sense to run an ARM port of MAME? I'm not sure anyone's still maintaining an MS-DOS port of MAME, and even if they were a low-end 486 wouldn't handle arcade games that were contemporary around the time of its heyday.
Seconding this - on less than a 50 MHz 486 with VLB video Duke Nukem 3D chugged badly. It ran pretty effortlessly on a friend's 133 MHz 486, as I recall, and on my Pentium 90 it was bearable at 640x480 when I used the SciTech Display Doctor.
Yeesh. That's almost as heartbreaking as finding an ancient box I'd built for college two years ago, booting it up, installing Slackware, and discovering that no one ever bothered to fix the driver for its Rendition Verite 2200 to support 2D acceleration. At this point I wouldn't hold my breath for a fix; I'd just switch to Xfce and swear oaths of vengeance. It's probably more productive than waiting for this to get fixed on either side of the driver support pool.
Only five years of support is shitty, no question. Out of curiosity, what are the GeforceFX and Geforce 6 cards doing wrong in Gnome 3? The Geforce6 cards were just bumped to legacy support last month, but the FXes have been in limbo for a lot longer... and Nvidia's failure to ever release a driver better than beta quality for NT 6 was pretty fucking irritating.
In my experience, DOSbox or DOSEMU with FreeDOS utilities and userland apps. A VM running FreeDOS will run pretty poorly in a 64-bit OS due to all the trapping and translation of 16-bit code, and DOS hasn't been a major target of optimizations for most virtualization solutions. If you're just planning to play video games, it would be foolish not to try DOSbox first.
I do use Linux, but before DOSbox was good I wanted to learn how to make the best DOS-running computer possible. If that knowledge can be extended to help someone's quixotic, borderline insane hobby project, well, why shouldn't I help him? Just because I have better things to do doesn't mean that he does.:)
You'll run into those file size limitations pretty fast in certain edge cases - some scientific computing applications can generate gigantic files, to say nothing of video editing. But in this case FAT32 would mostly be useful for creating a large partition for your DOS/Win16 userland - you'd be surprised how fast a 2 gig partition can be eaten by a few application installs and regular use, even if you're using it as though it were still 1996.
In those days you tended to know how your filesystem was laid out exceedingly well. As X0563511 points out, directories helped an awful lot. And if things were just too damned confusing, you could always write up a text file with some explanation of the naming scheme and put that into the directory.
Just realized I forgot to talk about Windows 3.1. Everything I ran seemed to work just fine, from Microsoft Office 3.0 to fussy old crap like SimLife and the Doom editing utilities DeuTex and DeuSF. I don't guarantee a problem-free experience, but in my aimless nostalgic fiddling I never ran into anything problematic, let alone the scowling ASCII art face of Bill Gates telling you that he's sent a team of men to force feed you a live chicken for desecrating his sacred Windows with an inferior DOS.
I have! There's at least one pre-rolled floppy image floating around on various boot floppy sites, usually called something like "MS-DOS 7.10" and based on a Win9x boot floppy. I recommend burning a boot CD floppy emulation mode with that image and a suite of DOS utilities and the aforementioned \Windows\COMMAND direcotry contents, sys c: to install to the MBR, copy files over (including pre-configured autoexec.bat and config.sys files), reboot, and you'd be able to get started. I keep harping on \Windows\COMMAND because if you try to use files from, say, MS-DOS 6.2, COMMAND.COM will bitch about them being from the "Incorrect MS-DOS version." Keeping things consistent will help you get a basic install going. Then you can worry about copying in FreeDOS files and tricking it out. This all worked very well for the dedicated DOS box I ran for several years on a thrown away Pentium II.
You say he won't "do pro-level editing on a cell phone," but he said he was using a tablet, and I'll remind you that "pro-level editing" from the time that Windows 3.1 was relevant also didn't generally use files that ran into the hundreds of megs either. I'm just disclosing limitations he might run into in the realm of not-quite-ordinary tinkering. It's worth noting that if he's doing it all in DOSbox in the first place, then this doesn't really matter so much; but if it's QEMU...
Well, sort of. You can hex-edit the COMMAND.COM from a Windows 95B or higher boot floppy, replace the "Windows 95(c)" or whatever tag's in there with "MS-DOS 7.xx," partition and format C:\, do a quick install to the hard drive's boot record from the floppy, copy over files from the old C:\Windows\COMMAND directory into C:\DOS, roll your own autoexec.bat and config.sys with proper path setting, reboot, and have a functional DOS install with FAT32 support. Then Windows 3.1 can run on top of it and take advantage of some of the functionality, but applications within Win3.1 may still try to warn you away from long filenames just because they were an unknown quantity at the time of development. Finding a functional defragmenter may also be tricky. At that point you could have a very large FAT32 volume, but above a certain size threshold your cluster size would balloon to 16KB or so, and you'd still be hobbled by the ~4GB filesize limit... to say nothing of memory addressing issues, or the large size of the COMMAND.COM in conventional memory.
Some, or all, of these things could be circumvented by using FreeDOS, but I haven't really tried that. YMMV.
Thank you, that's wonderfully informative. Using 4K for effects work makes sense - going back in time, it's analogous to using 70mm film for optical effects while using 35mm for your main filming. Wow.
...and dramatically higher encoding playback requirements unless you've got a new, dedicated piece of hardware to handle most of the computational overhead. Or sufficient patience... Believe me, I'm happy to see H.265, but it's going to be deployed at a trickle rather than a dramatic gush. There will be a lot of growing pains and deployment will be slow.
Yep - even if the set-top box customers are given is natively MPEG-4 AVC, the backend is frequently still MPEG-2 passed through a realtime transcoder. 4K resolution is going to be a big deal for theaters and exhibition halls of various stripes. At the smaller scale tech isn't ready for home yet by a long shot - AVC's successor HEVC is still in the drafting stages, never mind successful deployment - and the improvements won't have the impact that the DVD --> Blu-ray jump did for most customers. I predict 2K resolutions encoded with AVC or VC-1 will become an intermediate point for large-scale exhibition, much as MPEG-2 was used for early HD video.
Nouveau's expressly stated that NV1 and NV03/NV04 are too fundamentally different to be properly supported by the project, but if the TNT(2) and up will soon be supported, that'd be kinda neat. Granted, we're talking about hardware that's about 15 years old, now...
AMD's continuing financial support from building the Xbox 360's GPU doesn't seem to be tainting them unduly. Let's not assume the worst about one and give the other a pass when a bogeyman's involved, OK?
Because changing financial regulations and laws practically requires an act of Congress to accomplish many times, so the old way stands - no matter how repulsively outdated and impractical it is.
Slashdot Mirror
Maybe he's talking about an Athlon(64) X2 6000+? If that's the case it's not competitive with any i3 I've ever heard of and wouldn't even make my Lynnfield i5 750 sweat, never mind an Ivy Bridge. But it should manage 1080p video OK... Maybe a player upgrade is needed.
With respect, I think you're misremembering things. Doom I can almost believe, but busy scenes would still give it an occasional hiccup. Duke might have given playable framerates if you used its abominably ugly "low detail" mode in 320x200. But Quake was very unforgiving - you'd be lucky to manage 512x384 on a then-scalding Pentium Pro 150 with a decent video card. The included TECHINFO.TXT file warned that id Software wouldn't accept bug reports about slow performance on 486 chips. It just wasn't designed for them.
If you wanna play Doom like it's 1993, there's always Chocolate Doom...
Um, wouldn't it make more sense to run an ARM port of MAME? I'm not sure anyone's still maintaining an MS-DOS port of MAME, and even if they were a low-end 486 wouldn't handle arcade games that were contemporary around the time of its heyday.
Seconding this - on less than a 50 MHz 486 with VLB video Duke Nukem 3D chugged badly. It ran pretty effortlessly on a friend's 133 MHz 486, as I recall, and on my Pentium 90 it was bearable at 640x480 when I used the SciTech Display Doctor.
Christ, that was a long time ago...
Yeesh. That's almost as heartbreaking as finding an ancient box I'd built for college two years ago, booting it up, installing Slackware, and discovering that no one ever bothered to fix the driver for its Rendition Verite 2200 to support 2D acceleration. At this point I wouldn't hold my breath for a fix; I'd just switch to Xfce and swear oaths of vengeance. It's probably more productive than waiting for this to get fixed on either side of the driver support pool.
Only five years of support is shitty, no question. Out of curiosity, what are the GeforceFX and Geforce 6 cards doing wrong in Gnome 3? The Geforce6 cards were just bumped to legacy support last month, but the FXes have been in limbo for a lot longer... and Nvidia's failure to ever release a driver better than beta quality for NT 6 was pretty fucking irritating.
In my experience, DOSbox or DOSEMU with FreeDOS utilities and userland apps. A VM running FreeDOS will run pretty poorly in a 64-bit OS due to all the trapping and translation of 16-bit code, and DOS hasn't been a major target of optimizations for most virtualization solutions. If you're just planning to play video games, it would be foolish not to try DOSbox first.
I do use Linux, but before DOSbox was good I wanted to learn how to make the best DOS-running computer possible. If that knowledge can be extended to help someone's quixotic, borderline insane hobby project, well, why shouldn't I help him? Just because I have better things to do doesn't mean that he does. :)
You'll run into those file size limitations pretty fast in certain edge cases - some scientific computing applications can generate gigantic files, to say nothing of video editing. But in this case FAT32 would mostly be useful for creating a large partition for your DOS/Win16 userland - you'd be surprised how fast a 2 gig partition can be eaten by a few application installs and regular use, even if you're using it as though it were still 1996.
Ah. Fair enough; I retract my objection. Uck, trying to squeeze Paint Shop Pro onto a cell phone display sounds like a recipe for a killer headache.
In those days you tended to know how your filesystem was laid out exceedingly well. As X0563511 points out, directories helped an awful lot. And if things were just too damned confusing, you could always write up a text file with some explanation of the naming scheme and put that into the directory.
Just realized I forgot to talk about Windows 3.1. Everything I ran seemed to work just fine, from Microsoft Office 3.0 to fussy old crap like SimLife and the Doom editing utilities DeuTex and DeuSF. I don't guarantee a problem-free experience, but in my aimless nostalgic fiddling I never ran into anything problematic, let alone the scowling ASCII art face of Bill Gates telling you that he's sent a team of men to force feed you a live chicken for desecrating his sacred Windows with an inferior DOS.
I have! There's at least one pre-rolled floppy image floating around on various boot floppy sites, usually called something like "MS-DOS 7.10" and based on a Win9x boot floppy. I recommend burning a boot CD floppy emulation mode with that image and a suite of DOS utilities and the aforementioned \Windows\COMMAND direcotry contents, sys c: to install to the MBR, copy files over (including pre-configured autoexec.bat and config.sys files), reboot, and you'd be able to get started. I keep harping on \Windows\COMMAND because if you try to use files from, say, MS-DOS 6.2, COMMAND.COM will bitch about them being from the "Incorrect MS-DOS version." Keeping things consistent will help you get a basic install going. Then you can worry about copying in FreeDOS files and tricking it out. This all worked very well for the dedicated DOS box I ran for several years on a thrown away Pentium II.
You say he won't "do pro-level editing on a cell phone," but he said he was using a tablet, and I'll remind you that "pro-level editing" from the time that Windows 3.1 was relevant also didn't generally use files that ran into the hundreds of megs either. I'm just disclosing limitations he might run into in the realm of not-quite-ordinary tinkering. It's worth noting that if he's doing it all in DOSbox in the first place, then this doesn't really matter so much; but if it's QEMU...
Well, sort of. You can hex-edit the COMMAND.COM from a Windows 95B or higher boot floppy, replace the "Windows 95(c)" or whatever tag's in there with "MS-DOS 7.xx," partition and format C:\, do a quick install to the hard drive's boot record from the floppy, copy over files from the old C:\Windows\COMMAND directory into C:\DOS, roll your own autoexec.bat and config.sys with proper path setting, reboot, and have a functional DOS install with FAT32 support. Then Windows 3.1 can run on top of it and take advantage of some of the functionality, but applications within Win3.1 may still try to warn you away from long filenames just because they were an unknown quantity at the time of development. Finding a functional defragmenter may also be tricky. At that point you could have a very large FAT32 volume, but above a certain size threshold your cluster size would balloon to 16KB or so, and you'd still be hobbled by the ~4GB filesize limit... to say nothing of memory addressing issues, or the large size of the COMMAND.COM in conventional memory. Some, or all, of these things could be circumvented by using FreeDOS, but I haven't really tried that. YMMV.
Thank you, that's wonderfully informative. Using 4K for effects work makes sense - going back in time, it's analogous to using 70mm film for optical effects while using 35mm for your main filming. Wow.
Yep, I just realized 4K indicates 3840x2160, because apparently 2160p just doesn't sound cool.. Blech.
...and dramatically higher encoding playback requirements unless you've got a new, dedicated piece of hardware to handle most of the computational overhead. Or sufficient patience... Believe me, I'm happy to see H.265, but it's going to be deployed at a trickle rather than a dramatic gush. There will be a lot of growing pains and deployment will be slow.
Yep - even if the set-top box customers are given is natively MPEG-4 AVC, the backend is frequently still MPEG-2 passed through a realtime transcoder. 4K resolution is going to be a big deal for theaters and exhibition halls of various stripes. At the smaller scale tech isn't ready for home yet by a long shot - AVC's successor HEVC is still in the drafting stages, never mind successful deployment - and the improvements won't have the impact that the DVD --> Blu-ray jump did for most customers. I predict 2K resolutions encoded with AVC or VC-1 will become an intermediate point for large-scale exhibition, much as MPEG-2 was used for early HD video.
That's even beginning to sound like... Full Life Consequences!
I think a 64 MB Geforce256 would be sort of OK for Compiz, though any modern integrated video would run circles around it.
Nouveau's expressly stated that NV1 and NV03/NV04 are too fundamentally different to be properly supported by the project, but if the TNT(2) and up will soon be supported, that'd be kinda neat. Granted, we're talking about hardware that's about 15 years old, now...
AMD's continuing financial support from building the Xbox 360's GPU doesn't seem to be tainting them unduly. Let's not assume the worst about one and give the other a pass when a bogeyman's involved, OK?
Because changing financial regulations and laws practically requires an act of Congress to accomplish many times, so the old way stands - no matter how repulsively outdated and impractical it is.