Master 512
Forum by Robin Burton
Beebug Vol. 11 No. 9 March 1993
As mentioned in the last issue, this month we'll take a look at PC graphics standards. I'll also tell you the end of the story about directory names, which will presumably be a surprise to all but one Forum reader.
HARDWARE CONSIDERATIONS
Compatible software has featured in the Forum recently and since the display is increasingly the problem these days an outline of PC display standards might be illuminating. It should clarify why some programs will never work in the 512 and might provide an insight into programs that do stand a chance before you try them, i.e. before you spend money. After all, even though shareware is by far the cheapest and best source of programs for the 512, it's not entirely free.
First let's summarise the 512's hardware. The 512's physical display is handled by the BBC micro. Obviously if the BBC micro can't display something, then the 512 can't either. That's where we start. The story begins ten years ago.
The 512's display problems are a consequence of the BBC micro's design, specifically its limited screen RAM. Screen RAM is limited because it's part of main memory, which in turn is limited by the maximum addressing range of the 8-bit 6502 processor, 64K bytes. Of this the MOS, a language and a bit of workspace take over half leaving, even in a Master, less than 32K for data, programs and display RAM. Shadow RAM eases the strain a little, but the 64K limit in the processor is the real block on any attempt at true memory expansion, whether for screen RAM or for programs and data.
There are two ways round such a limit. One is to change the processor to a 16-bit or 32-bit type that can address more memory. The other is to separate display RAM totally from main memory. Naturally, the two solutions combined are even better, but of course both increase the complexity, hence the cost of hardware. For the BBC micro's intended market the costs weren't acceptable. Bear in mind too, that when the BBC micro first appeared its graphics were pretty hot stuff, close to state of the art both within its price bracket and a bit beyond, as you'll see.
PC DESIGN
In contrast, PCs (apart from the best forgotten PC Junior) were aimed at business, so a machine's manufacturing costs weren't such a limitation. Because of this, PCs use a modular approach, where the basis of the system is the processor and its main circuit board plus a keyboard, but just about everything else, including RAM, is a plug-in extra.
This obviously allows a wide range of basic machine configurations, giving the purchaser more choice. Just as important, individual items can be replaced easily and cheaply if they fail or are superseded by new, higher specification hardware options. This design philosophy is precisely why there have been so many PC display standards.
If you look inside any PC from an XT onwards, apart from the very earliest machines and a few odd ones, you'll find that floppy disc control, hard disc control, serial ports, the parallel port and the display controller are all provided by extra, plug-in interface boards. These are called expansion cards, which plug into expansion-slots on the main board. Six to eight expansion slots is normal in PCs today.
Using more sophisticated, hence smaller and fewer chips than earlier cards, it's common to find several functions grouped together on a modern expansion board, particularly if they're facilities that logically belong together and that virtually everyone needs. For example AT-bus cards (known as ISA – Industry Standard Architecture, by far the most common PC architecture) will typically have two serial ports plus a parallel port, sometimes with a games port too, on one card called an IO card. A second card usually caters for two floppy drives plus two hard (winchester) drives.
In most machines this leaves only display support and, interestingly, display support is usually provided by a dedicated card, for various reasons. For one, display standards change more quickly than those for other peripherals, so a graphics adaptor and screen are likely candidates for upgrade during a machine's lifetime.
Also, it's not unusual to have two graphics adaptors and two screens on a PC. My old XT for example has a mono card and screen, plus a switchable CGA/EGA card and colour screen. Both screens can be used together, so I can run a program in the debugger on one and watch the program's output on the other at the same time. This two screen technique is most frequently used for separating very high definition graphics from text. In fact one or two 'high-end' applications almost demand two screens. They'll run on one, but they tend to be much less convenient to use.
Naturally, putting other interfaces on a display card would increase its cost, so it's never been considered a good idea.
Nowadays there's a further consideration. Even the most meagre VGA card has 256K of RAM with slots allowing up to a megabyte, which is both more useful and more usual these days.
In fact the most sophisticated (but not particularly specialised and rapidly becoming standard for Windows and CAD) graphics cards now have up to 3 megabytes of RAM driven by a dedicated processor, using a special colour chip called a Ramdac. As you can imagine, these cards are pretty full already without other hardware.
PC GRAPHICS
The main point to appreciate is that the way a PC outputs display data depends on the display card being used, rather than on the PC itself or its main circuit board as is the case in the BBC micro.
The most basic PC display is a monochrome display adaptor (MDA). These are still useful for text, though mono VGA is the standard these days. MDA cards contain screen refresh circuitry, hardware connections and little else, so MDA is the cheapest display type and, incidentally, it supports no graphics whatsoever. Clearly MDA programs should run in the 512, at least as far as screen output is concerned. Because it's an old standard, there should be few problems in other areas too.
Hercules was a mono display which did support graphics. Although popular for a time it never became a real standard for two reasons. It wasn't an IBM product and most graphics users wanted colour, not mono.
CGA (Colour Graphics Adaptor) was the first colour display standard for PCs, with a resolution similar to the BBC micro's but with extras, particularly for text. CGA offers two graphics modes, either 320x200 pixels in four colours or 640x200 in two (note that in DOS graphics modes are quite distinct from text modes: see table). The BBC micro's displays range from 640 by 256 in two colours (mode 0), through 320 by 256 in four colours (mode 1) to 160 by 256 in 16 colours (mode 2), so the humble BBC can actually surpass CGA graphics both in the number of colours or maximum resolution, so where's the problem?
|
|||||||||||||||||||||||||||||||||||||
DOS 3.x MDA/CGA
& PC Junior display modes |
Well, first you can see that, although two of the horizontal resolutions match exactly, none of the verticals do. DOS's 320 by 200 in four colours is nearest to the BBC's mode 1, so this is what the 512 uses for four colour graphics with good results for programs that work. Likewise 640 by 200 CGA display almost matches BBC mode 0, so this is where the 512's two colour graphics come from. As you can see, the BBC's vertical display resolution is actually 25% better than CGA's. As I said, the BBC was close to the state of the art at the time (unless you were paying five figures).
Of course CGA also displays text, but here the problems are potentially worse. A CGA 40 or 80 character by 25 line display can include up to 16 foreground colours. These are the usual seven plus black (as in the BBC), plus high-intensity versions of the seven plus grey. The first eight colours can also be used for background and while all this is going on (120 sensible combinations so far) foreground characters can flash and, if that's not enough they can be underlined. There's no limit to how all these are used, so any character can be in any combination of the above, regardless of neighbouring characters.
For text the 512 uses BBC mode 3, with the BBC's 6845 chip reprogrammed to move the lines together, unless you prefer 'PCSCREEN 7', which is standard BBC mode 3 with gaps between lines. As we know, mode 3 is two colour only, so the 512's text output can offer only standard, inverse, bold and underlined characters.
This is clearly an extremely limited CGA text emulation, much, much worse than for graphics. In fact it would be more accurate to say the 512 provides CGA graphics, but only MDA for text modes. If you have a text program that insists on exploiting CGA colour with no mono option (or no user settings for specific colours) you'll end up with unsightly bold characters, invisible text, a glaring background or sometimes a mixture of all three.
You can see why you should configure 512 applications for a mono display when there's a choice. In monochrome (using B&W text modes) programs will restrict themselves to normal, inverse and underlined text, so the author will (unwittingly) already have made the right choices for an acceptable (i.e. visible and legible) display in the 512.
All in all it's surprising that the 512 successfully runs more text programs than graphics, since it's potentially superior to CGA in colour graphics, but a long way short in text modes.
As usual there's more to it than just the numbers. Some PC graphics programs poke RAM directly, as do many BBC programs. The reason is that DOS graphics support is limited to setting physical to logical colours and reading or writing a single pixel. It's pretty slow too (forget PLOT, MOVE and DRAW: in DOS it's all strictly DIY). Just as in the BBC micro, programs that poke RAM directly won't work in other hardware. Consider: we all know of Master programs that won't run in a model B/B+ (and viceversa) and they're much more closely related than the 512 and a PC.
Legal graphics and text output is handled remarkably well by the 512's XIOS, even down to ROM BIOS level, although unmodified graphics are squashed 20% vertically for obvious reasons. On the other hand, direct memory pokes by-pass the XIOS, so they never get across the tube to the display. Result? A blank screen!
It's worth remembering that in some CGA programs it can seem that the 512 has crashed. However, if you know how to exit to DOS and press the appropriate keys 'blind', you may well find the 512's fine, only the display wasn't working. This is always worth trying if you can before you resort to re-booting, if you get a blank screen on trying a new program.
MYSTERY SOLVED!
In Vol.11 Nos.5 and 6 I mentioned that DOS Plus doesn't like extensions to directory names. That's incorrect, but it's only thanks to the persistence of Philip Draper that I found out.
When I first used DOS Plus 2.1 I only had floppy discs and found that DOS Plus gave an error if directory names had an extension. That this appeared again when I tested the CHKDSK example for Vol.11 No.5 was, therefore, no surprise.
The fact that CHKDSK created the problem didn't bother me either. After all quite a number of the 512's modified DOS utilities have bugs or omissions. I viewed this as just another one. For obvious reasons the CHKDSK examples were tested on floppy disc and the problem of the directory extension was, to me, quite normal. It wasn't to Philip Draper though. He wrote saying he had no such problems and had had such a directory name on his winchester.
I checked and again verified that my version of DOS plus didn't like directory name extensions. However, since I'd never tried it on the hard disc I did so after Philip's letter. Lo and behold, it worked! I again tried on floppy with the same result as before! This wasn't reasonable. I re-booted and re-checked a couple of times – everything was completely consistent, but far from satisfactory.
It next occurred to me that all my installed copies of DOS Plus, my emergency boot floppy, the winchester and all backups have always come from the same source – the copy of issue disc 1 taken when I first acquired DOS Plus 2.1. I therefore took a new copy from my issue disc, re-installed it and tried again. No, not yet! It was exactly the same as before. Hmmm....
Not really expecting much luck, but short of other constructive ideas, I took another copy of issue disc 1, but this time from Mike Ginns' master disc, and tried again. Finally, the floppy directory name extension problem vanished.
A double check confirmed all. Booting from my own issue disc brought the problem back, booting from Mike's cured it. It seems my issue disc has always had a small corruption in the XIOS which caused the directory name problem on floppy discs. That it didn't happen on the hard disc is easy to understand, as most of the hard disc XIOS code is quite separate from that for floppies. That I didn't discover this before is also easy to understand, I tend not to do things that I know don't work!
Thanks to Philip I've now corrected a bug in my copy of DOS Plus that for years I'd accepted as 'standard'. It turns out it was nothing of the sort!