BeebLink

[tom_seddon]

Sadly that wasn't the end of my GitHub release woes - so I've decided decided to retire AVR support, and BeebLink now officially only works with the Tube serial adapter + purple board. I don't use an AVR dongle any more, and I don't think anybody else ever did, and it was taking the CI server ages to set up the compiler to build the firmware, and I was having sporadic problems with the last set of AVR boards I bought anyway... so it's getting nuked while there's still the chance!

In terms of throughput, functionality and ease of setup, the Tube serial setup has the AVR dongle cleanly beaten. But there's not just that! - because it also doesn't occupy the user port, and it even acts as a handy Tube extension cable - I don't think there's much point supporting both types at once.

--Tom

[SpaceFlightOrange]

Bit late to the party, but...

I bought a Tube Serial adaptor from Chris about 2 months ago. Chris had mentioned BeebLink when I bought it, but it didn't support the Tube Serial back then. I finally got around to building it yesterday, and noticed this morning that BeebLink now supported it, so it was the first thing i tried.

Brilliant piece of work, Tom! Everything worked first time, and i really like the bootstrap process.

One question. Is it possible to copy from BLFS to disk? I tried switching to DFS and then back (using *BLFS) and it didn't seem to sync. when I issued a ctrl+B+break, it reported it couldn't sync. A restart of the server fixed this, so it could be coincidence.

I highly recommend everybody try this. A big thanks to both Tom and Chris for all your effort on this. It's really appreciated.

[cmorley]

One question. Is it possible to copy from BLFS to disk? I tried switching to DFS and then back (using *BLFS) and it didn't seem to sync. when I issued a ctrl+B+break, it reported it couldn't sync. A restart of the server fixed this, so it could be coincidence.

I don't know about the server sync problem - Tom's your man for that - but I successfully used ADT's *XFER with BLFS to transfer from/to ADFS and DFS with BLFS. Get the ADT2.0 ROM

[SpaceFlightOrange]

I don't know about the server sync problem - Tom's your man for that - but I successfully used ADT's *XFER with BLFS to transfer from/to ADFS and DFS with BLFS. Get the ADT2.0 ROM

Ah cool. I’ll try that. Thanks.

[SpaceFlightOrange]

I don't know about the server sync problem - Tom's your man for that - but I successfully used ADT's *XFER with BLFS to transfer from/to ADFS and DFS with BLFS. Get the ADT2.0 ROM

Ah cool. I’ll try that. Thanks.

Yup, that works No sync issues this time, switching between BLFS and DFS. Very nice.

Thanks

[myelin]

BeebLink looks awesome -- nice work Tom!

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.

I'm happy to make more of these boards if people are interested At the time I wasn't building anything myself for people because I figured that the postage costs (~$15 to the UK for a small parcel) would make things too expensive, but I could probably actually make a few of them for £30 shipped, and of course they're open source so anyone else is welcome to make them too. If this is something people would like, I'll work up a v2 board which uses an ATSAMD21 chip rather than the Pro Micro, which will make it a bit smaller and nicer looking. They should make a reasonable platform for BeebLink also, and because they're on the 1MHz Bus, they could bootstrap themselves with a few bytes of ROM.

If I get some time (and I should really finish Arcflash and the "Ultimate Elk Upgrade" board first) I'll see if I can get BeebLink to work with my board. I imagine it's just a matter of using different serial port registers -- my board just acts like the Beeb's serial port, except the tx/rx status register is &FCA1 (instead of &FE08), and the tx/rx data register is &FCA0 (instead of &FE09).

[tom_seddon]

Bit late to the party, but...

I bought a Tube Serial adaptor from Chris about 2 months ago. Chris had mentioned BeebLink when I bought it, but it didn't support the Tube Serial back then. I finally got around to building it yesterday, and noticed this morning that BeebLink now supported it, so it was the first thing i tried.

Brilliant piece of work, Tom! Everything worked first time, and i really like the bootstrap process.

