BeebLink

[tom_seddon]

BeebLink - https://github.com/tom-seddon/beeblink - a file storage system for the BBC Micro. Get your PC doing something useful: have it store your BBC Micro files, and serve them to your BBC over a high speed link. No more swapping disks, no more seek times, no more 31 file limit. You even get 10 character file names.

Server supports Windows, macOS and Linux; filing system ROM is compatible with BBC B, B+, Master 128, and second processors.

You can connect BBC and PC using cmorley's Tube serial board or MartinB's UPURS serial cable.

Windows and macOS builds of the latest release are available from the latest release page: https://github.com/tom-seddon/beeblink/releases/latest

If using Linux, some self-assembly will be required. See the Linux instructions: https://github.com/tom-seddon/beeblink#linux

I'm always interested to hear from anybody that tries it out!

--Tom

P.S., similar projects that inspired this one: Mount BBC Micro disc images over USB (early versions of BeebLink used an AVR microcontroller too); John Kortink's 65Link (which I used for many years, but the parallel port requirement is a faff on modern PCs, and it's not FOSS); UPURSFS+TubeHost (haven't used it but JGH's FS code was a useful reference in places).

[lurkio]

Interesting!

You might want to mention it connects to the Beeb's user port.

[tom_seddon]

Thanks for the suggestion - good point. I've tweaked the description slightly ;)

The ROM in the github release zip is built to use the User VIA, of course, but if you've got multiple user ports, you can rebuild the ROM with a different setting for the `via' constant and have it use a different VIA's port B instead. (If there are common locations for extra VIAs, and there's any interest, I can set up the build process to build multiple ROMs for the GitHub releases, each one accessing the VIA some other address.)

--Tom

[lurkio]

If there are common locations for extra VIAs, and there's any interest, I can set up the build process to build multiple ROMs for the GitHub releases, each one accessing the VIA some other address.

Have you seen the various different builds of MMFS for different user-port variants?:

• https://github.com/hoglet67/MMFS/wiki/Release-structure

[cmorley]

Have you considered supporting the FT232H Tube serial in you software? Very fast and doesn't clash with a SD reader on the user port. The 'purple' boards are £5.57 on eBay at the moment.

[tom_seddon]

Can that work if you have an internal second processor installed? I've got one of John Kortink's 16MHz ones in my Master...

I would quite like to support more link types though - I didn't really write the code with this in mind, but it wouldn't take much to make those bits pluggable. Also, 100KBytes/sec. (The code already deals with the transfers in 256-byte chunks when possible, so perhaps it could do them in the flat out mode you mention in the thread, to at least some degree...)

One thing the current setup does have is an out-of-band signaling mechanism, so the BBC can let the PC know when BREAK was pressed, and the PC (and firmware) know to cancel the current operation. (At the moment this takes the form of the firmware detecting when the 6522 handshaking has been disabled, and doing a USB stall.) It felt like it needed this, because the user port is half duplex, and it certainly seems to have done a fair job of stopping the two sides getting out of sync. But maybe it's not necessary with a full-duplex channel? The PC could always be listening when it's sending, and I could tweak the sending protocol to have some kind of in-band reset.

--Tom

[cmorley]

Can that work if you have an internal second processor installed? I've got one of John Kortink's 16MHz ones in my Master...

It should be possible since the IO is done on the Host.

Assuming the buffer is already in the host something along the lines of... claim Tube (possibly already claimed by you), switch to external port (no idea how this is done on the Master), do USB transfer, switch IN/EX tube from OS copy, release Tube (wait if data destined for Parasite)

The simple PLD code I did already plays nice (electrically) with an external Tube.

One thing the current setup does have is an out-of-band signaling mechanism... But maybe it's not necessary with a full-duplex channel? The PC could always be listening when it's sending, and I could tweak the sending protocol to have some kind of in-band reset.

You could send your reset token on reset to the PC. On the Beeb you'd need to eat and discard from the FIFO until empty/synchronised again.

[dominicbeesley]

Just spotted this, I'll have to give this a go when I get a chance, it looks interesting.

This sounds rather like what I use, I hacked JGH's hostfs to use Myelin's 1MHz bus SD/serial card. Currently it runs at around 33KB per second (i.e. similar to 300,000ish baud) but HostFS wastes some of this with acking and nacking - but its pretty nippy! I use a slightly modified version of sweh's perl server to serv up .inf files. I've not got round to making it release-able as I didn't think Phil was going to make (m)any more serial boards. However, if he is I'd recommend you have a look at his board as another datalink layer option.

D

[dominicbeesley]

The code looks very nice! Out of interest what sort of transfer speeds do you get with this setup. I know for most purposes speed is not the main issue but for some of the stuff ive been doing it certainly is nice!

[tom_seddon]

The maximum raw throughput depends on transfer direction and which processor's memory is involved:

Host memory: save: 78.55 KBytes/sec, load: 61.83 KBytes/sec
Parasite memory: save: 85.69 KBytes/sec, load: 69.06 KBytes/sec

(Saves are quicker because of the way the handshaking works, and parasite memory is faster because loading or storing the data is just an unindexed read/write of the FIFO register.)

