Wires? Pah.....

[MartinB]

Hi Tom - I’m just a Beeb hobbyist and not from a software or IT background so things like licensing, open/closed source, git(?) etc are all just complete jabberwocky to me. The reason I haven’t ever gone out of my way to make the sources for UPURS public is simply because I didn’t want to encourage tinkering with the core routines which, being cycle-critical, can easily be broken if the person playing doesn’t fully understand why what’s there, is there - if you see what I mean.
I developed the transfer ‘engine’ over many months and once published, it’s now been ‘out there’ for nearly ten years! The user-base runs into literally hundreds that I know of and I would imagine that over the decade, the volume of valuable Acorn data that’s been accurately transferred using UPURS must be mind-boggling!

Anyway, the bottom line is that if someone wants a copy of the sources for genuine reasons, then I’m always perfectly happy to supply them, as was the case with Stephen when he was putting together UPURSFS and Dave when he was I think investigating my reservations about non-FTDI USB serial adapters. I can of course only vouch for my own original sources so if you use a different version then the usage-provenance above is lost but that’s not to say other versions aren’t valid, just that I personally have no means to underwrite any alternative incarnations.

So, if you want my v5.1 sources then just PM me with an email address or, if you can get what you need from github (whatever that is ), then by all means fill your boots....

[tom_seddon]

I used hoglet's routines from UPURSFS in the end, and BeebLink now has UPURS cable support: viewtopic.php?f=53&t=15605

(Max throughput is ~8.5 KBytes/sec - nowhere near as fast as the Tube serial adapter, but I'm still happy with the performance overall. The lack of seek and step times makes a big difference compared to disks!)

--Tom

[aerobaticant]

I've recently been resurrecting my Beebs and have come across UPURS.
Firstly: MartinB, fantastic work!

Initially I had trouble because my Prolific USB to serial cable doesn't handle RTS/CTS as expected by UPURS but having now acquired an FTDI based cable everything is hunky dory.

I have a few observations:
1) When using a *HELP . command no output is produced by the UPURS v5.1R ROM. *HELP UPURS works as expected.

2) If no active serial port is connected by a UPURS cable to the BBC user port then the *UPCFS command hangs indefinitely. Initially I thought I had a problem with my ROM (UPURS UEF FS Ver 1.0 160212). When connected to a serial port there now is a delay of a few seconds. In the video on https://www.retro-kit.co.uk/UPCFS/ there appears to be no perceivable delay at all (Ver v1.0k 021211). Any suggestions?

3) I appreciate that the serial baud rate is probably determined by cycle timing but it might be nice to be able slow it down when using URCFS to give a more cassette-like experience. Maybe not all the way to 1200 bps though!

By the way I have now tested UPURS on two Model Bs (Iss4 and Iss7), and a Master 128.

[MartinB]

Hello and thank-you for the feedback, always appreciated!

When using a *HELP . command no output is produced by the UPURS v5.1R ROM. *HELP UPURS works as expected.

What is *HELP . supposed to do? I must have forgotten over the decades!

If no active serial port is connected by a UPURS cable to the BBC user port then the *UPCFS command hangs indefinitely.

On entry, *UPCFS ensures that there are no spurious characters in the PC output buffer (learned from experience) by 'dragging' them out and in doing that, no hardware connected looks the same as 'busy' hardware and hence the hang. Give that its an easy spot, cost<>benefit told me not to bother getting into top-heavy timers and interrupts so just enjoy the feature....

When connected to a serial port there now is a delay of a few seconds. In the video on https://www.retro-kit.co.uk/UPCFS/ there appears to be no perceivable delay at all (Ver v1.0k 021211). Any suggestions?

The delay is the buffer-clearing I mentioned earlier and you should see it, Paul may have had a cheeky development version for his video, despite what the rom title might say. (He and a few others were at the coal face of my development release testing... )

I appreciate that the serial baud rate is probably determined by cycle timing but it might be nice to be able slow it down when using UPCFS to give a more cassette-like experience. Maybe not all the way to 1200 bps though!

First time I've been asked to slow it down! Buy a tape deck maybe....?

[sweh]

What is *HELP . supposed to do? I must have forgotten over the decades!

