Wires? Pah.....

[Elminster]

Better just to keep the UPURS one and throw the other 4 away.

Would make using my SWTPC, RC2014, ICE-T, Logic Analysers, etc. a bit tricky.

[Back2skooldaze]

Thank you Martin for the *UPCFS games list/folder that's fantastic! I've got the multi OS on the Master so i tend to leave it in BBC model B mode as much as i can for games.

Super speedy loading

[MartinB]

No worries Andrew

It’s not an exhaustive collection btw, it’s just the positive ones that we tested out of the hundreds out there. Somewhere on Paul V’s Retro-Kit site there is a go/no-go list but again, it’s not exhaustive across the Acorn collections. Don’t forget though, at the end of the day UPCFS was just a ‘bonus feature’ of the UPURS suite so it isn’t trying to compete with proper filing systems. Still, it isn’t too shabby even so...

Would make using my SWTPC, RC2014, ICE-T, Logic Analysers, etc. a bit tricky.

I don’t know what all those are but UPURS has the best acronym....

[guddler]

[EDIT] Ignore me - lack of sleep! I've already got a thread and clearly I was intending to go UPURS to RAM FS.

Would be much better if ADFS were supported. Would save a lot of dicking about to get files onto the CF HDD.

[guddler]

Made my cable earlier today (yesterday I guess!)

Difficult to tell if it’s the prolific cable or my very hurried Mac setup or what but if I try to upload an ssd either to RamFS or direct to dfs floppy I get ‘Write Error’. If I try to load to sideways ram I get stuff spewed all over the screen and then eventually a crash. Haven’t finished reading the docs or really investigated yet.

Will have a play later if I get the chance, possibly from Linux this time just to rule out my Mac setup.

FTDI cable should arrive next week.

Finally, now I’ve got the UPURS rom loaded via USB I can see what it does in more detail and really don’t need adfs. I only use that for CF and not floppies so DFS is fine as long as RamFS works.

[MartinB]

if I try to upload an ssd either to RamFS or direct to dfs floppy I get ‘Write Error’.

I don't have RamFS but the two key points here are (1), in the case of real floppies, the destination disc must be pre-formatted under DFS and must be write-enabled (does formatting and WP apply to RamFS?) and (2), I did design UPURS for use with real floppies but it is actually hardware-agnostic provided the characteristics of the destination media are predicated on DFS such that the device read/write control responds to OSWORD $7F, is based on the ssd/dsd construct and has tracks consisting of 10 sectors of 256 bytes each.

If I try to load to sideways ram I get stuff spewed all over the screen and then eventually a crash.

You can load data to a specific sideways ram bank or you can load data directly to anywhere in the destination Beeb's memory map. It sounds as if you are perhaps inadvertently doing the latter and hence hitting screen and then system memory? (Some users do employ this deliberately to view Beeb screen-dump images stored on PC.)

The two syntax are....

*UPLOAD R<id> where <id> is the single digit 0-F hex id of the destination SWR bank

*UPLOAD <addr> where <addr> is the 4-digit hex start address in Beeb memory (no 'safety' validation of the address is carried out by UPURS)


(Note that there is one irritating trait, bug if you like, that I intend to fix this winter with UPLOAD-related use and this concerns the 'key press to end transfer' behaviour. I changed to the latter functionality to pander to legacy PC serial ports [long story] but I forget to de-bounce the key press so when typing a UPLOAD command, you have to give a very light tap on the Return key or you will annoyingly start and end the transfer all in the one press.... )

[Elminster]

Will have a play later if I get the chance, possibly from Linux this time just to rule out my Mac setup.

F it is any help I use coolterm on the Mac, and that works fine with UPURS.

[guddler]

F it is any help I use coolterm on the Mac, and that works fine with UPURS.

Thank you! Yes, that got it. I did load CoolTerm up as I've used it in the past but couldn't remember how to send a binary file. I just did send as text and it worked fine. So fast incidentally I didn't think it could possibly have completed!!

with my trusty Prolific 2303 cable by the way

Previously I was just using "cp <FILE> /dev/cu.usbserial" from the command line having configured the null modem cable in network settings. I know there is a way to configure the port properly from the command line as I've done it with my Amiga. Will have to try and remember how.

Sadly, RamFS does not work. I just get "Bad String" and the beeb side of things exits and locks up. I need to try *RAMTRAP as JGH mentioned in reply to my original enquiry. Fingers crossed.