For *LOAD in practice to host memory (the slowest case unfortunately), I seem to get about 57KBytes/sec. with the server running on OS X. That timing includes OSFILE and whatnot and the time the server spends searching through .inf files - not especially noticeable interactively, even with large numbers of files, but it does make a dent in benchmarks.

--Tom

[dominicbeesley]

Thanks Tom,

That certainly sounds like a useful improvement on what I was getting before when reading / writing with ADFS to a CF card - I got Linux working on my Arm CoPro but it was taking many minutes to load the image file and I got bored.

I've got an AVR on order and will hunt out some ribbon cable and a user port plug.

D

[Elminster]

What platforms will this run on by the way.

Obviously BBC B. How about Master? And would it work with an Electron with one of the User Port Cards? (assume possible with software tweaks)

[tom_seddon]

It definitely works with the Master as that's what I'm currently using. It's intended to run on the B/B+/etc. too, but I haven't tested it yet - this will happen once my B is in working order again! And it ought to work on the Electron, too - should just be a case of changing the VIA address. (It may well be incompatible with Electron second processors, though. I get the impression they work differently from the BBC variety.)

I'll be tweaking the build process at some point to produce a number of different ROMs, so you'll be able to pick the one you want based on the VIA address. As per lurkio's link there'll probably be fe60 (standard address), fe80 (Master modem), fea0 (Master ethernet), and I'll generate one for each 16-byte aligned address in page FC, which should cover Electron and 1MHz bus user ports on the BBC.

But for now, if you want to try it on the Electron, or with an alternative VIA, it's a DIY job I'm afraid :( - get the ROM building on your PC , and change the value of `via' in the constants near the top. And, if you need it, you'll also have to make a similar change to `VIA%' in the bootstrap program.

If you (or anybody else) tries it on the Electron, I'd love to hear how you get on!

--Tom

[Elminster]

Perhaps I might get around to it on Electron one day.

For now I have added Beeblink the the Hardware List as just working on Beeb/Master, until someone gets it up and running on the Electron.

[tom_seddon]

I've tested it on model B now (including with 6502 second processor), and can confirm it does work! (There were some * commands missing, though, which I've now added.)

--Tom

[hoglet]

The board I've been using is the Minimus AVR 32K (ATmega32U2), and if you've got one of those in +5V mode, and some bits of jumper wire, you should be good to go with one of the GitHub releases. (It uses the LUFA library, so with a bit more DIY, it could be straightforward getting it to work with other USB-equipped AVR boards too...)

I'd like to give BeebLink a try, but it seems the Minimus AVR USB 32K board is not easy to obtain now.

Can anyone suggest a suitable replacement?

Dave

[cmorley]

Can anyone suggest a suitable replacement?

I spoke with Tom at the last ABUG about using the FTDI USB board. It shouldn't be terrible to replace the read/write in the client code and use the Tube serial although it is complicated by the way of ACKs... Tom would be better placed to explain but he's used an ACK signal to eliminate the requirement for timeouts in his protocol (if I understood correctly!).

Did you get an adapter board off me? I think you might have. I have some spare still.

Using the Tube keeps the user port free but I won't get round to looking at the client code anytime soon.

[tom_seddon]

I'd like to give BeebLink a try, but it seems the Minimus AVR USB 32K board is not easy to obtain now.

Can anyone suggest a suitable replacement?

I haven't actually yet tried it with another board, but it's intended to be relatively straightforward to make it work with anything supported by LUFA. In theory:

1. tweak MCU/ARCH/BOARD in firmware/Makefile to tell LUFA what sort of AVR device you're using
2. adjust firmware/beeblink.c to change the port/pin assignments for user port connection as appropriate (you need one AVR port for user port PB0...PB7, and two other pins on other ports for CB1/CB2)
3. adjust defines in firmware/serial.c to change port/pin assignment for serial log output (just 1 pin)

I think that should then be it.

I've got some alternative boards on order, that seem to be more easily obtainable, and are available from multiple sellers: https://www.amazon.co.uk/gp/product/B07 ... UTF8&psc=1 - so more info to follow, when they finally arrive. (I think they're coming from China. I ordered them 2 weeks ago...) While I'm doing this I will also tweak the code+build process so it does a better job of supporting more than 1 type of board :)

If you try it with a non-Minimus board yourself then I'd love to hear how you get on!

--Tom

[hoglet]

If you try it with a non-Minimus board yourself then I'd love to hear how you get on!

I have a Teensy 3.5 which is ARM based.

Do you think it's worth having a go with that?

