Date : Wed, 24 Aug 2011 18:39:00 +0200
From : rick@... (Rick Murray)
Subject: Tube ROM
On 23/08/2011 13:06, famrowland wrote:
> co-pro concept, but the video limitations.
I guess it depends a lot on what you wanted to do? I see the co-pro as a
way to take something Beebish and turbocharge it. Not to mention the
additional memory. Indeed, it makes it feasible to have a large program
AND a high resolution display at the same time. No more MODE 7 jobs.
> it was mostly pretty niche and far from main stream.
Still is. Think about it, the main reason for the x86 co-pro was to be
compatible with DOS and Windows, and it was pretty cool. But after a
fashion, it because less capable and more expensive than just getting a
budget PC. I like my RiscPC's co-pro because of what it represents, not
what it can do. But then it's the generic bog-standard (40MHz?) 486, so
it won't set the world alight. Especially not when in the RiscPC's main bus!
> I would have killed for a 4-colour Mode 0 back in the day (80?32?4),
How many computers of the same era offered better displays?
VIC-20? So not a comparison!
Commadore 64? That's a better graphics chip. But 320?200 is less than
MODE 0's 640?256 (or is it only 160?200 in colour mode?)
Dragon 32/64 PMODE 4's 256?192 is the highest resolution mode.
Oric Let's not discuss this one...
ZX Spectrum 256?192 with quirky restrictions.
Amstrad CPC Can almost match the Beeb, with 640?200, but it is a
two colour display, essentially a MODE 0.
IBM CGA card Highest resolution - 640?200 *monochrome*.
As you can see, pushing video to a plug-in board was a good idea on the
PC, but the increased memory capabilities of the machine (~640K) mean it
isn't usually much bother to take some space for drivers. Here's
something from TurboC++ v1.0:
D:\TCPP\BGI>dir *.bgi
Volume in drive D is Local Disk
Volume Serial Number is 78CE-3F1A
Directory of D:\TCPP\BGI
28/02/1991 02:01 6,348 ATT.BGI
28/02/1991 02:01 6,332 CGA.BGI
28/02/1991 02:01 5,554 EGAVGA.BGI
28/02/1991 02:01 6,204 HERC.BGI
28/02/1991 02:01 6,665 IBM8514.BGI
28/02/1991 02:01 6,012 PC3270.BGI
6 File(s) 37,115 bytes
0 Dir(s) 1,061,576,704 bytes free
D:\TCPP\BGI>
While 6K isn't a lot, it is a massive amount for a machine habitually
supplied with 32K onboard. Not to mention that *no* generic TurboC++
program will be able to take advantage of a WUXGA or WSXGA display, for
the basic reason that no such driver exists.
Therefore:
> they should have put the video on a separate card like PCs did, not
> the processor.
would not have worked. You'd need memory, and lots of it, on daughterboards.
Bear in mind the Beeb was designed to be a single-box cheerfully
impenetrable machine for widespread deployment in schools. Acorn made
the move from the System # machines (which were modular) to the Beeb
range (with were expandable, not modular).
> Hence all the daft limitations and messing around with TINT in Basic V.
I think you'll find that was a limitation of the VIDC. From a palette of
4096 possible colours, you could pick 64 base colours (*not* 256). The
mode was 256 colours because of those 64 base colours chosen, they were
offered in four 'tints'. You can see this clearly with !Paint's colour
palette when in a 256 colour mode. Essentially, you *cannot* have 256
unique colours. It is a 64 colour display, with tint options thrown in
for free.
However, later versions of RISC OS (3.5+) threw away this bit-fiddling
crap [*] and went with COLOUR <red>,<green>,<blue> and likewise for GCOL.
* - still there for compatibility, but if you want your 32K/16M
colours, you aren't getting it with COLOUR numbers and TINT...
> So ultimately, it wasn't the CPU that was the bottleneck but the I/O,
> and they targeted the wrong thing.
Au contraire. They may be niche products, but the different
co-processors came in handy.
Kindly name a computer into which I can plug an ARM as a co-processor.
An ISA board on a PC? Perhaps, once upon a time.
A BBC Micro today? Yes.
It is a difficult quandry, actually. I don't necessarily see the point
of developing for an ARM on a Beeb when a basic RISC OS system is a lot
friendlier. However, I *do* see the point of running said developed code
directly on the ARM. You can't so easily do that on a RISC OS machine
when the ARM there is actually running the operating system and dev
tools. This is, perhaps, why software such as QEMU exist, but then
you're limited by the accuracy of the emulation.
Still, the Beeb co-pro kit was good enough to get Arthur off the ground.
It isn't just a fancy toy.
> Discuss ;)
;-)
Best wishes,
Rick.
--
Rick Murray, eeePC901 & ADSL WiFI'd into it, all ETLAs!
BBC B: DNFS, 2 x 5.25" floppies, EPROM prog, Acorn TTX
E01S FileStore, A3000/A5000/RiscPC/various PCs/blahblah...