Rick's b.log - 2010/12/31
It is the 21st of November 2024 You are 3.15.149.24, pleased to meet you!

Beeb goodies

The first item is pretty simple. Here it is:

If you find yourself shrugging and asking "And?" then you're probably reading the wrong b.log, so try this instead.

For those still reading, it is a new ROM chip to put inside the BBC micro. It will require minor surgery, being 32 pins rather than the expected 28, but that is not an insurmountable problem.
But why?
I know you're asking this. Well, the process of burning an EPROM is quite a pain in the ass. It involves hooking up the EPROM programmer, getting the old A5000 running, getting the ROM image to the A5000, programming the EPROM... assuming I don't have to UV erase the EPROM first. This is a pain when you look at more modern solutions. For example I am recording a film as I write this. To videotape? Nope. To harddisc? Nope. To a flash device. It is a little slower than a harddisc, but ultimately just as flexible.

This is where the device pictured above comes in. It looks and feels just like a traditional ROM chip. But it isn't. The AM28F020 is a 256KiB FlashROM. Offering in-situ programming and an erase/reprogram capacity in the order of 10,000 cycles minimum, it should offer all the benefits of EPROMs with a lot less hassle.
This isn't to say it is perfect - for it will require a bit of patchwork to fit this into the system (normal EPROMs are either 8KiB or 16KiB). In addition to this, the entire Flash cell must be erased prior to programming, so individual EPROM images cannot be written at will.

All of this said, I plan on using half of the chip's capacity to provide 128KiB as 8 × 16KiB images. The BBC MOS can support up to 16 ROMs, the standard BBC micro only offers 4 slots (the B+ offers more), but a little bit of cut'n'paste into the logic decoding will allow possibilities to be expanded.
In addition to this, it does not look too difficult to write some code to write to the chip. It ought to be a weekend's work to code up something to permit up to 8 images to be selected. The chip will be erased, and the images will be loaded and written one after the other. The datasheet reckons on 4 seconds to program the entire chip, although we will probably take a bit longer than that. In fact, the only thing that concerns me is how the Write Enable is handled. Is it possible to write to EPROM space? I'll probably need to jack into the CPU control bus as I rather doubt Acorn has tracked !WE anywhere near the EPROMs. ☺

Here's the second thing:

The system works by using the host computer (the Beeb) as an input/output device. It looks after the screen, the floppy discs, all the basic boring grunt work. The parasite processor, the co-pro, just... executes code. Really really quickly.
The Acorn patented 'Tube' interface contains FIFO buffers, so the co-processor can push instructions to the host machine. While some waits are inevitable (such as loading data from disc), a good many of these can be deferred to be the responsibility of the host processor. In essence, you'll have a 3MHz processor running in tandem with a 2MHz computer. The computer will deal with all the mundane work (keyboard scanning, writing to disc, blah blah) and the co-processor can just get on without worrying about that. Indeed, due to this duality, some programs may fly along twice as fast as before.

I don't want to try fitting this inside my Beeb. What with networking, floppy disc, etc, I do not wish to cook the power supply. I have an Acorn Teletext Adaptor in a "cheese wedge". Since teletext is, sadly, mostly historical, I think I might remove the teletext board and fit the co-processor in its place.

While the world is making use of Windows, seeing the liberty of Linux, and gloating over iWhatever, let me remind you that a little British home computer offered, pretty much as a standard set of options:

• Rather nice set of expansion possibilities. Most early '80s computers offered an expansion port and, if you were lucky, a parallel port. The BBC offered analogue, parallel, 1MHz bus, Tube, user port, and most of the bits for floppy disc interfacing except for the actual disc controller chip.
• It is let down on the memory capacity being 32K RAM as standard, and rather less with expansions. On the other hand, many comparable era machines had an operating system that was barely more than a program loader with rudimentary handlers for basic interrupts. Enough to get a game loaded, in other words.
• While most BASICs were an insult to the concept of a programming language, BBC BASIC offered real procedural programming (as opposed to the usual GOTO/GOSUB spaghetti). It also offered proper variable names (and not just paying attention to the first two letters). Full support for real and integer variables. And if this isn't already enough to give you warm fuzzy pseudo-sexual feelings, then how about a fully featured assembler? There's absolutely no need to POKE obscure incantations into memory, you can write with opcodes, like a real programmer. Embed it, compile at runtime, switch back and forth between BASIC and pure code, and plenty of access to the inner workings of the OS too. All of this in a mere 16KiB.
• Many such computers have what can only be described as display issues. For example, you often get a "hi-res" display and a "low res" one. There are numerous quirks, like you can only have certain background colours, or you can only have text in a certain 'resolution' or a certain part of the display.
  The standard BBC Micro? 7 display "modes" offering a variety of combinations of resolution versus colours (from a high-res monochrome to a lowish-res 8 colour). Text could be placed by the operating system, in any valid choice of colours, with full scrolling and linewrapping options. As if this isn't good enough, you can switch the text cursor to graphics mode and then place it at any point on the screen. And if that isn't good enough, there's an extra display mode using a teletext character generator (text, eight colours). This makes a full 40×25 colourful text based display available consuming a mere 1KiB. Great for databases and the like where you need the maximum amount of memory for data tables.
• Networking support. Full user-based access with filing systems, file support, and such. The protocol is port-based allowing all sorts of third-party applications to run within the networking system. There can be over 250 individual stations on a network. While some machines are dedicated file servers (usually station 254), it is possible to turn any capable machine into a server with the right software. It is also possible to 'bridge' networks. This may be useful for mixing older slower BBC micros and newer faster RISC OS machines. Both can run at a speed most appropriate to the hardware without causing problems to other types of hardware.
• Full detailed access to the operating system, plus numerous OS calls so a lot of code works in the same way irrespective of the baseline hardware - floppy, harddisc, network, or more modern replacements such as GoMMC.
• And saving the geekiest to last, Acorn has quite the history when it comes to jaw-droppingly awesome co-processing units. Here we have a 6502 co-processor, which while arguably the most useful with regards the BBC Micro, is also one of the simplest. Others are an 80186, a Z80, and (for ultimate cool) an ARM. Jon Kortink expanded upon this theme with a device called the "ReCo6502" which is a modern version of the co-processor which can either run a standard 65C02 at up to 14MHz, or a mostly-compatible 65C816 with half a megabyte of memory.
  This behaviour continued into the RiscPC range where the machine offered two slots, one for the main processor and the other for an x86 to allow fast PC emulation. Akin to the 6502 co-processor, the host RiscPC does all the I/O stuff, with the x86 executing code...

But all said, perhaps the most astonishing thing is the 6502 co-processor can provide immediate benefits just by, you know, plugging it in. This is hardware from the early '80s. No jumpers, no complicated drivers, no ritual to get it going. Just plug it in. It won't run optimally, but it'll be an immediate boost.
Technically, you'll require a ROM with the Tube code, however as this is a part of some DFSs and most versions of DNFS, there's a chance you'll already have this installed. I do, so getting the tube going will require me... plugging it in.

Okay, this is reading like a drooling advocacy post. But given the technical innovations that Acorn were capable of, it's a shame that the world tended to prefer the bargain-basement crap. Just look at the Spectrum...

But, hey. It's the final day of the year. There's half an hour left for me, and my favourite country (and, <cough> about half the planet...) has already had their New Year. You'll find some pictures here.

Whoever, wherever, Happy New Year. I hope 2011 is good to you.

Best wishes,
Rick.

Your comments:

Rob, 1st January 2011, 01:28

Happy new year, and a great post.. oh, and don't worry about overloading the Beeb PSU by putting the 2P inside - I used to run a fully loaded beeb, full ATPL board (12 roms) and beeb-powered dual floppies without a problem... The 6502 2P doesn't draw all that much power - it's got a jumper on-board to draw power from the host after all.

Austin, 2nd January 2011, 15:39

Happy New Year Rick! Looking forward to updates regarding your Beeb work. I might dig out one of my co-pro Masters... I have a turbo, 512 and one with a Torch Z80 board in storage. CPN (sic) in ROM on the Torch, a truly wacky piece of kit.

opal, 2nd January 2011, 18:20

Hello Rick,  Happy New Year !  I wish you all the best in this year. Keep going with this nice blog and good luck with this project (I know you have been panning to get back to it for a long time).  Regards