One question. Is it possible to copy from BLFS to disk? I tried switching to DFS and then back (using *BLFS) and it didn't seem to sync. when I issued a ctrl+B+break, it reported it couldn't sync. A restart of the server fixed this, so it could be coincidence.

I highly recommend everybody try this. A big thanks to both Tom and Chris for all your effort on this. It's really appreciated.

Great to hear you've got it working, and thank you for the kind comments. Did you use the bootstrap process to get the ROM copied across? That's come in handy for me a few times after breaking something while working on it and discovering my last good disk copy is outdated...

Regarding the sync failure: what message did you get when the sync failed? If it happens again, try a second B+BREAK or *BLFS, and it will retry. Restarting the server is still an option as well though!

The sync is supposed to handle any issues transparently (at worst, taking longer than normal - this can happen if you press BREAK during a *LOAD or similar), but clearly it still needs a bit more work. If this happens to you a lot, and/or you figure out some way of reproducing it reliably, let me know and I'll try to figure it out...

Regarding file transfer: it sounds like you've got ADT's *XFER working, and that's what I use for copying files between BLFS and disk. Or, for one-offs, the Master 128's *MOVE also works (the BLFS works as a temporary filing system, so you can do stuff like *MOVE -BLFS-FRED -DISC-:0.$.FRED and so on). This isn't something I do super often, so there's currently no special support for it, but I'm open to suggestions.

(There is built in support for writing disk images to disks (*WRITE), as I use that for testing stuff - this overwrites the whole disk though!)

--Tom

[tom_seddon]

If I get some time (and I should really finish Arcflash and the "Ultimate Elk Upgrade" board first) I'll see if I can get BeebLink to work with my board. I imagine it's just a matter of using different serial port registers -- my board just acts like the Beeb's serial port, except the tx/rx status register is &FCA1 (instead of &FE08), and the tx/rx data register is &FCA0 (instead of &FE09).

I've never used the BBC's serial port so I'm not sure how much of the BeebLink code might need to change! The Tube serial protocol code is here: https://github.com/tom-seddon/beeblink/ ... serial.s65 - a bit involved in places as it has to switch between internal and external Tube on Master when required.

Documentation (such as it is) for the link routines: https://github.com/tom-seddon/beeblink/ ... r.s65#L665

If the device appears as a COM port on the PC, the server side should mostly work as-is, though it might need a bit of minor tweaking as it currently checks for the FT232H specifically.

If you do try this, let me know!

--Tom

[SpaceFlightOrange]

Great to hear you've got it working, and thank you for the kind comments. Did you use the bootstrap process to get the ROM copied across? That's come in handy for me a few times after breaking something while working on it and discovering my last good disk copy is outdated...

Not last night, I just copied the rom to a disk image and loaded it from my Gotek. I did try it this evening though. I transferred the B.TUBE program to a disk and wiped out the rom. I then ran the program. didn't seem to sync up though; I got a "Too many repeats at line 90" I'll have a play around and see what I did wrong.

Regarding the sync failure: what message did you get when the sync failed? If it happens again, try a second B+BREAK or *BLFS, and it will retry. Restarting the server is still an option as well though!

Sorry, I didn't capture it I switched to DFS and when I tried to switch back (*BLFS) It just sat there, so I had to escape out. when I issued a CTRL+B+BREAK the break message said something like "Timed out" but I could be wrong. I'll make sure I capture it next time. I should say that it hasn't happened since.

The sync is supposed to handle any issues transparently (at worst, taking longer than normal - this can happen if you press BREAK during a *LOAD or similar), but clearly it still needs a bit more work. If this happens to you a lot, and/or you figure out some way of reproducing it reliably, let me know and I'll try to figure it out...

Will do

Regarding file transfer: it sounds like you've got ADT's *XFER working, and that's what I use for copying files between BLFS and disk. Or, for one-offs, the Master 128's *MOVE also works (the BLFS works as a temporary filing system, so you can do stuff like *MOVE -BLFS-FRED -DISC-:0.$.FRED and so on). This isn't something I do super often, so there's currently no special support for it, but I'm open to suggestions.

