Project updates

We've been neglecting the '816 and OHO-related FPGA designs for a while - in part due to some involvement in the highly recommended visual6502.org project.

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.)

So in a sense we were 2-1 down: our design works in the Master internal coprocessor.

On the plus side, we met some nicehelpfulpeople and were able to discuss some possible reasons.

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.

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)

It lives! Rich has been busy for the past few weeks, coding up a TUBE-like project in verilog for our 40-pin FPGA module. He has a BBC Master with a second processor board, which has a socketed TUBE ULA ripe for replacement.

With Rich on Verilog and socketing technology, and Ed on the sidelines with Google searching and general moral support, it took us a week and a half to get from a lifeless second processor to the magic output shown here, which shows - to the initiated - that the BASIC interpreter we're talking to is indeed running on the second processor.

The best we could get from this setup is a precise replica of the original - the existing second processor is serving only as a test bed and there isn't much scope for improvement by replacing the TUBE. But once we have a design we're happy with, we can re-use it: perhaps for a 40MHz T65-based second processor.

We're not the first to want to implement our own TUBE: we think there may be three efforts out there. Most recently, John Kortink posted pictures of his replacement board which he may yet sell as a product. It looks great!

But for us, this is just a good challenge, and it sets us up for integrating an entire second processor on an FPGA module, and that in turn could be a platform for experimenting with CPU variations and inventions.

Oh, and we intend to release the code as open source, so the project can benefit from fixes and enhancements from the many talented and energetic people out there who are sure to be interested! (And maybe serve as the basis of a product, if someone wants to do that.)

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)

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.

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.

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.

Success!

(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:

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.

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.

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...

We've got 4 Beebs between us - 3 model Bs (one a loaner) and a Master. We also have an Electron, but that's a bit special - the CPU is socketed, and the video/CPU memory sharing is more involved.

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.