Hello again, I think my techno-stress and gadget-anger levels have returned to normal now so thanks for the feedback thus far
I apologise for the curt post last night and I won’t bore you with the details but in essence, that video has a lot to answer for
. It was the third full version interspersed with hours of turgid and ultimately wasted uploading time whilst the Beeb was the second of two after the first ignored No Smoking
signs and then later kept hitting the ‘Language?’ barrier
. (Oh yeah, and YT just plain lied to me about the first link they allocated
Anyway, my major omission was not to thank Paul (paulv
) & t’other Martin (mga1103
) for all their help with UPCFS. I seriously doubt it would ever have made it to release without their efforts
. Paul has already pointed to his fantastic all-things-Beeb site where you can find all the background info to UPCFS, an amazing manual and details for how we hope to advance the development. Talking of ‘advance’, I must also mention my friend and armageddon, Hugh (Advance
), who found more ways to ‘break’ UPURS & UPCFS then there are bytes in the code – certainly kept me on my toes
A bit more detail then….
UPCFS has three functional layers, the RS232 115K byte-fetching engine, a UEF reader and the CFS emulation itself. Regarding the UEF reader and as Paul has already mentioned, UEF’s often seem to be ‘gzipped’ and the Beeb isn’t really up to unzipping on the fly so you need to make sure that you’ve unzipped a UEF properly before using it with UPCFS. (It will refuse to play and tell you if a file is gzip btw.) For example on this - if you download a tape file from STH where it will have a zip extension (test.zip), unzip it and a .uef will fall out (test.uef). However, you then need to add a .gz extension (test.uef.gz) and unzip it again when a true UEF will result (test.uef again!). Paul and/or Martin know more than I about how to automate this process and perhaps might elucidate on a possible plan to provide a pre-prepared library?
The CFS emulation is necessarily accurate and I should point out that all the code is written from scratch, none of the OS code is re-used and no calls are made to the OS other than to the documented library. This approach ensures maximum compatibility across the Acorn range and will make an Electron port a breeze. I (we
) intend to convert UPCFS into a full FS (current a Utility rom) and this will offer an immediate improvement because for starters, there is a potentially vulnerable block of about 60 bytes of ram used by UPCFS for rom switching that would vanish in an FS wrapper.
We would very much like to engage interested parties (hackers and tinkerers etc.) to see if we can better characterise why certain games fail. We have a good handle on this side of things and whilst there are some techniques that can not be sorted in the short term, there may be some protection techniques that could be overcome if the CFS emulation in UPCFS was even tighter still. If this sort of exciting investigative work interests you then you are welcome to a copy of the source code but I don’t want to wholesale lay it bear until we believe we’ve reached the 99% compatibility end-game.
What else have I forgotten team…..?