(There is built in support for writing disk images to disks (*WRITE), as I use that for testing stuff - this overwrites the whole disk though!)

I'll be honest, I've never seen the *MOVE command I've only owned a master for 4 weeks but with ADT it worked flawlessly. Great stuff!

Thanks again. Your efforts on this are really appreciated.

[SpaceFlightOrange]

The only issues I'm seeing with syncing (when the ROM is loaded) is if my MBP goes to sleep, which is to be expected, waking it up, everything seems to carry on as before, without trouble.

This got me thinking...

I noticed the server is written in Node, but I also noticed you only packaged the server for windows or MacOS. does it run on Linux ok? My beeb's are across the other side of the room (ironically I only moved them a week ago) which means I have to move my MBP from my other desk over to connect it up.

so I have a couple of options:

1) move a beeb over to my main desk (both won't fit)
2) get a really long USB extension cable
3) drop a Raspberry Pi (or a Tinkerboard) on the Beeb desk and run the server on that, I can then make the volumes on the server accessible over wifi.

I like 3 as I have a couple of Pi's knocking around doing nothing right now (I seem to collect them, I have 2 running 24/7, one as a RISCOS/RetroPi machine and a couple for projects).

Could deploy the server in a Docker container.

Thoughts? Does the FT232H even show up on Linux/Pi?

Edit: Yes it does!

[tom_seddon]

Regarding the bootstrap process, maybe something went awry when I copy-and-pasted the code into the docs, or maybe I broke something - I'll have a look

The server does run on Linux, but you have to build it from source: https://github.com/tom-seddon/beeblink# ... t-yourself

I've never tried it on a Raspberry Pi, though. Might give that a brief go later tonight, and report back... if you try it, please let me know if you have any difficulties!

--Tom

[SpaceFlightOrange]

Works on the Pi

I need to setup a headless build now. I just transferred the SD card from my main pi to this pi3 with touchscreen.
Haven't tried deploying through docker yet. That's next...

[tom_seddon]

Oh, excellent - thanks for the report!

Your pi must be newer than mine, as it doesn't work for me ;)

(But it fails in a way that makes me wonder whether perhaps the Linux version I've got is just too old and/or weird - which wouldn't be surprising, as my Pi is a single core 700MHz ARMv6, and I've had it for quite a while. When starting the server with 'npm start --' it craps out with 'UnhandledPromiseRejectionWarning: Error: spawn udevadm ENOENT': well, indeed, since udevadm is in /sbin, and I'm not running BeebLink as root! But, since it runs fine on my Linux PC, clearly at least some distributions allow invocation of udevadm by non-root users...)

--Tom

[SpaceFlightOrange]

Yeah, this is a Pi 3 so it’s Arm v8. It’s the latest distro and yeah I’m not running as root.

I was planning on using an old Pi1 B+ which is v6 so I’ll let you know how it goes

[SpaceFlightOrange]

Got it running on a P1 B+ (ARMV6).

I used the latest image of Raspbian Stretch Lite and set it up headless.

The Pi is running Samba so I can drag and drop files to it

DISCLAIMER

on a Pi1 it is painfully slow! so it does tend to time out. The server takes a good few minutes to start. I could create a volume no problem, and then copy a basic file to it, but when I try to load it, the beeb hangs and then subsequent CTRL+B+BREAK results in a sync time out.

The curious thing is running top suggests its not actually doing a huge amount so I'm not sure what is happening. it doesn't seem to be consuming a great deal of memory either.

What I have learned is just how much faster the current gen Raspberry Pi is!!


EDIT -- I've just tried a Pi Zero W and its a lot faster!
No hanging when load the same file and the following CTRL-B-BREAK worked fine!!

The Pi Zero W seems to be working perfectly! top was reporting very similar stats to the Pi1 B+ but the performance is night and day! I've transferred a few files between DFS and BLFS, loaded a SWR and run some stuff and its working great!

[myelin]

