Wires? Pah.....

[guddler]

Thanks guys, I’ll have a look at this at some point today and report back in the scramble thread

[MartinB]

I think tricky has just fessed-up on the Scramble thread to a possible glitch which might well explain why we both experienced some crashing. I also therefore strongly suspect that your UPURS vs DC USB approach was perhaps a red herring but we’ll see how you get on with tricky’s RC5 build if you get time to transfer it to floppy using UPURS.

[guddler]

OK, found the problem. Well, I assume it's causing the failure to start in Scramble anyway! The last incomplete block of data (sector? track? don't know) is not making it to the floppy for me. See screenshot @ 0x4600. On the left is the image that I transferred over UPURS to floppy, then exported to USB, on the right the image that I manually copied to USB. So basically, as downloaded from *.

SO, assuming that there is nothing wrong with UPURS itself (totally happy to accept that, given this has been working for years before I came along), I now need to work out if it is on my Master side, my Mac side or in between (my cable).

Cable:
Am I safe to assume that I would not be getting this far if my cable was not wired correctly? Bear in mind I can write a much larger image such as White Light and it works fine.

[EDIT] Of note, I always have to end the transfer by pressing a key. It never ends by itself however I thought this was normal from the message on the screen.

Master:
I am using the v5 ROM image from here:
https://www.retro-kit.co.uk/user/custom ... elease.zip

Mac:
I was already thinking that I might write my own tool to transfer files. Might be time to do so.

[tricky]

Maybe as it is supposed to be a disk image, it is only transferring whole sectors (256 bytes) or possibly waiting to read a batch of 256 bytes before sending.
Either way, beebasm could pad to a whole sector without bloating things too much or it could be padded afterwards.
As there are probably many "partial" disc images out there, maybe if this is the problem, UPURS could be tweaked.

[MartinB]

SO, assuming that there is nothing wrong with UPURS itself (totally happy to accept that, given this has been working for years before I came along), I now need to work out if it is on my Master side, my Mac side or in between (my cable).

Well, I'll still have a look tonight but I use UPURS all the time for transferring small images, typically 16k roms rather than ssd's but the principal is the same. What I don't have is anything other than Windows so if its a Mac issue, I can't help.

As there are probably many "partial" disc images out there, maybe if this is the problem, UPURS could be tweaked.

It already does this! It uses auto-padding to ensure the last transferred track is a full one but what it can't do is compensate if the host doesn't actually send the residual bytes. However, I shall again have a look....

[guddler]

Mulling this one over we should be able to rule out anything Mac specific as it also fails under Linux using the setup from the manual.

I’ll double check that and double check my cable wiring.

[MartinB]

