`*DIR M` then OSGBPB 8

[tom-seddon]

Reported:

One bug I think I've located is that doing *DIR M (or any other directory letter) followed by OSGBPB 8 causes a server crash. It then goes into an endless loop seemingly trying to reopen the com port that wasn't correctly closed in the exception handler.

[dominicbeesley]

Detailed log output of the event

COM15: Got request 0x0a (REQUEST_STAR_COMMAND). Waiting for 5 payload bytes...
SERIALSRV1: Request: Type: 10 (0x0a) (REQUEST_STAR_COMMAND) (5 (0x00000005) byte(s)
SERIALSRV1: 00000000: 44 49 52 20 4d ** ** ** ** ** ** ** ** ** ** ** DIR M
SERIALSRV1: STAR_COMMAND: command line="DIR M"
SERIALSRV1: 2 part(s), Y=4 (0x4)
SERIALSRV1: [0]: "DIR"
SERIALSRV1: [1]: "M"
SERIALSRV1: 2 command line parts:
SERIALSRV1: 0. "DIR"
SERIALSRV1: 1. "M"
SERIALSRV1: Matched command: DIR (

)
SERIALSRV1: Response: Type: 2 (0x02) (RESPONSE_YES) (0 (0x00000000) byte(s)
SERIALSRV1: 00000000: (no data)
COM15: Sending response 0x02 (RESPONSE_YES) (+0x0)
COM15: Sending 5 bytes response data...
COM15: Done one request / response.
COM15: Waiting for request...
COM15: Waiting for payload size...
COM15: Got request 0x14 (REQUEST_OSGBPB). Waiting for 14 payload bytes...
SERIALSRV1: Request: Type: 20 (0x14) (REQUEST_OSGBPB) (14 (0x0000000e) byte(s)
SERIALSRV1: 00000000: 08 00 00 00 00 00 00 00 00 00 00 00 00 00 ** ** ..............
SERIALSRV1: OSGBPB: Input: A=0x08, handle=0 (0x0), addr=0x00000000, size=0 (0x0), PTR#=0 (0x0), 0 data bytes
Error: not TubeHostFilePath
at mustBeTubeHostFilePath (C:\snapshot\server.build\tubeHostType.js)
at TubeHostType.findObjectsMatching (C:\snapshot\server.build\tubeHostType.js)
at FS.OSGBPBReadNames (C:\snapshot\server.build\beebfs.js)
at FS.OSGBPB (C:\snapshot\server.build\beebfs.js)
at Handler.fun (C:\snapshot\server.build\server.js)
at Handler.call (C:\snapshot\server.build\server.js)
at Server.handleRequestInternal (C:\snapshot\server.build\server.js)
at Server.handleRequest (C:\snapshot\server.build\server.js)
at handleSerialDevice (C:\snapshot\server.build\main.js) COM15: connection closed due to error: Error: not TubeHostFilePath
Error opening serial port COM15: Error: Opening COM15: Access denied
COM15: connection closed.
Error opening serial port COM15: Error: Opening COM15: Access denied
COM15: connection closed.
Error opening serial port COM15: Error: Opening COM15: Access denied
COM15: connection closed.
Error opening serial port COM15: Error: Opening COM15: Access denied
COM15: connection closed.
Error opening serial port COM15: Error: Opening COM15: Access denied
COM15: connection closed.

[tom-seddon]

Crap... looks like I missed a couple of cases in the TubeHost code when I was rearranging things at some point. Sorry about that. I'll get this sorted out this week.

(I should really try to improve the "quality" "assurance" "process" generally, as per the linked issue, so that the bits of BeebLink I don't regularly use myself get at least some testing.)

[dominicbeesley]

No need to apologise. I should really look to move all my stuff to beeblink compatible volumes and probably hack my perl hostfs server to work similarly but it's a long list of projects I have to get to! D

…

On Wed, 11 Feb 2026 at 23:47, Tom Seddon ***@***.***> wrote: *tom-seddon* left a comment (tom-seddon/beeblink#209) <#209 (comment)> Crap... looks like I missed a couple of cases in the TubeHost code when I was rearranging things at some point. Sorry about that. I'll get this sorted out this week. (I should really try to improve the "quality" "assurance" "process" generally, as per the linked issue, so that the bits of BeebLink I don't regularly use myself get at least some testing.) — Reply to this email directly, view it on GitHub <#209 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACDUWGUNQZDVZ5P24M5RD334LO5RRAVCNFSM6AAAAACURNA72CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQOBXHA2TEMBTGU> . You are receiving this because you commented.Message ID: ***@***.***>

[tom-seddon]

There's a prerelease that hopefully fixes this now, plus a few other minor things: https://github.com/tom-seddon/beeblink/releases/tag/beeblink-20260214-155120-0eac6ea-prerelease

[dominicbeesley]

Thanks Tom, I'll try and get a look at this this week if I can get the tube-serial card to work. If not, how easy or difficult would it be to port to another, slightly different fast COM port? The ROM looks trivial - just change port address and which bits are TXF, RXF but does the host end use any special properties of the FTDI driver or should I be able to force it to use a different COM port?

…

On Sat, 14 Feb 2026 at 15:59, Tom Seddon ***@***.***> wrote: *tom-seddon* left a comment (tom-seddon/beeblink#209) <#209 (comment)> There's a prerelease that hopefully fixes this now, plus a few other minor things: https://github.com/tom-seddon/beeblink/releases/tag/beeblink-20260214-155120-0eac6ea-prerelease — Reply to this email directly, view it on GitHub <#209 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACDUWGW4DL2PIF6MM3JJMTD4L5A4HAVCNFSM6AAAAACURNA72CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSMBSGA4TONJVGE> . You are receiving this because you commented.Message ID: ***@***.***>

[tom-seddon]

Hopefully anything that appears to be a serial port on the PC end should be good in theory! I'm using a 3rd party npm module for handling serial port stuff in Javascript/Typescript, and I'm not actually 100% certain what it does internally, but from a quick skim it didn't look like it was doing anything special and/or FTDI-specific. If the device comes up in the --serial-list-devices then you should just be able to tell the server to open it.

There is some checking for specific serial devices IDs in the server code that you may notice, but this is only to determine whether to auto-open a given device by default or not. More devices can be added to the auto-open list if they work!

(One note: if you're going to modify the code, please start from wip/master (branch the prereleases are generated from) or wip/tom (the branch I do stuff in myself), as both are currently now meaningfully ahead of master.)

[dominicbeesley]

Oops, I just saw this was sitting in my draft folder, I must have forgotten to send. I just got some time to try this out - I get a bit further and my test case in BASIC now passes but the application still hangs...I'll try and get some time to debug that this weekend, it's probably a me thing! I also found I'd had a go at writing a driver for the myelin 1MHz serial port some time ago I've brought it up to date with wip/tom and its on my fork in commit abcaecb I've not done a pull-req yet as its quite bodgy. Would it be ok to include this in the tube_serial driver with the appropriate #definey includes as its almost identical apart from hardware address and the lack of configured/suspend bits Sunday update. I'm still getting random hangs during OSGBPB calls (both reason code 8 and 4) I've not managed to catch it doing this when I've got the logic analyser hooked up unfortunately. It seems to be a 1 in 10ish chance of it hanging. I've now written a quick BASIC test case that provokes it (attached). One thing of note is that if I run with a 65816 as the CPU (instead of the t65 core which emulates a NMOS 6502) it seems to be ok. I would be quite surprised if this turned out to be a bug in the t65 core though as it has been pretty stable for a long time now. I'll try and drag a real beeb out at some point this week and see if that is the same. D Transcript of GBPB COM4: Waiting for request... COM4: Waiting for payload size... COM4: Got request 0x14 (REQUEST_OSGBPB). Waiting for 14 payload bytes... SERIALSRV1: Request: Type: 20 (0x14) (REQUEST_OSGBPB) (14 (0x0000000e) byte(s) SERIALSRV1: 00000000: 08 00 0e 3c ff ff 01 00 00 00 1c 00 00 00 ** ** ...<.......... SERIALSRV1: OSGBPB: Input: A=0x08, handle=0 (0x0), addr=0xffff3c0e, size=1 (0x1), PTR#=28 (0x1c), 0 data bytes SERIALSRV1: Output: Output: C=false, addr=0xffff3c0e, bytes left=0, PTR#=29, 9 data bytes SERIALSRV1: 00000000: 08 50 44 52 45 41 4d 53 35 ** ** ** ** ** ** ** .PDREAMS5 SERIALSRV1: Response: Type: 13 (0x0d) (RESPONSE_OSGBPB) (23 (0x00000017) byte(s) SERIALSRV1: 00000000: 00 00 17 3c ff ff 00 00 00 00 1d 00 00 00 08 50 ...<...........P SERIALSRV1: 00000010: 44 52 45 41 4d 53 35 ** ** ** ** ** ** ** ** ** DREAMS5 COM4: Sending response 0x0d (RESPONSE_OSGBPB) (+0x0) COM4: Sending 29 bytes response data... COM4: Done one request / response. COM4: Waiting for request... D

…

On Sat, 14 Feb 2026 at 15:59, Tom Seddon ***@***.***> wrote: *tom-seddon* left a comment (tom-seddon/beeblink#209) <#209 (comment)> There's a prerelease that hopefully fixes this now, plus a few other minor things: https://github.com/tom-seddon/beeblink/releases/tag/beeblink-20260214-155120-0eac6ea-prerelease — Reply to this email directly, view it on GitHub <#209 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACDUWGW4DL2PIF6MM3JJMTD4L5A4HAVCNFSM6AAAAACURNA72CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSMBSGA4TONJVGE> . You are receiving this because you commented.Message ID: ***@***.***>

[dominicbeesley]

PS: I meant to add that the hanging appears to happen in both hostfs and normal volumes D On Sun, 22 Feb 2026 at 19:31, Dominic Beesley ***@***.***> wrote:

…

Oops, I just saw this was sitting in my draft folder, I must have forgotten to send. I just got some time to try this out - I get a bit further and my test case in BASIC now passes but the application still hangs...I'll try and get some time to debug that this weekend, it's probably a me thing! I also found I'd had a go at writing a driver for the myelin 1MHz serial port some time ago I've brought it up to date with wip/tom and its on my fork in commit abcaecb I've not done a pull-req yet as its quite bodgy. Would it be ok to include this in the tube_serial driver with the appropriate #definey includes as its almost identical apart from hardware address and the lack of configured/suspend bits Sunday update. I'm still getting random hangs during OSGBPB calls (both reason code 8 and 4) I've not managed to catch it doing this when I've got the logic analyser hooked up unfortunately. It seems to be a 1 in 10ish chance of it hanging. I've now written a quick BASIC test case that provokes it (attached). One thing of note is that if I run with a 65816 as the CPU (instead of the t65 core which emulates a NMOS 6502) it seems to be ok. I would be quite surprised if this turned out to be a bug in the t65 core though as it has been pretty stable for a long time now. I'll try and drag a real beeb out at some point this week and see if that is the same. D Transcript of GBPB COM4: Waiting for request... COM4: Waiting for payload size... COM4: Got request 0x14 (REQUEST_OSGBPB). Waiting for 14 payload bytes... SERIALSRV1: Request: Type: 20 (0x14) (REQUEST_OSGBPB) (14 (0x0000000e) byte(s) SERIALSRV1: 00000000: 08 00 0e 3c ff ff 01 00 00 00 1c 00 00 00 ** ** ...<.......... SERIALSRV1: OSGBPB: Input: A=0x08, handle=0 (0x0), addr=0xffff3c0e, size=1 (0x1), PTR#=28 (0x1c), 0 data bytes SERIALSRV1: Output: Output: C=false, addr=0xffff3c0e, bytes left=0, PTR#=29, 9 data bytes SERIALSRV1: 00000000: 08 50 44 52 45 41 4d 53 35 ** ** ** ** ** ** ** .PDREAMS5 SERIALSRV1: Response: Type: 13 (0x0d) (RESPONSE_OSGBPB) (23 (0x00000017) byte(s) SERIALSRV1: 00000000: 00 00 17 3c ff ff 00 00 00 00 1d 00 00 00 08 50 ...<...........P SERIALSRV1: 00000010: 44 52 45 41 4d 53 35 ** ** ** ** ** ** ** ** ** DREAMS5 COM4: Sending response 0x0d (RESPONSE_OSGBPB) (+0x0) COM4: Sending 29 bytes response data... COM4: Done one request / response. COM4: Waiting for request... D On Sat, 14 Feb 2026 at 15:59, Tom Seddon ***@***.***> wrote: > *tom-seddon* left a comment (tom-seddon/beeblink#209) > <#209 (comment)> > > There's a prerelease that hopefully fixes this now, plus a few other > minor things: > https://github.com/tom-seddon/beeblink/releases/tag/beeblink-20260214-155120-0eac6ea-prerelease > > — > Reply to this email directly, view it on GitHub > <#209 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ACDUWGW4DL2PIF6MM3JJMTD4L5A4HAVCNFSM6AAAAACURNA72CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSMBSGA4TONJVGE> > . > You are receiving this because you commented.Message ID: > ***@***.***> >

[tom-seddon]

If the 1 MHz serial port is that similar to the Tube Serial then it makes sense to reuse the code. Better to have a few .ifs here and there than a big pile of duplicated code I think.

GitHub didn't pass on your attachment for some reason, but if you send it over email then I'll give it a go here and see what I get. I've got a Master 128 + Tube Serial set up at the moment, so easy to try.

OSGBPB 8 with non-zero index hasn't had much testing, but OSGBPB 4 should work ok. Famous last words of course.

[tom-seddon]

(So it doesn't get forgotten: the Tube Serial switches between the internal and external Tube on Master 128, as the Tube Serial I/O is only accessible with external Tube selected. Unnecessary if the I/O port is in page $fc - but harmless, I think, and shouldn't need looking at immediately.)

[dominicbeesley]

Here's the OSGBPB test program again...if that's the attachment that was missing?

…

On Tue, 24 Feb 2026 at 14:36, Tom Seddon ***@***.***> wrote: *tom-seddon* left a comment (tom-seddon/beeblink#209) <#209 (comment)> If the 1 MHz serial port is that similar to the Tube Serial then it makes sense to reuse the code. Better to have a few .ifs here and there than a big pile of duplicated code I think. GitHub didn't pass on your attachment for some reason, but if you send it over email then I'll give it a go here and see what I get. I've got a Master 128 + Tube Serial set up at the moment, so easy to try. OSGBPB 8 with non-zero index hasn't had much testing, but OSGBPB 4 should work ok. Famous last words of course. — Reply to this email directly, view it on GitHub <#209 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACDUWGS42KAULF5TFSY53YD4NROVZAVCNFSM6AAAAACURNA72CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSNJSGQZTSNZVHA> . You are receiving this because you commented.Message ID: ***@***.***>

[dominicbeesley]

I've resent the BASIC test case in a separate email, give me a nudge if it doesn't come through. I'll try and get another look at the ROM code, I'll sprinkle a few .ifs through the tube-serial file and see where I get to, good point about the internal/external switching, I'll keep a lookout for those. D

…

On Tue, 24 Feb 2026 at 14:36, Tom Seddon ***@***.***> wrote: *tom-seddon* left a comment (tom-seddon/beeblink#209) <#209 (comment)> If the 1 MHz serial port is that similar to the Tube Serial then it makes sense to reuse the code. Better to have a few .ifs here and there than a big pile of duplicated code I think. GitHub didn't pass on your attachment for some reason, but if you send it over email then I'll give it a go here and see what I get. I've got a Master 128 + Tube Serial set up at the moment, so easy to try. OSGBPB 8 with non-zero index hasn't had much testing, but OSGBPB 4 should work ok. Famous last words of course. — Reply to this email directly, view it on GitHub <#209 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACDUWGS42KAULF5TFSY53YD4NROVZAVCNFSM6AAAAACURNA72CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSNJSGQZTSNZVHA> . You are receiving this because you commented.Message ID: ***@***.***>

[tom-seddon]

Regarding the internal/external Tube switching: the hope is that you should be able to leave it just as it is, and the only problem will be that transfers will be slower on a Master with internal coprocessor. (Representative numbers here: https://github.com/tom-seddon/beeblink/blob/master/docs/tube_serial_roms.md)

You could also try making is_itu returns A=$00 in the 1 MHz serial case - and then it'll skip the Tube switching and it'll be the same speed in all cases. (Hopefully!) The ROM will include a bit of unused code in this case, but I think I'd rather deal with that separately, as stripping out that stuff is controlled by the compile-time Electron flag, which was silly of me. It'll need a bit of a rethink.

[tom-seddon]

I tried GBPBTEST on my Master 128+Tube Serial, and also under emulation in b2 (using the BeebLink HTTP interface), and, for whatever it's worth, both ran for several minutes without any problems.

Server was running on macOS... I wonder if that makes a difference? I've found the Tube Serial interface to behave pretty consistently (unlike UPURS), but I can try Windows at some point this week.