Last night I had a go at getting BeebLink to work with the USB serial port on the Ultimate Electron Upgrade (which is very similar to the port on my board mentioned earlier in this thread; like the Beeb's own serial port but with data=&FCA0 and status=&FCA1). I ripped out all the block read code from tube_serial.s65 and implemented the setup, byte read/write, and startup routines. Making some progress -- it makes it through the sync and now hangs at this point:

Code: Select all

/dev/tty.usbmodem142401: sync: read server step 3 sync byte: 1 (304 bytes read)
/dev/tty.usbmodem142401: Got 0x01 byte - now synced
/dev/tty.usbmodem142401: Waiting for request...
/dev/tty.usbmodem142401: data in: 00000000: 01 00 ** ** ** ** ** ** ** ** ** ** ** ** ** **  ..              
/dev/tty.usbmodem142401: Got request 0x01. Waiting for 1 payload bytes...

Update: Turns out I needed to implement the status bytes when sending and receiving payload data; the Electron was sending 0x01 0x00 above but not terminating the payload with a 0x01 byte. After adding those, things seem to be mostly working, although during writes the Electron sometimes seems to send 0xff, which sends the server into sync mode. Here's an example during the "WRITE" stage of "OSGBPB WRITE BYTES TO BLOCK PTR, EXTENDING" in $.FS-TEST:

Code: Select all

SERIALSRV1: Request: Type: 13 (0x0d) (REQUEST_OSFIND_CLOSE)
SERIALSRV1:          00000000: a0 ** ** ** ** ** ** ** ** ** ** ** ** ** ** **  .               
SERIALSRV1: OSFIND_CLOSE: Input: handle=160 (0xa0)
SERIALSRV1: Response: Type: 8 (0x08) (RESPONSE_OSFIND)
SERIALSRV1:           00000000: 00 ** ** ** ** ** ** ** ** ** ** ** ** ** ** **  .               
/dev/tty.usbmodem142401: Sending 3 bytes response data...
/dev/tty.usbmodem142401: data out: 00000000: 08 00 01 ** ** ** ** ** ** ** ** ** ** ** ** **  ...             
/dev/tty.usbmodem142401: Done one request / response.
/dev/tty.usbmodem142401: Waiting for request...
/dev/tty.usbmodem142401: data in: 00000000: ff ** ** ** ** ** ** ** ** ** ** ** ** ** ** **  .               
/dev/tty.usbmodem142401: Got command 7f - returning to sync state

BTW did the *VON command ever exist? The only way I can see to set that bit is with ?&DF0 = ?&DF0 OR &80.

I managed to find a better example, with verbose logging on, where the Electron thinks it's sending 8C 04 00 00 00 40 2B 2E 35 01, and the server is receiving an extra FF before the zero bytes:

Code: Select all

/dev/tty.usbmodem142401: Waiting for request...
/dev/tty.usbmodem142401: data in: 00000000: 8c ** ** ** ** ** ** ** ** ** ** ** ** ** ** **  .               
/dev/tty.usbmodem142401: Waiting for payload size...
/dev/tty.usbmodem142401: data in: 00000000: 04 ** ** ** ** ** ** ** ** ** ** ** ** ** ** **  .               
/dev/tty.usbmodem142401: data in: 00000000: ff ** ** ** ** ** ** ** ** ** ** ** ** ** ** **  .               
/dev/tty.usbmodem142401: data in: 00000000: 00 ** ** ** ** ** ** ** ** ** ** ** ** ** ** **  .               
/dev/tty.usbmodem142401: data in: 00000000: 00 ** ** ** ** ** ** ** ** ** ** ** ** ** ** **  .               
/dev/tty.usbmodem142401: Got request 0x0c. Waiting for 65284 payload bytes...
/dev/tty.usbmodem142401: data in: 00000000: 00 ** ** ** ** ** ** ** ** ** ** ** ** ** ** **  .               
/dev/tty.usbmodem142401: data in: 00000000: 40 ** ** ** ** ** ** ** ** ** ** ** ** ** ** **  @               
/dev/tty.usbmodem142401: data in: 00000000: 2b ** ** ** ** ** ** ** ** ** ** ** ** ** ** **  +               
/dev/tty.usbmodem142401: data in: 00000000: 2e ** ** ** ** ** ** ** ** ** ** ** ** ** ** **  .               
/dev/tty.usbmodem142401: data in: 00000000: 35 ** ** ** ** ** ** ** ** ** ** ** ** ** ** **  5               
/dev/tty.usbmodem142401: Got confirmation byte: 53  - returning to sync state

I'm doing an echo test from my Python code right now to make sure there's not just something weird going on in the serial interface. It seems to be working pretty well so far; it's in a loop adding a byte to a string every time and echoing it back, and the string is now 4500 bytes long, so it's transmitted and received about 10 MB without any errors. That means either I'm messing something up in send_byte, or the node.js code is getting spurious bytes.

Echo code on the Electron:

Code: Select all

.A
LDA &FCA1
AND #1  ; bit 0 set if a byte is ready for us to read
BEQ A
LDY &FCA0  ; read incoming byte
.B
LDA &FCA1
AND #2  ; bit 1 is set if the outbound buffer has space for a byte
BEQ B
STY &FCA0  ; transmit outgoing byte
JMP A

My repo and Electron ROM: https://github.com/myelin/beeblink/blob ... om/elk.s65

[tom_seddon]

Awesome - an Electron version of BeebLink would be great!

Did you spot https://github.com/myelin/beeblink/blob ... /notes.org? - that has some notes, that I think are still accurate, about the status bytes. (That file isn't very organised overall, and it's not linked to from the main docs, as it's mainly just random scribblings for my own benefit.)

Regarding *VON: yes, this is now gone, but there may be some references to it that I didn't excise. The approved way to set or clear the verbosity bit is now *BLCONFIG V+ (set) or *BLCONFIG V- (clear). The *BLCONFIG docs are a bit dismissive about the V option (because when you switch it on you get a huge pile of crap printed out, which for most people won't be very useful...) but I should probably update them to make them a bit clearer about how it could be useful when working on the ROM.

