Comments? Mail us at email@example.com
Latest news from Rich is that his Master - our only Master - doesn't power up any more. We may be sourcing one or two replacements.
Other exciting news: from RetroClinic - a co-processor in the same spirit as some of our ideas. Not quite a product as yet, but certainly a project.
As a tangent, here's an idea: the magicROM! It's an FPGA-based second processor which fits into a ROM socket - no flying leads - emulates a ROM to the degree that it can hook into the OS or take over the machine, and offers two or more bidirectional channels between host and parasite by means of reads from specific pages (for writes) or locations (for reads.)
It should be possible to do this on an OHO GOP - only 24 pins, so would look like a 2k ROM but would need an adapter to sit in a normal 28 pin ROM socket.
There are plenty of details to figure out: hooking into the OS, polling for interrupts, building an entire second processor in a GOP board... so this is just food for thought at present.
We had a grand day out at the VCF at Bletchley Park, and discovered that our Tube ULA replacement design didn't work: it didn't work in both a 6502 and a Z80 external second processor, in both cases connected to a Master.
So in a sense we were 2-1 down: our design works in the Master internal coprocessor.
It turns out that there are (at least) three Tube interfaces - all of which will of course work with the original Acorn Tube ULA because they were designed to do that. Specifically, the databus is in the case of the BBC Model B a direct connection to the heavily loaded NMOS CPU's databus, and is helpfully furnished with pulldown resistors. The internal Tube of the Master is again a direction connection, but to a CMOS databus, with rather less loading and without resistors. Finally, the external Tube of the Master is connected to the PBC, a custom chip which bridges the three databusses on that machine, with both pullup and pulldown resistors for termination.
All three busses have variable loading depending on the configuration of the machine: number of ROMs, 1MHz expansion, disk controller and so on. There are quite a few cases to consider. That's why Ed got his ancient scope out of the garage in the hope that study will be rewarded.
Meantime Rich has been taking a tally of various combinations - including a Model B with one of our 816 cards in it - and we have seen some life out of the Z80 second processor, kindly donated to us by Tom at the VCF.
Bletchley Park is an excellent museum by the way.
Just a quick note that you can now download our sources for the Tube design.
We chose to use the LGPL license, because it's the least restrictive copyright license that keeps the code out in the open - you can use it, modify it and redistribute it even as part of a larger closed-source design so long as you also redistribute the sources for the tube.
We hope you find the sources useful, or at least interesting, and welcome your feedback.
(Our project is only a project, not a product. It might one day be part of a product, but in the meantime if you just need a replacement tube ULA, source one secondhand or try John Kortink's Retula)
We're still here, and we still have a project. We also have a couple of OHO modules: FPGA on a DIP adaptor with 5v compatibility. One is a 24-pin device and we plan to use that as a logic analyser, to help debug why the beeb816 only works reliably with a synchronous clock. The other is a 40-pin device and we plan to use that first as a 6502 replacement using the T65 design, and then as a TUBE replacement using our own design (which doesn't yet exist)
This may take some time: but we're still here!
By kind donation we have an additional dead Electron board in our collection, so Ed decided to start getting some desoldering experience on a couple of scrap boards. At the very least, we'll need to desolder the 40-pin CPU, and perhaps it will also be useful to desolder the 68-pin ULA.
We tooled up with some Field's Metal and a cheap and cheerful butane powered blowtorch - something which melts at domestic temperatures and something to supply more heat than we should sensibly apply to a circuit board. This is sure to be a success!
Field's Metal will melt in hot water, so we only had to wave a hot iron at the pictured lump to collect a few big drips in a foil tray.
One desoldering approach is to replace the solder with the alloy, remove the alloy with a desoldering pump, and then apply mild heat to the board. Any remaining alloy will melt and the part can be removed.
Well, certainly the part was removed. Only a little of the alloy escaped to the food preparation area. Only one cooking utensil was tagged with a "Not for food use" label by the kitchen police.
The alloy approach having worked once, on a 30-pin SIMM socket, Ed had a try with the blowtorch on a 40-pin DIL socket. Near the socket anyway: let's just say that damage was done. Next time, perhaps a lighter touch on heating everything gently and evenly.
So, back to the alloy, but using the torch with the soldering tip. Still too hot! When the 40-pin socket eventually became free, it only had 35 pins left.
Time for a tactical withdrawal! Next time, listening to advice, we'll be preheating, re-soldering and taking more care with the desoldering pump. For the CPU, we'll try heating from the component side as we desolder from the underside.
(We're still chasing down a logic problem in the accelerator card: we're going to fit up one of our FPGA modules as a logic analyser.)
Good news and bad news from yesterday's session with 3 beebs, two and a half accelerator cards and some updates to CPLD and ROM.
good news: Ed's unreliable beeb is rock-solid when running entirely in accelerated memory.
bad news: It's become so unreliable that getting booted into an accelerated state is a matter of luck.
good news: We were able to load and run Elite at 4MHz, and the frame rate is visibly better.
bad news: It's entirely academic because the game runs too fast (not just smooth.)
more bad news: We couldn't load the game at 8MHz: the disk reads seem to return partial sectors.
good news: Our loaner beeb is in fact able to run at 8MHz - Ed had mis-identified the pins and was trying to run at 16MHz.
bad news: We're not doing as well as we thought at arbitrary frequencies: the accelerator is fine but there are rogue writes to the host RAM, clearly visible on the screen but we'd missed them because we run over a serial port most of the time.
good news: We're stable at 12.5MHz, running from a 50MHz crystal oscillator.
The acceleration and memory mapping is working well enough that we updated the ROM to populate and switch in the overlay at boot time: it takes no appreciable time to copy 64K. We haven't yet made high-speed clocking the default at boot time..
Overall, we can run at about 6 times the speed of an original beeb, we have the equivalent of sideways RAM and a patchable copy of the OS in RAM, and we have a 65816 CPU with at least 64k memory free for experiments. That's good news.
Our adventures so far have in theory been able to clock our CPU replacement board at any reasonable frequency, but we've found it only works reliably when the clock is related to the host clock. Fortunately the Beeb's video ULA gives us a 2/4/8/16MHz selection, and using that we have one machine running at 8MHz and another at 4MHz.
Since the problems seemed to be in accessing the host RAM, as soon as we'd implemented the address mapping to place the lower 32k into our on-board fast memory, Rich had a go with an unrelated clock: a 2.45MHz crystal clock fitted in the socket we'd put there for the purpose.
(Our first efforts at mapping host RAM failed to comedy errors like mapping in the wrong direction)
So Rich immediately tipped out his box of misc crystals, and tried our 4-second memory test at various speeds:
which normally runs in about 3.8s, but with *OVERLAYON, we get:
and the test runs in under a second.
Now, 17.18MHz is outside the spec of the 14MHz 65816, so this isn't expected to be a robust result. Also, the system speed depends on the exact timings in the CPLD, so the max speed keeps changing as we tweak the design for features or for robustness.
Nonetheless, we're happy!
816 board is about ready to be tried on some serious software. The best example is of course Elite, the ground-breaking 3D space combat and trading game.
To run a game, we need to load it, and so it was time to see if our upgrade is compatible with the disk storage of the day. So far, we'd done our experiments with a serial connection to a host, and pasted in test code in BASIC or srecord format - or added it to our ROM.
Many original Beebs were bought without a floppy disk controller, and needed an OS upgrade to support one. Ed's was one such. By the time he came to upgrade (£120?) there was a choice of two disk controller chips and several different ROMs. The original chip - an Intel 8721 - was the more expensive option, and so Ed's Beeb, until recently, had a WDC 1770 chip and a Solidisk ROM.
It also has defective RAM.
Our loaner Beeb had a less constrained history, and had the 8271 controller, and doesn't scribble all over its own memory.
At the first attempt, we were able to read the disk catalogue. But trying to load Elite failed with a disk error. We could only read the first block or so of any file. We have to conclude, for now, that the 8271 won't work with our 816.
Swapping to Ed's machine, after some tactical wobbling of the power connector, success! Elite will load, sometimes, and play for a few seconds before decaying memory gets the better of it.
So the 816 can happily run the code which drives the 1770 controller.
All that remained was a tense session of removing 8 chips, replacing 2, replacing the 8271 with the 1770 daughterboard and fitting the two jumpers needed for the Solidisk kit. Then swapping the DFS ROM. Then reconnecting the keyboard. No boot. Reconnecting the keyboard correctly...
Success! On 17th Jan 2010, Elite ran on our Level 1b board.
Next step: turning up the clock.
Ed's beeb had a RAM extension - Solidisk sideways RAM - which was becoming unreliable. So he removed it (several flying leads had to be removed too: this was quite an invasive upgrade.)
But from that point on, the machine has become unreliable. It will usually boot, but stray characters start appearing on screen, and the rate of stray writes starts to rise. This makes it an increasingly marginal platform for testing.
So Ed took the path of least resistance and switched to the loaner machine for a few months.
Our cunning plan is to map some or all of the host RAM into our fast RAM on the Level1b board. Mapping RAM is attractive for other reasons: if we can access the memory at full speed instead of host speed, we get faster access to the stack and zero page, also to the OS and language variables in low memory, and to any user program which is located in the mapped area. (Unfortunately, as it makes no sense to speed up for single accesses, there isn't actually any speed gain unless the code and data are both in fast memory. It would be very nice to be mapping the ROM space too, but that's for another day.)
Back to the flaky machine...
If the stray writes are confined to RAM, the machine become usable again! We've got 128k on board (512k also supported) so mapping 32k isn't a big deal. If we map video memory onto the board - the Beeb uses from 1k to 20k of the 32k for video - then we won't see anything on screen. Unless, in an extra level of cunningness, we mirror writes for some or all of the mapped RAM back to host memory. The CPU will have to slow for some proportion of writes, but we'll get to see graphics and the stray writes will only disturb the view, not the machine.
The first effort is likely to be: 16k mapped, writes not mirrored back to host.
1-10 of 17