(I really have no idea how AVR specific BeebLink and it's dependencies are)

Dave

[tom_seddon]

If you try it with a non-Minimus board yourself then I'd love to hear how you get on!

I have a Teensy 3.5 which is ARM based.

Do you think it's worth having a go with that?

(I really have no idea how AVR specific BeebLink and it's dependencies are)

The firmware is effectively AVR-only as it stands, as it depends on LUFA, and LUFA only supports AVRs :(

By coincidence, my new AVR boards actually arrived today (unnoticed when I posted earlier, as they were wrapped in some junk mail...) so I'm going to have a go at making it work on them now.

--Tom

P.S. regarding other types of link entirely, like the FTDI Tube interface: I would like to support these, as the user port requirement is a bit of an impediment. I'll make a post about this in the next day or two.

[tom_seddon]

On a beta basis, subject to ongoing testing - BeebLink is now compatible with the SparkFun Pro Micro/Arduino Leonardo. The two designs are supposedly compatible, and the Pro Micro is open source, and available from various sellers, so there should now be fewer difficulties obtaining a BeebLink-compatible board.

What I bought: https://www.amazon.co.uk/gp/product/B075LM7R57/

I've pushed the code for this to GitHub, and there's a new release (beeblink-20190204-015356-8056fbb), now with separate Minimus and Leonardo/Pro Micro .hex files. Aside from the rather more annoying programming process on the Leonardo/Pro Micro board, the experience should be basically the same in either case.

Only thing to note, I think, is that performance (as measured by the built-in *SPEEDTEST command) is slightly worse with the Leonardo/Pro Micro board. The way the GPIO pins are assigned means each byte transferred takes more AVR instructions, and in the PC->BBC direction this reduces throughput by ~10%. But you probably won't feel short-changed, as it's still ~55KB/sec...

I'm now using a Pro Micro board with my Beeb, rather than a Minimus, so if there are any issues with it, I'll probably find them, and hopefully fix them.

--Tom

[hoglet]

I'm now using a Pro Micro board with my Beeb, rather than a Minimus, so if there are any issues with it, I'll probably find them, and hopefully fix them.

I've just bought a Pro Micro from eBay, which should be here by the weekend.

I see you have documented the connections:
https://github.com/tom-seddon/beeblink/ ... s/setup.md

Any chance of a photo of your setup?

Thanks,

Dave

[tom_seddon]

Any chance of a photo of your setup?

Certainly, but don't expect much :) - I just plugged the dupont cable straight onto the header pins. It looks a bit rough and ready.

The two loose yellow pins are for resetting the device, which puts it into programming mode for a few seconds. The black and white wires connect to a USB serial dongle.

The Minimus boards have a pushbutton-based programming mechanism, so I used them on a breadboard, thought it was barely neater:

--Tom

[BigEd]

Edit: ignore me, I am completely confused. See below.

That's a very long cable, and it doesn't seem to have alternate grounds (or power) so the various address and data lines are being given the maximum chance to interfere. As there's no isolation on the Beeb, that's the main databus, and is a risky tactic to say the least.

An IDE cable does the trick, and is a length which doesn't break things - perhaps you could use an IDE cable to bring the Tube to your breadboard and then break out the signals you need using only relatively short wires?

[cmorley]

An IDE cable does the trick, and is a length which doesn't break things - perhaps you could use an IDE cable to bring the Tube to your breadboard and then break out the signals you need using only relatively short wires?

Tom is using the user port not the Tube.

[BigEd]

D'oh! (I thought I was looking at the thread where the plugging in of the Tube cable was causing the machine to hang at boot.)

Time for some and perhaps a and hopefully

[tom_seddon]

Does that even count as a cable? The multicoloured bit did come as one unit, but each end has its own individual connector, and they tear apart very easily, so I'm inclined to class it as a bunch of stuck-together bits of jumper wire myself I'm sort of amazed it works at all, really.

On another note, I've found my first issue with the new type of AVR board - though luckily not a very serious one in practice: when doing a *SPEEDTEST benchmark with serial debug output enabled, the Pro Micro reboots partway through the test, and restarts in a non-functional state that requires a further manual reobot. Reproduced on 2 out of 3, so I expect when I try number 3, that will do the same...

This seems to be purely down to the delays that the serial logging introduces - it does the serial output manually, so there's a spin loop of ~1/115200 sec per bit - but I've yet to figure out why this is a problem for one type of board and not the other.

With serial debug output disabled (the default), all seems well.

--Tom

[tom_seddon]

Still none the wiser about this serial output issue, but it's just done 12 hours of error-free transfers (via the *SPEEDTEST command) with serial output disabled (as is the default). So whatever the problem turns out to be, you shouldn't see it with the default settings, at least.

--Tom

[tom_seddon]

BeebLink now supports cmorley's Tube serial adapter in comms mode, meaning installation and setup is much simplified, and max throughput is improved in most cases* - It's enough of an improvement over the AVR setup that it's now the preferred link type, even though strictly speaking this is beta functionality.

Also looks a lot tidier:

--Tom

* - Transfers to a Master 128 internal second processor's memory are unfortunately a bit slower than before, but still 60+ KBytes/sec

[cmorley]

I have been trying Tom's beeblink on a Model B with the Windows prebuilt server.

We highlighted some problems with the releases on Github which Tom has fixed.

Turns out CTRL-B-BREAK is a bad idea since CTRL-B turns on the printer... making me think that beeblink was freezing

I heartily recommend anyone who has the purple board to give BeebLink a go.
https://github.com/tom-seddon/beeblink