Regarding the FFs: this is a bit of a mystery to me. The fact you've got things working OK with Python but failing with node.js is a bit worrying... but I'm not sure offhand what the problem might be. It is possible, I suppose, that there's sometihng weird going on in the node.js stuff, as I'm just using some random serial port reading library from npm. But it's worked fine for me (so far??), so I've never spent any time looking at what it might be doing internally.

Maybe I should add test modes to the server, that just produce/consume a specific stream of bytes, just as a flat stream of bytes, with no status bytes or anything like that? Then there could be test code on the BBC/Electron that does the opposite... when the server's producing data, the Acorn side could then crap out if it receives invaid data, and vice versa when consuming.

--Tom

[myelin]

I did see the notes page! Very helpful to understand the sync process and why it exists. It took me a little while to correctly implement that, mainly because I started with avr.s65 rather than tube_serial.s65, so I ended up with some outdated stuff. Then most of the errors were due me using the A register for my nonblocking reads and writes instead of Y like the tube serial code, but forgetting to change the associated ldy instructions to lda. Works now though

The V option was extremely useful for me during the initial bringup, as is the tx_dp debug output, although you're right -- nobody is going to want that during normal operation, so it doesn't need to be easy to access.

I'm digging deeper into the FF mystery. I verified that it's not coming from the Electron by looking at the tx_dp output then scoping the output from the FPGA to the microcontroller, so I'm moving one step closer to the laptop (running macOS, if that's any help). I have a logic trace of the USB lines on my microcontroller now that is slowly being decoded by sigrok-cli (and what looks like a stack of Python libraries) on my Linux box, plus a copy of the verbose server output at the same time, and I'm hoping to be able to match them up and see what's going on. Fingers crossed!

The test mode would be extremely useful -- if you can find something that works nicely with the Tube serial port, I can try running it on my machine and seeing how it goes.

[myelin]