Stop looking Martin - I've reproduced it under Windows! I don't know why its happening yet, I won't get chance to investigate until later but I do understand why I was getting confused though and that's because of the extended (padded) ssd I posted last night. That test image does transfer ok and thus writes the correct bytes to the Scramble physical sectors on the disc such that when I then go back to the failure case (tricky's original ssd), even though this falls short in the transfer, the missing bytes are already present on the disc and in precisely the right physical locations meaning second time around, it appears to work fine

Bottom line, it does indeed look as if you've found a bug in UPURS after all these years of its being out there! I'd like to thank you for this but somehow I just won't....

EDIT : Just read your posts in the Scramble thread and you've already reached the same conclusion about it not working first time but then working second time around after a different successful method has been used with the same physical disc.


.

[guddler]

No problem! Honestly, I'm just glad I'm not losing the plot because there are days where I chase my tail in my day job and that can easily follow over into the evenings!

It might have helped if I had read your mail from last night more thoroughly but I just glanced at my phone while watching a film. Sorry 'bout that. The reality is, it sounds like we both went through exactly the same thing, just in different ways. I had the Eureka moment when I realised that it started to fail after the format.

I think I'm still going to write something a bit more slimmed down to send files from the Mac. Using CoolTerm, as nice as it is seems a bit of a faff to me. I know I already had some code from around the time this thread started that communicated over the Prolific adapter but I think I may have discarded it as I only ever got the serial comms working and never finished the rest of the project (I was writing a Mac program for the Data I/O programmer that I was using at the time).

[MartinB]

I've only just been saying that I was going to fix a few niggles in 5.1 so this will give me some compelling motivation to issue an update sooner rather than later. Apart from today's transfer bug that I've yet to diagnose, there's an error reported by Colin Mcd in the UPLOAD assist dialogue where it tells you how to *SAVE the last load - the prompted range is out by one byte. Also, there's the niggle I recently mentioned to other Martin where when using UPLOAD, the keypress-to-begin transfer often also gets immediately read as the keypress-to-end and so you just end up with a 'No Rx Data' abort. Lastly, I think I might need to put a blank line in the UPURS *HELP rom banner as Ken Lowe recently pointed out in relation to the I2C rom. Has anyone come across anything else that I've forgotten?

[Elminster]

:
I think I'm still going to write something a bit more slimmed down to send files from the Mac. Using CoolTerm, as nice as it is seems a bit of a faff to me.

What did you have in mind, as not sure what you mean by faff, seems pretty simple to me. But then I always have coolterm running. Always found some thing with upurs, freefi232 testing, rc2014 or swtpc stuff. Or are you thinking of perhaps some sort of finder addon so you can right click and send a file over UPURS? I could see where that would be useful.

[guddler]

I actually had in mind something as simple as "upput <fname>" from the command line. But yeah, maybe a finder integrated service entry, maybe a "drop a file onto an icon in the dock" or whatever. Anything more complicated then "upget <fname>" starts to get into the realms of UI's and stuff I guess.

And some of it is more "just because..."

[1024MAK]

On my Linux System, I have a short cut (link) set-up to fire up CoolTerm. Then it’s just a case of opening the channel, selecting the file and clicking send

I also use CoolTerm for sending EPROM images to one of my EPROM programmers.

Mark

[guddler]

Then it’s just a case of opening the channel, selecting the file and clicking send

Like I say, that sounds like a lot of faffing about, especially if perhaps I wanted to do it as part of a build script. If I've only got one USB serial cable connected and I know what file I want to send then why do anything other than just tell the system to get on with it and let it connect and send the file for me?

Anyway, don't worry about what I'm up to

[MartinB]

UPURS 5.1 Banner.jpg (12.65 KiB) Viewed 7407 times

The attached zip contains the following UPURS v5.1 update files :

• UPURS 5.1R 16k binary rom image
• UPURS 5.1 DFS ssd containing disc-based versions of the utilities and a further SWR-loadable copy of the rom image
• UPURS 5.1 User Guide (unchanged from 5.0 other than version 5.1 references)

There are no feature updates in v5.1 but the following bugs and anomalies are addressed :

• For certain ssd images, UPSSD not writing the final track to the destination Beeb disc
• UPLOAD file save dialogue indicating one byte too few
• UPLOAD (rom version) immediately aborting due to inadequate key de-bounce
• UPLOAD freezing Beeb after a load
• Missing blank line in *HELP header response

Thanks to Martin (guddler) and Colin (CMcDougall) for bug reports.

Further details of UPURS can be found at it's support home on Paul Vernon's (paulv) excellent Retro-Kit site.

UPURS 5.1 Rom,Disc & Manual.zip

(2.43 MiB) Downloaded 97 times

[paulv]

Cool, I've updated my UPURS page to reflect the updates too

Paul

[MartinB]

Ahh, thanks Paul - you're a star....

I was going to contact you via email because I didn't want to just assume you had the personal bandwidth to deal with the update. Anyway, you have and that's great!

I'll update my post above later to add the standard UPURS Retro-Kit link.

Ta

[paulv]

Ahh, thanks Paul - you're a star....

I was going to contact you via email because I didn't want to just assume you had the personal bandwidth to deal with the update. Anyway, you have and that's great!

I'll update my post above later to add the standard UPURS Retro-Kit link.

Ta

No problems. Bandwidth is getting back to much more normal levels for me these days although I'm still restricted in what I can carry due to a reliance on crutches so physical issues will continue to be in play for the long term.

Things are coming out of storage slowly and I'm engaging more on stardot again which is all good

Paul

[guddler]

Hi Martin - thanks for the updated tools. For the most part all checks out fine here, in particular the SSD that wasn't working before is now working.

Hate to be the bearer of bad news but the new-line on the end of the help is still not OK on a Master however.

If I just do *HELP there is no newline at the end at all, the cursor is immediately after the R of "5.1R". If I specifically do *HELP UPURS then there is a newline but it only backs up to the previous tab indent, not to the beginning of the line.

Do you need a screenshot? I appreciate that may not make a terrible amount of sense!

MOS 3.2 and 3.5. Although I have OS1.2 "compatibility" I don't really know how to use it and don't have the Dual MOS Manual to hand.

[MartinB]

Hate to be the bearer of bad news but the new-line on the end of the help is still not OK on a Master however.

Actually, looking at it now on a Master (and a Beeb), the recent addition is working fine but I only added a LF before the UPURS 5.1R text and not after. It looks perhaps as if a LF is expected after too but I don't do that and this hasn't changed since v5.0 which does the same if you try it.

I could never find any accepted protocol details documented for this so I've been making it up as I go along! It was only recently that Ken Lowe suggested adding the preceding LF in relation to my I2C rom so I applied this to UPURS too since I was doing the update.

Anyway, thanks for noticing Martin but tbh, the bottom line is that I'm not going to do anything about it unless there's another bug-fix update required. It has always been like that for all versions and I've apparently improved things with the recent preceding LF so just think yourself lucky!

[1024MAK]

bug_crawls_on_screen.gif (220.54 KiB) Viewed 7310 times

[MartinB]

So we all know for future reference when writing sideways roms, can someone point us to the official documentation of how a rom is to behave when responding to an 09 *HELP call? I don’t mean the rom header format, that is well documented and my roms are compliant with the specification. I’m referring to something that explicitly says you should issue a <cr><lf> before and maybe after (?) the rom title string - I’ve never been able to find anything. Thanks.



.

[sweh]

There never was an official standard, as far as I can tell. There's a lot of "best practices", and JGH has documented a number of them. But these are guidelines, rather than rules.

In my mind, for the Beeb world, if it's not in the UG then it's not a rule... if it's in the AUG then it's a strong recommendation, otherwise it's a guideline

BITD I basically did it by trial and error, until I got results that looked right. I know I've seem commercial ROMs that didn't match expectations!

And, indeed, for my manager ROM

Code: Select all

.helpm  EQUB 13
        EQUS "RAM Manager 2.0"
        EQUB 13
        EQUS "  "

[MartinB]

Thanks Stephen - I used to do just that, i.e. 'frame' the title string with <cr>'s, but subsequently, I kept reading that the 'correct' sideways rom header format is to frame the title with nulls ($00) and I've even seen JGH get shouty about this. What that means though is that the individual rom help code does then have to fully mange the print format itself and it looks as if it will have to explicitly JSR OSNEWL before and after printing the title string. The latter seems to be a strange way of doing things to me though - I would have mandated the framing with zeroes, but then, for the *HELP function, I would have put the common handler code in the OS and used this to print out the title string for each discovered rom such that the OS remains in charge of the screen format. As it stands, each rom has to hold its own *HELP code and and each has to replicate the others in terms of screen output. Seems like a flawed concept to me if you want some guaranteed consistency.....


.

[MartinB]

Actually Stephen, I've just checked my notes and you do still have to include the $00 bytes either side of the title or the rom simply isn't recognised by the OS. You can still include a <cr> at any point in the title to avoid having to perform an explicit JSR OSNEWL but the null framing is still required.

So.....

@ Martin (guddler) or indeed anyone else : If you hate the look of the help entry and don't mind the 'UPURS 5.1R' becoming just 'UPURS 5.1', you can modify one byte of your 5.1 rom image to lose the 'R' in the title and replace it with a line feed which will sort it out for you. At image offset $0012 (installed sideways rom address $8012), overwrite the existing $52 with $0D, re-save, and that will sort it until I next do an update when I'll formally change the header.

[guddler]

Well, go on then, I guess I may as well

Honestly, it doesn't desperately bother me but if that's all I need to do then I shall do it later

[MartinB]

If you hate the look of the help entry.....

Sorry Martin, I was being unnecessarily flippant saying that - any issue, even cosmetic, is my bad and it’s down to me to sort it but having already put a good two weeks-worth of evenings into preparing the 5.1 release, I guess I wasn’t very being very receptive and was just trying to rationalise things...

Anyway, do the poke and all will be well whilst I crack on with my I2C RTC project. Once that’s up and running, I’ll revisit UPURS and sort the 5.1 rom header.

Thanks as always for the feedback....

[MartinB]

On another thread, John (jms2) mentioned using UPURS on the Electron with his Peg which has reminded me that I need to port the recent Beeb 5.1 updates into the equivalent Elk version. I think that’ll become Elk 1.1E then so just in the off chance that anyone has noticed any additional quirks on the Elk version, shout up in the next few days and I’ll include anything in the update. Ta

[MartinB]

From another thread.....

There’s a later version of that post actually.... clicky here

Ordered!

Go on then, Martin. You’ve worn me down.

How do I get hold of one of your UPURS kits?

If Martin can't put one together for you (?) pm me as I have a PCB and possibly all the ICs needed.

Dave H

I'm not sure he meant UPURS for an Elk? (I presume you [Dave] are talking about an EUP?)

I was assuming he meant a Beeb cable and rom....

Which did you mean Chet?

[lurkio]

I was assuming he meant a Beeb cable and rom....

Which did you mean Chet?

Yes, I meant a Beeb cable and ROM.

[daveejhitchins]

Ah! Over to you, Martin . . . . I keep forgetting that there are other machines in the family

Dave H