[MartinB]

I don’t have a DC as I said but from reading the chatter, does DTRAP perhaps redirect OSWORD $7F to the DC virtual discs? That could be bahoolliocks of course....

(Prolific usually describes the number of errors you’ll get so ‘trusty’ or not, be sure to use the FTDI when it arrives... )


.

[guddler]

Yeah I will.

It looks like RamFS will eventually work. Either with DTRAP and disk versions of UPURS or RAMTRAP (not tried yet) but it looks like I'm sending crap at the moment. Not entirely crap as the disk dirs look fine. At this stage don't know if it's the prolific cable or my setup. Probably won't know until the FTDI one turns up.

@Ellminster - how are you sending binary files with Coolterm? All I'm seeing (and using) are options for sending text and text files. The help is a bit unclear about whether this will send raw binary if that is what you give it? Do I need to tweak any settings?

[Elminster]

Just use the send as a text file for everything. Works fine. Don’t remember changing any settings, think it just works. If you get issues I will double check setting, probably tomorrow as knocking down some sheds and putting them in skip at the moment.

[guddler]

Don't worry, that's good enough, thanks.

I'm just going to go through the setup from my Linux PC and if that doesn't work then I think it's safe to say that's it's nothing to do with the Mac and all about the Prolific cable, which, let's face it I was warned about from the start

[Elminster]

Don't worry, that's good enough, thanks.

I'm just going to go through the setup from my Linux PC and if that doesn't work then I think it's safe to say that's it's nothing to do with the Mac and all about the Prolific cable, which, let's face it I was warned about from the start

I did the same, probably 50 screens back, in the end I gave in and went with the new cable and it worked fine. (After I turned of transmission delay which I have on when talking to my SWTPC 6800 which suffers buffer over run)

[guddler]

I've run out of time right now and will have to come back to it. I'm not entirely convinced that the cable is at fault. I can happily transfer a ROM image from a sideways ram bank to the PC (Linux now) and aside from the padding at the end differing, the MD5 sums match. The ROM already on the PC was padded with FF at the end, the one received was padded with 00. Don't know why but after changing them so they match, so then did the MD5's.

I've already also transferred the ADEPlus ROM from PC (Mac) to Master and was able to start ADE, which rather unscientifically but maybe not exhaustively, I assume to mean that the transfer was OK. I guess the ROM could be corrupt somewhere still?

This evening I'll get a few more SSDs to play with and see if I can get an SSD to work. So far the ones I've tried don't seem to transfer properly but ROMs do. Maybe that will mean more to Martin than it does me. Ie, maybe there is a good reason for that - file systems or something?

[EDIT] Something I am pleased about is that it looks like I got the UPURS cable right first time which makes a change for me!

[MartinB]

I don't have anything Linux but my good friends from back in the UPURS development days always recommended Cutecom whose setup and use is fully described in the UPURS User Guide.

[guddler]

All the activity noted as Linux in the previous post was using Cutecom in accordance with the manual.

[MartinB]

Ok

When you get more time then, no rush at all, if you could describe in a bit more detail any issues or queries you have then they can definitely be sorted or explained.

[1024MAK]

If you are getting data errors, they are much more likely with disk images rather than ROM images, simply due to the size.

Most people leave unused bytes in EPROMs/EEPROMs as 0xFF. Because that is the value that a byte goes to when a EPROM or EEPROM goes to when erased. So it saves a programmer (a burner, a device not a human!) from wasting time changing the state of unused memory locations. It also enables these locations to be programmed to different values at a later stage.

Mark

[Elminster]

All the activity noted as Linux in the previous post was using Cutecom in accordance with the manual.

As an aside.

You can also get Coolterm on Linux. I never really got on with cutecom. I usually use Screen for cli or coolterm for gui.

[guddler]

Where CoolTerm is proving useful and i may well try it on Linux is that it displays the status of the control lines in realtime. Of particular note is that RTS is permanently set on the PL2303 adapter. Until I have something to compare it to I don't know if this is abnormal or not.

Incidentally, on linux you can use

Code: Select all

stty -F 115200 cs8 -cstopb -parenb raw crtscts

and then just

Code: Select all

cp <file> /dev/ttyUSB0

You should be able to do the same or very similar on Mac. I'm not guaranteeing that they are the exact correct options to stty until I have a proven working setup.

[MartinB]

Of particular note is that RTS is permanently set on the PL2303 adapter. Until I have something to compare it to I don't know if this is abnormal or not.