I haven't looked through the decoded USB capture yet, but I have managed to reproduce the FF problem on Linux, which means I can use Wireshark to capture the USB packets at the OS level and see what's going on there. Expect more here in a bit once I figure out how to configure that

BTW it looks like the paths in import statements on Linux need to match the case of the filenames; here's a commit that lets the server run on Linux: https://github.com/myelin/beeblink/comm ... a76f1fe32b

Update: Capturing on Linux didn't work as well as I hoped, but I managed to use Wireshark+XHC20 on macOS to capture a packet trace... and indeed the FF is in there. So it looks like the issue is probably in the microcontroller firmware... next step will be to take a look at its USB stack. Unfortunately I tried to be clever with this board and use an ATSAMD11C14A, which is small and cheap, but not supported with the mainline Arduino tools, so there's a chance that the USB or CDC implementation is buggy.

[tom_seddon]

Excellent, thanks for that - I don't test on Linux as often as I should! (I'll do a cherry-pick from your branch later to get that fix, which I don't think will cause any problems with merging, fingers crossed...)

It might be redundant now you've reproduced the problem, but I've now added some simple test modes to the server and test programs for the Acorn side. "Documentation", such as it is: https://github.com/tom-seddon/beeblink/ ... l-test-xxx

The sender sends an endless stream of incrementing bytes (0, 1, 2, 3, etc.) and the recipient checks it's receiving the expected values.

--Tom

[myelin]

Just had my first successful run through the FS-TEST program "GOOD. TOOK 147.52 SECOND(S)."

I ported my program over to run under ASF4 / Atmel START, and after a ton of debugging work trying to understand what was going on with the USB CDC implementation, it now runs. Took ages, but now I'm a bit more familiar with the internals of USB at least!