The "." is the traditional "truncate" character, same as with * commands. So on a standard beeb with DFS "*HELP U." would cause the "UTILS" help to display.

Take this to the logical conclusion and "*HELP ." should cause all help to be displayed.

Of course it never worked properly. eg with DFS1.2 ROM it only caused the "DFS" help to be displayed and the "UTILS" one got skipped!

[MartinB]

Thanks Stephen, I do remember now and tbh, I never did think it had much value because why on earth would you want simultaneous help info from every rom with it all just scrolling past...?

So Ant, the reason UPURS doesn't respond to *HELP . is because UPURS thinks that command switch is silly.....

(....and Ant, if you're now officially a MartinB follower and you like hardware tinkering, have a look at my I2C rom..... )

[sweh]

I must admit my ROM _does_ respond... but more by luck than judgement. The "abbreviated request" routine is called even if no previous characters were hit.

Code: Select all

.help   LDA (CLI_NAME_VEC),Y    \ Service 9 - *HELP
        CMP #13
        BNE nhelp2
        JMP help2
.nhelp2
        \ User specified something with *HELP; let's see if he wants us
        TYA
        PHA
        LDX #&FF
        DEY
.helpfl INX             \ Compare user string to our name
        INY
        LDA (CLI_NAME_VEC),Y
        AND #223
        CMP helpm2,X
        BNE nohelp      \ didn't match?  Hmm.
        CMP #13
        BNE helpfl      \ Hey, we reached the end of our name.  Match!
        JMP mrhlp
.nohelp LDA (CLI_NAME_VEC),Y
        CMP #'.'        \ Second chance; maybe users wanted an abbrev name
        BEQ mrhlp
        PLA             \ Nope.  Not for us.  Bye, now!
        TAY
        LDA #9
        RTS

.mrhlp  LDY #&FF        \ Display more help
....

So the "nohelp" testing of an abbreviated name would match even if the whole string was just "."

[tom_seddon]

A very interesting discussion! I'd never thought to try "*HELP .".

I suspect BeebLink won't respond at all. There's a special case for the first char, so it specifically won't match a single . against anything: https://github.com/tom-seddon/beeblink/ ... k.s65#L957

Even if I fix that bit, it still assumes you're only printing out help for one subject at a time, rather than trying each subject name in turn and seeing if that matches. I did it this way, because the help routine can reuse the general star command parsing... but thanks to this discussion, I realise this is wrong. These two cases are not the same, and need to be treated differently. *HELP XXX gives help for all ROMs that recognise XXX - so clearly the rules are that help must be supplied for all matches!

--Tom

[aerobaticant]

Thanks for the replies.

I used *HELP . partly because I was used to it on the Archimedes

First time I've been asked to slow it down! Buy a tape deck maybe....?

I do have an original BBC Micro cassette deck, I just thought that as UPCFS emulates the cassette filing system I thought it might be interesting to be able to see the filenames and block counts while loading. At 115200 if you blink you miss it! I suppose there's always PlayUEF.

(....and Ant, if you're now officially a MartinB follower and you like hardware tinkering, have a look at my I2C rom..... )

.... interesting. I2C on a BBC.

[tom_seddon]

I've been having some issues with UPURS on my laptops I've got the UPURS 5.1R ROM, a cable from Martin, and a genuine FTDI USB serial adapter. I'm using Windows 10 x64 with the 2.12.28.0 driver and Hercules, as recommended in the UPURS manual, but I get the same results on macOS Big Sur with the latest FTDI VCP driver and CoolTerm. Laptops are a 13" Macbook Pro from 2015, and a 15" Macbook Pro from 2014 - same results from both.

What I'm trying to do: write a 80 track SSD disk image (Master 128 Elite, to be precise) to a disk using *UPSSD.

What happens: transfer gets to 184840/204800 bytes, UPURS on the Beeb stops with a "Track No. >79" error, and the resulting disk doesn't work - it craps out with an "at line 130" error when booted. Probably not surprisingy, looking at an image of it, as some of the tracks are bogus: they've got 1 valid byte, then they're full of 0s. I didn't check the entire image, but this affects at least track 6 (offset $3c00) and track 13 ($8200).

Any suggestions very welcome.

(I was moved to try this after having some problems with UPURS BeebLink, something I'm not going to think about until I have the official UPUPRS transfers working...)

--Tom

P.S. the attached zip contains m128eltf.ssd (the ssd file I was trying to write, and m128eltf.upurs.ssd (an ssd of what I get from doing *UPSSD 0 and following the instructions to put m128eltf.ssd on the disk). m128eltf.ssd works if I write it to a disk using BeebLink, so it feels like there's nothing obviously wrong with the disk image.

[MartinB]

EDIT : I misread your post I think. You're not trying to copy a disc (?), you are writing a physical disc from an existing image so I need to rethink what might be going on. Very quickly though, what you're seeing implies that the image is not ssd in my language (or that of UPURS), but is actually a >20480 byte double-sided image using the ssd 'sequential-sided' terminology rather than the 'single-sided' meaning. Perhaps as a quick test, try renaming the image extension to dsd (although to be fair, UPURS doesn’t care what an image is called) and use *UPDSD with a DFS pre-formatted double-sided 80T disc.

Failing anything else, I'm sure myself and others have more versions of Elite saved in UPURS-compatible ssd & dsd images than you can shake a crooked stick at so if you're still struggling, shout up and someone will oblige...

Hi Tom - I presume from what you’re saying that the disc is actually an intentionally protected type in that it has some tracks written in a way that will cause certain ‘normal’ DFS (hence OSWORD &7F) operations to fail and thus prevent copying. Sometimes, depending on the protection method used, UPURS will succeed despite such techniques but beyond a certain level of trickery, it too will fail.
One possibility is to try forcing UPURS to unconditionally produce an 80 track (10x256 byte sector) image using the ‘I8’ command line option which divorces the image reading process from the DFS directory information present on the disc. Any reported errors are for user information only, UPURS will ignore these if physically possible and continue to produce an image.
If this does produce an image (though it may still not succeed), whether or not the program(s) on the disc subsequently work properly will depend on whether the protected tracks are just present for anti-copying purposes or whether they are always checked at runtime by the programs in order to validate the disc in realtime. If the latter, then forcing an image with I8 is unlikely to be of use but often, it can overcome the copying of protected or damaged discs. Other than that, I don’t think UPURS can be used in this instance.

[tom_seddon]

EDIT : I misread your post I think. You're not trying to copy a disc (?), you are writing a physical disc from an existing image so I need to rethink what might be going on. Very quickly though, what you're seeing implies that the image is not ssd in my language (or that of UPURS), but is actually a >20480 byte double-sided image using the ssd 'sequential-sided' terminology rather than the 'single-sided' meaning. Perhaps as a quick test, try renaming the image extension to dsd (although to be fair, UPURS doesn’t care what an image is called) and use *UPDSD with a DFS pre-formatted double-sided 80T disc.

Failing anything else, I'm sure myself and others have more versions of Elite saved in UPURS-compatible ssd & dsd images than you can shake a crooked stick at so if you're still struggling, shout up and someone will oblige...

Thanks for the reply. The exact disk image isn't really important - I picked Master/Tube Elite simply because it's the largest one I happened to have to hand, at 179,456 bytes (70 tracks + 1 sector). All I'm interested in is figuring out why UPURS isn't working, as I'm hopeful this'll shed some light on why I'm having difficulties with BeebLink.

After a bit more investigation, *UPXSSD does seem to work OK, producing a .ssd file with the expected contents. But *UPSSD fails to write it back correctly.

I've done some more experiments today, this time with an original Micro User disk, definitely unprotected and definitely single sided (as side 2 appears to be unformatted).

I used *UPXSSD to get a known good copy of the original disk, matching the one I got using BeebLink. This is tmu.91-06.good.ssd in the attached zip. (The file contents also match the 8bs copy, though for some reason it isn't bit identical - the files are in a different order - I wonder how many subscribers they had at that point? Maybe they did the disks by hand. Anyway, this ssd looks good.)

I then used *UPSSD to write this copy back to another disk, producing a disk that didn't work.

I then used *UPXSSD to get a copy of this non-working disk for investigation - tmu.91-06.bad.ssd in the attached zip.

Comparing both images, the bad parts, which consist of 1 valid byte then 2,559 0s, are at:

0x3c00-0x45ff
0x8200-0x8bff
0xc800-0xd1ff

Valid data then appears to follow, as if the 0s were just inserted into the stream and subsequent data was offset - so the data at 0x4600-0x81ff in the bad copy, for example, is what's at 0x3c00-0x77ff in the good copy. If I strip out the bad regions then what's left matches the start of the good copy.

I'll fiddle around with this a bit more and see if I can get any further useful info.

--Tom

[MartinB]

Hi again Tom - sorry for the slow reply, I didn't currently have any working hardware set up for testing and clearly, there was only one way to proceed with this so, in the first instance, I had to get some kit configured. That done and cutting to the chase, I've downloaded your test sample tmu ssd and iterated several times the process of PC ssd image>UPSSD Beeb Disc>UPXSSD PC ssd image>HxD_binary_compare_with_start_image and in all cases, the final image is identical to the starting image. My only quick guess therefore is that somewhere you perhaps have a handshaking issue or a faulty USB serial adaptor or some PC USB driver issue (I’m certainly no ninja there) but I'm afraid I just can't repeat the problem. (...and to be honest, if you had discovered an UPURS bug of this ilk, it would have been so fundamental that hundreds of users over the last goodness knows how many years would certainly have got there before you.)

btw - my config is a Beeb B with 1772 FDC & DFS 2.26, real floppy drives and media, UPURS-in-rom v5.1R, MS Windows 7, Hercules terminal and finally, FTDI serial adaptor from Tronisoft as tediously promoted by me.

[tom_seddon]

btw - my config is a Beeb B with 1772 FDC & DFS 2.26, real floppy drives and media, UPURS-in-rom v5.1R, MS Windows 7, Hercules terminal and finally, FTDI serial adaptor from Tronisoft as tediously promoted by me.

Thanks for trying it out! I was using my Master before, but I've now tried it with a BBC setup similar to yours (BBC B, 1770, DFS 2.26, real floppy drive, UPURS 5.1R), and I get the same bad results I was getting before. I'm using Windows 10 + Hercules, and it looks like my serial adapter came from tronisoft, so it's hopefully the genuine FTDI one that it claims to be. But I note that my FTDI Windows driver is 2.12.36.4, a version rather newer than the recommended one - so perhaps they've changed something? Who knows.

I should probably at least order another USB serial adapter and see if that makes a difference, then take it from there.

I'll post here if I find anything remotely interesting.

--Tom

[MartinB]

Looking at the data incident addresses you’ve provided, they actually all fall on the UPURS 6-track pre-write buffer boundary (with some apparent error perturbation) and the interesting thing therefore is that this does, as I alluded to previously, further point the finger at a handshaking. UPURS releases CTS to allow the PC to send data and at the nominal buffer-full point (6*2560 bytes), UPURS de-asserts CTS again to pause the byte flow whilst the buffered data is written to Beeb disc. One thing I discovered during development, and it is discussed in the thread somewhere, is that these USB-RS232 devices do exhibit a degree of overrun after the incoming de-assertion of CTS and actually, I further entered into discussions with FTDI regarding the behaviour of their chipset implementation in this respect. I can’t remember the full story but they did at some point update the drivers with some tweak that tightened the overrun such that at worst, it was only one or two bytes and UPURS is robustly configured to deal with more than this, around ten I think without checking. (By overrun, I mean the number of bytes that are sent from the PC via the serial adaptor after CTS has been set to STOP by UPURS.)
Anyway, the reason for all that waffling is just to set the scene for the importance of handshaking with these devices (I did actually find cheaper non-FTDI types that had no credible handshaking implemented) and to support a postulation about your suffering some adverse effect in relation to this area. I wonder if some W10 aspect of USB device support or the FTDI driver itself is not handling CTS correctly such that perhaps the extra zeroes you are seeing are somehow being erroneously inserted when CTS is toggled? I’m only speculating and have no great knowledge of these PC driver interfaces other than to note that I had to account for the overrun behaviour as I’ve described above.