In two matched systems running at band-edge, then no, both RTS and CTS would be active. In the case of a Beeb vs a PC, when UPURS is transferring data to the PC rather than receiving (e.g. UPXSSD or UPXROM etc.), RTS is the authority from the PC for the Beeb to send so if the PC is super quick and processes the incoming volume of data far faster than the Beeb can send (which is likely), then arguably you might not see RTS toggling, especially with graphical representations. I have encountered adaptors where the handshaking doesn't toggle simply because it isn't implemented properly but in these cases, you do get data transfer errors.

On the more general subject of data errors, whatever you do with UPURS, you should get zero errors, always! My testing went on for months and I transferred literally gigabytes of data in automated continuous 24/7 transfers and in addition, over the years, there are over a hundred users (I've lost count), all of whom experience zero transfer errors on a correctly configured set-up.

So, the bottom line is that if you try everything that UPURS offers and everything works, then your adaptor is probably ok but as I tediously state, the biggest enemy of UPURS is sub-standard handshaking and personally, I would only certify the performance of UPURS if it was being used with an FTDI-based adaptor....

[guddler]

There's little point in me trying to get any further until the FTDI adapter arrives. I've no idea if it's even been dispatched yet.

[guddler]

OK, so it only took a week and an email to ask where it was for them to finally dispatch the FTDI cable. Not surprisingly everything now works. It looks like the specific problem with the Prolific cable is it not asserting RTS properly. At least in my case anyway, maybe they're not all the same as I know there are a bunch of different versions and I've had mine years.

After a bit of messing about I've arrived at a setup where RamFS plays nicely as well...

As we know *DTRAP disables all other ROMs so that was no good. *RAMTRAP which doesn't disable the other ROMs did not work, it just corrupted the RAM quite royally resulting in a power cycle being required. I eventually settled on importing the v4 UPURS SSD image to RamFS disk, then copying the UPSSD, UPDSD, UPXSSD and UPXDSD commands to the DC's built in small non-volatile drive (drive 4 in RAM) and moved them to the % folder which is mapped to *Lib.

The result is that I can enable RamFS. Enable DTRAP and have the UPSSD/DSD etc. commands accessible just as I would from ROM. They seem to work just fine this way (I loaded White Light across serial and played it). Obviously from here I can *EXPORT the SSD to the USB stick which is now permanently inside the Master. Clearly I don't need to copy the other UPURS commands to the NVDrive since they work fine from ROM.

I have yet to explore the other delights of UPURS but it's finally nice to be able to stop faffing about with USB sticks backwards and forwards

My next exploration is moving RamFS and possibly UPURS into a custom Master ROM since I now have a dual MOS (actually 8x MOS) that uses a standard EPROM.

[MartinB]

Well done Martin (you, not me).

Happy days....


(Don't know what went wrong with Tronisoft btw, they're normally pretty good.)

[guddler]

Before I go down the rabbit hole that is spending hours trying to work out why I can't transfer this SSD over UPURS, can anyone else successfully do so?

(Tricky's latest scramble version - RC4)
viewtopic.php?f=57&t=14988&start=90#p218181

I've tried Mac and Linux using FTDI cable. If I transfer the SSD over UPURS to DFS Disk (not RamFS) then it is VERY quick / small, and after the loader where you select your key layout the screen just goes blank. If I copy the SSD to USB stick, put it into the DC and then run it from an imported Ram SSD it works fine.

I haven't done any investigating like looking at the contents of the disk with a sector editor or anything like that.

[MartinB]

I can't try myself until tomorrow I'm afraid but the ssd is only very small being 18k so there's negligible transfer time, its literally just the overheads of writing about 8 tracks. Pending my trying the original and if you get time, have a go with the attached disc which is Tricky's real Beeb disc simply padded with some test data files to make a bigger ssd.

ScrambleRC4 + padding.ssd

(145.75 KiB) Downloaded 87 times

(Incidentally, there's never been such a thing as an ssd that UPURS won't transfer other than protected/unreadable ones.)



.

[MartinB]

Ok, I got home sooner than I thought so I’ve had a play since these things niggle me....

I downloaded Tricky’s original RC4, switched on the Beeb and fired it over to a floppy using UPURS. As Martin (guddler) noted, it’s super quick being only a short ssd so the whole process from Beeb on to <Shift><Break> was less than a minute. As Martin also found, I got the loading screen and key choices but on pressing Return, the screen just went blank.
So, I then spent a couple of minutes looking at the ssd in HxD (even though UPURS is agnostic to any data protocol at transfer time) but I fairly quickly decided that there was nothing to see. I then tried the bigger, padded ssd I posted above and that worked ok! Confused, I then tried loading Tricky’s original into DFS Explorer and simply rewrote the ssd without otherwise making any changes. This new ssd copy (still 18k) also worked! Even more confused, I then binary compared the original download with my rewritten ssd and they were identical!

At a now impossible juncture, I finally tried writing Tricky’s original back to a floppy again (still with UPURS) and guess what? It worked....

My conclusion - there’s something slightly awry with the actual Scramble code such that at least on my Beeb (and I suspect on other Martin’s too), it is very marginal as to whether the main program runs. I think I’d go as far as to say that it’s actually temperature-related in that when cold, the Beeb doesn’t like it and you get the blank screen. All my messing about simply added up to Beeb on-time and allowed everything to warm up.

Thoughts anyone? Tricky?


EDIT : I’ve also now closed the loop by using UPSSD to make a real floppy, then using UPXSSD to make an image of the floppy back on the PC and finally performing a binary file compare of the two and sure enough, they are identical. Thus, UPURS is faithfully transferring the image but there’s something subtle about whether you get the blank screen or not.


.

[guddler]

Thanks for trying this Martin. I was actually lazy as the wife wanted to watch a film!

There’s definitely something marginal going on as I had to write the SSD for RC3 a few times before it worked but no matter how many times I wrote RC4 to floppy it refused to play ball.

Would it not be more likely to be a marginal timing thing with the floppy drive write shutting off? But I feel like I’m talking out of my behind since I didn’t think that kind of thing entered into the equation!!

Ohhh, hang on. There are config parameters for floppy drives on the master. I wonder if it could be anything to do with that? But then that wouldn’t explain RamFS also failing.

To be honest, I’ll settle just for the resolution that upurs doesn’t seem to have an issue! In theory I guess I could write the SSD to memory (UPLOAD) and then write it to the usb stick. That ought to be the same as physically transferring the stick? I’ll try that.

It’s an odd one for sure!

[MartinB]

Would it not be more likely to be a marginal timing thing with the floppy drive write shutting off? But I feel like I’m talking out of my behind since I didn’t think that kind of thing entered into the equation!!

Ohhh, hang on. There are config parameters for floppy drives on the master. I wonder if it could be anything to do with that? But then that wouldn’t explain RamFS also failing.

No, I'm quite sure it's transferring over perfectly - floppy drive settings and the like don't matter to UPURS, the disc reading and writing aspects are OSWORD $7F driven so faster or slower writing due to hardware is irrelevant unless you get an actual write fault which would cause a failure and be reported. I've run my automated download>upload>compare>repeat test on Tricky's RC4 ssd for an hour this morning without any transfer failures and I've also tried lots of run-testing and basically, I just seem to get random occasions when it 'crashes', just giving the blank screen - I'm not even certain now that its temperature-related. So for me, this oddity is something subtle with the Scramble program itself, presumably related to variances in video chips but I'm no expert there.

[tricky]

Sorry, guys, I missed this thread, assuming it was WIFI related!

There was an issue on earlier versions of Scramble, where it could end up never hitting a vsync, or at least no where near what is needed to be reliable.
Once synced, everything is fine and it never got out of sync again.
For RC3, I changed the way that Scramble starts up, waiting for the correct point in the frame to guarantee a safe transition into Scramble MODE.
I have only tried a few dozen times, but can't reproduce the black screen on B, Master or Compact (B+ is poorly).
The beebem version I think can produce a blank screen (on HW), but it if ever didn't it would look very wrong, so I doubt that is the answer.
There may be something that I have missed or broken, but it is very hard to tell on HW without an instruction log that contains the H and V sync pulses!
The code sets a mode equivalent to MODE 1 that will sync very quickly, then decompresses Scramble to 19K which should be long enough for the HW to have synced. After decompressing, it changes to MODE Scramble and starts the game.

If you find a machine that fails often and have time to test, please change to MODE 1, run the code from line 350 of LOADER to set the keys (you can customise them if you like) and then *SCRAMBL. If this always works, it suggests that the new mode hasn't synchronised by then and that I need to wait longer or find a way to make it sync more quickly.

I'll re-post this in the Scramble thread as it doesn't look at all related to UPURS.