ASF4 makes you handle the USB requests yourself rather than wrapping them in a file-like interface; you have OUT requests (when the host is sending data) and IN requests (when it's checking if you have data for it). When you call the send function (cdcdf_acm_write), it queues up a packet for the USB hardware to send when the host next requests data (by sending an IN packet). When you call the receive function (cdcdf_acm_read), it gives the USB hardware a buffer to put data into when the host next requests a transmission (by sending an OUT packet).

The weirdest thing is that the system signals that a transmission is done by sending a packet that's smaller than the buffer size (64 bytes for full-speed / 12 Mbit USB). So to do a 64-byte transmission, it sends a 64-byte packet then a 0-byte packet. My code was getting confused by the 0-byte packets and not requesting any more, so it would hang the first time the host sent a multiple of 64 bytes. I suspect the Arduino code has something similar, because I've often found that things get weird unless I limit my transmissions to 63 bytes at a time... will have to go have a look into this next!

[myelin]

Chris's FT232 adapter board + PAL arrived just in time for me to build and fit it to my Master 128 before VCF West starts tomorrow -- so I'll have the Electron and Master 128 side by side at the Computer History Museum this weekend, running the two different versions

As expected, the Tube adapter is a bit quicker than the Electron version -- FS-TEST runs in 84.71 seconds on the Master, compared to ~145 on the Elk.

[tom_seddon]

Awesome! - have a good time, and please post a pic or two if you take any I expect Acorn stuff is a crowd pleaser? - there can't be that much of it in America, and I bet few from outside the UK will have seen a Master or Electron in particular...

I fixed a very bad bug today (affected transfers when using the Master's internal Tube) so I've done a quick push to fix that. Hopefully you haven't run into this yourself yet... it's sort of amazing that the transfers worked at all really.

As part of this I have removed FS-TEST from the repo, which I should have done before, as its home is now https://github.com/tom-seddon/beeb-fstest (repo is a BeebLink volume, so you can just point the BeebLink server at its parent folder and off you go). There's also a sort-of thread for beeb-fstest on here too: viewtopic.php?f=4&t=15855&p=231452

--Tom

P.S. If it would be compatible with whatever Google have you do when it comes to making open source contributions, I'll add you as a contributor to the repo. Happy to take PR(s) if you'd prefer though!

[tom_seddon]

On an experimental basis, BeebLink now supports the UPURS cable. Thanks to MartinB, hoglet and sweh for the UPURSFS transfer routines, and thanks to kieranhj for the loan of a cable.

Throughput is not as good as when using the Tube serial adapter, but everything else works the same!

UPURS support is currently experimental, as it hasn't had much testing yet, though I'll be doing some myself in the coming weeks. If you try it out, I'd be interested to hear how you get on! - please file a GitHub issue or post here if you run into any difficulties.

--Tom

[myelin]

Picking this up again on a new laptop so I can bootstrap a prototype MGC MKII (I'm helping Dave H out with the CPLD work there)...

P.S. If it would be compatible with whatever Google have you do when it comes to making open source contributions, I'll add you as a contributor to the repo. Happy to take PR(s) if you'd prefer though!

It absolutely would be. Google's rules in a nutshell for open source contributions are (a) it has to be under a real open source license and (b) it has to be clear that Google owns the copyright to what I'm writing. Being a contributor on GH repos is totally fine.

That said, I'll send you a PR for the Elk code once I've retested it and made sure it still works!

[tom_seddon]

It absolutely would be. Google's rules in a nutshell for open source contributions are (a) it has to be under a real open source license and (b) it has to be clear that Google owns the copyright to what I'm writing. Being a contributor on GH repos is totally fine.

That said, I'll send you a PR for the Elk code once I've retested it and made sure it still works!

Excellent - my Beeb stuff is all GPL v3 (or later, if you prefer) so the OSS licence part is hopefully covered. I've now added you as a collaborator, so feel free to push to the repo if you like, and I'm still happy to take a PR if you'd rather. Either way, I'm quite looking forward to having a major global corporation on the list of contributors to my little project

--Tom

[tom_seddon]

UPURS support is now non-experimental, as it's had a good amount of testing over the past 3 months, with no problems noted.

I'm now using UPURS BeebLink on my BBC B, so it will be getting ongoing use.

--Tom

[tom_seddon]

Picking this up again on a new laptop so I can bootstrap a prototype MGC MKII (I'm helping Dave H out with the CPLD work there)...

P.S. If it would be compatible with whatever Google have you do when it comes to making open source contributions, I'll add you as a contributor to the repo. Happy to take PR(s) if you'd prefer though!

It absolutely would be. Google's rules in a nutshell for open source contributions are (a) it has to be under a real open source license and (b) it has to be clear that Google owns the copyright to what I'm writing. Being a contributor on GH repos is totally fine.

That said, I'll send you a PR for the Elk code once I've retested it and made sure it still works!

Are you still using this at all? Is it in a state to be merged in? No problem if not!

I've done a couple of minor BeebLink things recently (CI spring clean, and some minor bug fixes), and I've got first draft support for Roland's Wi-fi board planned. So I figured while I'm doing things to it, if the Electron version is ready to be merged in, I could do that.

--Tom

[tom_seddon]

I mentioned BeebLink in another thread, so I thought I'd add a post to indicate it's not dead! Just stable enough that the average change I've made hasn't been significant enough to warrant a new release.

But I have been doing stuff to it, and there's probably enough now to justify one in the next month or two:

* improve OSBPUT performance
* file time stamp display via *LOCATE and new *WINFO command
* add compatibility with TubeHost (https://github.com/sweharris/TubeHost): access your TubeHost files via BeebLink, using the same * commands and server directory structure
* move some stuff out of the ROM and into BASIC programs, so the UI is a bit nicer

--Tom

[Sazhen86]

I mentioned BeebLink in another thread, so I thought I'd add a post to indicate it's not dead! Just stable enough that the average change I've made hasn't been significant enough to warrant a new release.

But I have been doing stuff to it, and there's probably enough now to justify one in the next month or two:

That's great news! I have a Model B and a Master both connected to a BeebLink server running on a Raspberry Pi and it's so useful I have the ROM installed permanently in both machines.

Looking forward to the new release.