Timeline for What we commonly call PCs are in fact ATs, correct?
Current License: CC BY-SA 3.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 3, 2018 at 3:57 | comment | added | Criticizing Israel not allowed | @Raffzahn I'd say it comes down to slowness being acceptable for your particular software, and not for supercat's software. | |
| Mar 22, 2018 at 14:53 | comment | added | Raffzahn | @supercat I still have a hard time to find your reasoning useful. Looks more like an attempt to justify a fight against some feature for premature optimization. Not even the IBM PC was only about the CGA. Even less all the other machines of the same time. Sure, nailing hardware down to a certain configuration of a specific machine is fine for some hobbyist programming in your basement. In a profesional environment that comes down to badly written. | |
| Mar 22, 2018 at 14:37 | comment | added | supercat | @Raffzahn: Blame the designers of the architecture for not having provided a usable alternative in the days of the 8088 or even 80286. The design of the CGA meant that a routine which accepts a bunch of data to be displayed and shows it as quickly as possible in one operation can vastly outperform a function which has to be called separately for each character. There's no particular reason the BIOS couldn't have included such a function, but it didn't, and there's no way to get decent performance on the CGA without such a function. | |
| Mar 22, 2018 at 10:56 | comment | added | Raffzahn | @supercat LOL. But sure, it's a valid opinion to call code that interferes with other programs and depends on very specific configurations 'not badly written'. I call it a pain in the ass. | |
| Mar 22, 2018 at 6:32 | comment | added | supercat | @Raffzahn: Code which accessed hardware directly was not "badly written". | |
| Mar 22, 2018 at 2:37 | comment | added | Raffzahn | @supercat and your point is? | |
| Mar 22, 2018 at 0:26 | comment | added | supercat | @Raffzahn: If software will need to write a lot more than that, it can wait for vertical retrace, blank the screen, draw everything, wait for retrace, and unblank the screen. The only time the BIOS does that, however, is when scrolling. Having the screen go blank for 1/60 second isn't great, but scrolling would be unusably slow if it didn't. Software that writes to display memory can draw arbitrary content in 1/60 second, but the BIOS has no function to do so. | |
| Mar 22, 2018 at 0:18 | comment | added | supercat | @Raffzahn: One difficulty with the CGA text mode on the original PC is that unless the screen is blanked, it can only be written at certain times. In the course of each frame, it's possible to write about 400 bytes to the screen during a vertical blanking interval and one for each of 200 horizontal blanking intervals. A function which writes a chunk of display data by waiting for horizontal blank, outputting one byte, checking for vertical blank, and either outputting 400 bytes or going back to waiting for horizontal blank, will be able to manage about 600 bytes/frame. | |
| Mar 22, 2018 at 0:06 | comment | added | supercat | @Raffzahn: Some clones could perform text-screen updates reasonably fast using the BIOS, but the original PC couldn't. The only graphics functions supplied by the BIOS were get pixel and put pixel, and I don't know that those have ever been fast enough to really be useful for much. | |
| Mar 21, 2018 at 23:25 | comment | added | Raffzahn | @supercat Not sure about the timing 30 years later, but I remeber that using the DOS/BIOS never had resulted in a relevant slowdown. My clients where quite satified :) Beside, having a portable MS-DOS program did outwight any speed penalty. Especially in the early days, when hardware was extreme different. | |
| Mar 21, 2018 at 22:35 | comment | added | supercat | @Raffzahn: Code using the supplied abstraction layer would take about a second to fill an 80x25 text screen, and many seconds to fill a 320x200 graphics screen. Software which bypassed that abstraction layer could fill an entire text screen in 1/30 of a second and a graphics screen in about 1/10 second. Using hardware directly allowed programs to be more than a full order of magnitude faster than would have been possible otherwise. | |
| Mar 21, 2018 at 18:03 | comment | added | Raffzahn | @StephenKitt 256 Colours would be a VGA, and especialy here IBM offered an awsome software interface (similar, just less awesome) for EGA. And for Sound, there where great libraries to handle this in a less hardware dependant fashion. | |
| Mar 21, 2018 at 17:46 | comment | added | Stephen Kitt | ... especially if they wanted to output 256 colours or use a sound card! | |
| Mar 21, 2018 at 16:28 | comment | added | Jules | To be fair to early PC software, the abstraction layers available to them were often totally inadequate for what they needed to achieve. | |
| Mar 21, 2018 at 15:37 | history | edited | Raffzahn | CC BY-SA 3.0 |
added 843 characters in body
|
| Mar 21, 2018 at 14:22 | history | answered | Raffzahn | CC BY-SA 3.0 |