UPURSFS on Elk with AP5

[!FOZ!]

Is anyone running UPURSFS (file system version) on an Electron with AP5? I know the user port is at a different location. I have rebuilt the ROM for my BBC Master (within internal user port) before. But before I head down the path of building another cable, building the ROM etc - thought I would ask if there are any known working cases? So far, I did put my cart from BBC Master in the Elk and it seems to boot, and is selectable via holding down U on Break - but obviously no RTS since its looking in the wrong place memory wise.

[sweh]

That's an interesting question.

I know it can work at other addresses (I run mine at &FCB1 with a second user port hanging off the 1Mhz bus).

A couple of other people have used it on the Electron, but I dunno if that was with an AP5 or something else.

What speed does the AP5 run at? If it's at 2MHZ then you might need to set USER_PORT_2MHZ to get the timings correct (needed for the M128 econet socket userport, at FEA0).

If the original UPURS works with AP5 (Martin?) then UPURSFS _should_... the core routines have been rewritten for tighter timings, but it's still the same idea.

[daveejhitchins]

There's an Electron version of UPURS (attached). It may also be worth reading MartinB's thread on the subject.

I've used it many time to transfer Disc images from PC to physical media.

Dave H.

UPURS2V0E.rom

(16 KiB) Downloaded 4 times

[MartinB]

Hello folks - yes, UPURS will work with any 6522-based ‘User Port’ but in some cases, depending on the details of the host machine, slightly different versions of UPURS have been configured to support either different physical addresses of the port or to support subtle timing nuances. In specific answer to the AP5 question and assuming we are talking about Dave H’s new AP5, the latter not only supports UPURS but has specific connection points for both my UPURS and I2C project functions via (I think) PL1 and PL2 respectively. I think the bespoke Elk UPURS version used for the AP5 is V2.0E which includes an MCG loader but if someone can confirm that the AP5 User Port is at the same address as my EUP board then UPURS V1.0E will also work fine. Apologies for the slight wooliness in my memory, its been a while since I produced this stuff so maybe Dave H can add some confirmations of version numbers etc. In terms of running UPURS on an original AP5, it depends where the User Port lived, was it at the same address as Dave’s new AP5?

EDIT : We overlapped Dave! Thank-you and it looks like we are being consistent!

[!FOZ!]

Thanks everyone. I am planning using UPRSFS - the file system variant. From what I gather from this discussion - seems regardless the core should work. Will report back results.

[!FOZ!]

Ok, I made up a lead (no diodes/resitors) per the AP5 manual and compiled my own UPURSFS for FCB1 and it works! I am seeing some instability when loading things and ROMs getting disabled. So I suspect the ADT rom and UPURSFS are clashing in workspace. I will disable ADT rom socket / remove it and try again. But so far so good!

[!FOZ!]

Ok, so it was not ADT (or at least not the whole problem), it appears UPURSFS ROM is not playing well with the RH Plus 1 ROM (which looks also to be a ROM manager). Providing I do not hit break, i can unplug RH Plus 1 ROM and files load and save just fine. What i may try next is changing some new workspace locations in UPURSFS - but I would need to know what RH Plus 1 ROM is using for its disabled ROM list.... Dave?

[daveejhitchins]

Ok, so it was not ADT (or at least not the whole problem), it appears UPURSFS ROM is not playing well with the RH Plus 1 ROM (which looks also to be a ROM manager). Providing I do not hit break, i can unplug RH Plus 1 ROM and files load and save just fine. What i may try next is changing some new workspace locations in UPURSFS - but I would need to know what RH Plus 1 ROM is using for its disabled ROM list.... Dave?

Try looking here - everything you need to know about the Plus 1 Support ROM, including the source code, is there . . .

Do post what you find as maybe one or the other programs can be modified.

Dave H.

[!FOZ!]

Ok, so it was not ADT (or at least not the whole problem), it appears UPURSFS ROM is not playing well with the RH Plus 1 ROM (which looks also to be a ROM manager). Providing I do not hit break, i can unplug RH Plus 1 ROM and files load and save just fine. What i may try next is changing some new workspace locations in UPURSFS - but I would need to know what RH Plus 1 ROM is using for its disabled ROM list.... Dave?

Try looking here - everything you need to know about the Plus 1 Support ROM, including the source code, is there . . .

Do post what you find as maybe one or the other programs can be modified.

Dave H.

Thanks Dave - I forgot you pointed out the source code before. Will take a look through both code bases and see what I can spot. Meanwhile I am quite impressed its basically working and excited for the improvement it will bring to developing the RTC code.

[sweh]

Ok, so it was not ADT (or at least not the whole problem), it appears UPURSFS ROM is not playing well with the RH Plus 1 ROM (which looks also to be a ROM manager). Providing I do not hit break, i can unplug RH Plus 1 ROM and files load and save just fine. What i may try next is changing some new workspace locations in UPURSFS - but I would need to know what RH Plus 1 ROM is using for its disabled ROM list.... Dave?

My guess would be the stuff around D68.

UPURSFS uses this for buffer (in "default")

Code: Select all

\ NMI routines can live from &D00->&D7F.  I know Solidisk DDFS used
\ to copy code into here, and we are a filesystem, so maybe it's safe
\ for us as well
serbuf =? $0D10
bufsize =? $60   \ allow some overrun space

(JGH has moaned, before, that I use this space without claiming NMI.. )

Looking at https://mdfs.net/Software/BBC/SROM/Plus1/AP1v131.src I can see

Code: Select all

REM Workspace
REM ---------
REM &0D68-&0D6C Plus 1 Support
REM &0D6D-&0D6F ROM Manager Support
REM &0D70-&0D7F ROM/TAPE intercept

And https://mdfs.net/Software/BBC/SROM/Plus1/AP6v133.src has

Code: Select all

:
REM Workspace
REM ---------
LAC=&AC:LAE=&AC                 :REM Command workspace
L0D70=&0D70                     :REM Saved file vectors
L0930=&0930                     :REM Base of *FORMAT workspace
L09D0=FILEBLK+1:L09EC=FILEBLK+12:REM Base of *VERIFY workspace
L0D6C=&0D6C:L0D6D=&0D6D         :REM ROM manager settings
L0D6E=&0D6E:L0D6F=&0D6F         :REM UNPLUG bitmap

So maybe reducing the bufsize to $40, or perhaps even moving it elsewhere; on the Beeb I thought about

Code: Select all

\ This might work; the serial/tape input buffer.  
\ serbuf = $0A00
\ bufsize = 240

but I've not tested, and I dunno if the Elk works the same way.

[!FOZ!]

Ok, so it was not ADT (or at least not the whole problem), it appears UPURSFS ROM is not playing well with the RH Plus 1 ROM (which looks also to be a ROM manager). Providing I do not hit break, i can unplug RH Plus 1 ROM and files load and save just fine. What i may try next is changing some new workspace locations in UPURSFS - but I would need to know what RH Plus 1 ROM is using for its disabled ROM list.... Dave?

My guess would be the stuff around D68.

UPURSFS uses this for buffer (in "default")

Code: Select all

\ NMI routines can live from &D00->&D7F.  I know Solidisk DDFS used
\ to copy code into here, and we are a filesystem, so maybe it's safe
\ for us as well
serbuf =? $0D10
bufsize =? $60   \ allow some overrun space

(JGH has moaned, before, that I use this space without claiming NMI.. )

Looking at https://mdfs.net/Software/BBC/SROM/Plus1/AP1v131.src I can see

Code: Select all

REM Workspace
REM ---------
REM &0D68-&0D6C Plus 1 Support
REM &0D6D-&0D6F ROM Manager Support
REM &0D70-&0D7F ROM/TAPE intercept

And https://mdfs.net/Software/BBC/SROM/Plus1/AP6v133.src has

Code: Select all

:
REM Workspace
REM ---------
LAC=&AC:LAE=&AC                 :REM Command workspace
L0D70=&0D70                     :REM Saved file vectors
L0930=&0930                     :REM Base of *FORMAT workspace
L09D0=FILEBLK+1:L09EC=FILEBLK+12:REM Base of *VERIFY workspace
L0D6C=&0D6C:L0D6D=&0D6D         :REM ROM manager settings
L0D6E=&0D6E:L0D6F=&0D6F         :REM UNPLUG bitmap

So maybe reducing the bufsize to $40, or perhaps even moving it elsewhere; on the Beeb I thought about

Code: Select all

\ This might work; the serial/tape input buffer.  
\ serbuf = $0A00
\ bufsize = 240

but I've not tested, and I dunno if the Elk works the same way.

Wow thank you Seth - so honored to have you take a look at this.

I totally love this version of UPURS. I have my project under Git and the magic of editing files on either my Mac or the Elk/BBC never gets old. Creating a file on the Elk and seeing it pop up as an uncommitted Git file makes me smile - and of course being able roll back changes and simply reload the file on the Elk/BBC more so. I bored one of my work colleagues with this the other day - may have gone on a bit too long!

I am trying your suggestion right now - and will update here!

[!FOZ!]

Ok reducing the buffer size worked a treat - I still get a clash with ADT but that’s fine I can live without that tbh.

Thanks very much Seth!

Update 1: Mode2 and Mode0 seems to cause UPURSFS some problems with *CAT for example - output gets corrupted and can crash the machine. Fortunately for the software I am developing (RTC software for AP6) it not a big issue. I suspect it’s a timing issue maybe with increased bandwidth needed in those modes?!?1

Update 2: Attached a couple of pictures on my cable. From past projects I had one end of joystick extended cable. It’s not likely to be the most durable solution but works just fine. It plugs directly into the UPURS pins on the EP5 so no additional components needed compared to such cables required when connected to the BBC. Nice!

Update 3: So the issues I saw with Break hanging that I thought was a combo of ADT and UPURSFS ROM provided not actually to be the case. Without the UPURSFS ROM installed I get the same issues - which I assume is likely a clash between ADT and Plus 1 ROM. For those interested it’s reproducible by doing *ROMS then pressing break which then hangs - it requires a Ctrl+Break to fix (topic for another thread clearly).

As a side note: I did find that a pin on my EEPROM I was using was quite stuck in the turnpin socket on the AP5, and alas broke off leaving the pin in the socket. As a credit to how far I have come in this hobby - I resisted freaking out and hacking away to try to remove it (it had very little to grab on) and noted a “project” for another day to desolder the socket for a new one. Fortunately, for today, I had another EEPROM (will also repair the other in the future) and the AP5 has another ROM socket. So turning a negative into a positive - I have a couple of new mini-projects on the list!

[sweh]

Thanks very much Seth!

Who?

Update: Mode2 and Mode0 seems to cause UPURSFS some problems with *CAT for example - output gets corrupted and can crash the machine. Fortunately for the software I am developing (RTC software for AP6) it not a big issue. I suspect it’s a timing issue maybe with increased bandwidth needed in those modes?!?

Very possibly. The UPURS core routines were tuned to be cycle accurate for a Beeb (so takes into account clock stretching when accessing the user port). I don't know that much about the Elk, but I thought it was relatively slow to access RAM (1Mhz?) so it's possible that the extra clock shenanigans needed for higher modes might break timings (I AM VERY MUCH GUESSING, HERE). And once that happens data could get lost or corrupted, or...

If you're using my TubeHost fileserver (written in perl) then there are *OPT6 options to let you add delays in sending data which _might_ help tune things and maybe improve reliability. There's a section in the README that talks about this.

[!FOZ!]

Who?

My goodness! So sorry to spell your name incorrectly.

Very possibly. The UPURS core routines were tuned to be cycle accurate for a Beeb (so takes into account clock stretching when accessing the user port). I don't know that much about the Elk, but I thought it was relatively slow to access RAM (1Mhz?) so it's possible that the extra clock shenanigans needed for higher modes might break timings (I AM VERY MUCH GUESSING, HERE). And once that happens data could get lost or corrupted, or...
If you're using my TubeHost fileserver (written in perl) then there are *OPT6 options to let you add delays in sending data which _might_ help tune things and maybe improve reliability. There's a section in the README that talks about this.

Very interesting - and yeah I have been meaning to refresh my memory on this ROM - will take a look. Oh and yes, I using the Perl Tubehost software.

Thanks again!

[daveejhitchins]

Without the UPURSFS ROM installed I get the same issues - which I assume is likely a clash between ADT and Plus 1 ROM. For those interested it’s reproducible by doing *ROMS then pressing break which then hangs - it requires a Ctrl+Break to fix (topic for another thread clearly).

I've not noticed that (I'll check it out), however, I always use *PROMS * to ensure I always use the Support ROMs *ROMS - The '*' after *PROMS gives a full listing.

Dave H.

[tom_seddon]

For whatever it's worth, the Master reference manual part 1 divides page D up as follows. (I've always treated this as fairly authoritative, since it's comprehensive official documentation produced relatively late in the Beeb's life.) This suggests that for widest compatibility across the whole 8-bit range you should probably avoid $d60 and up.

&0D00–&0D5F NMI routine and workspace
&0D60–&0D7F Econet workspace.
&0D80–&0D91 Currently unallocated.
&0D92–&0D9E Reserved for use by Trackerball.
&0D9F–&0DEF Expanded vector set.
&0DF0–&0DFF Paged ROM workspace.

(Correctly claiming the NMI region is actually pretty easy, but you can probably wing it until more serious repercussions are found from not doing it. Only thing to bear in mind is that the owner ID is a filing system ID, rather than (as some references have/had it), the owner's ROM number.)

Very possibly. The UPURS core routines were tuned to be cycle accurate for a Beeb (so takes into account clock stretching when accessing the user port). I don't know that much about the Elk, but I thought it was relatively slow to access RAM (1Mhz?) so it's possible that the extra clock shenanigans needed for higher modes might break timings (I AM VERY MUCH GUESSING, HERE). And once that happens data could get lost or corrupted, or...

It can be even worse than that: in modes 0-3, when display is being produced (so for 40 microseconds out of each of the visible scanlines - 256 scanlines in modes 0-2, 200 scanlines in mode 3), the display uses all the RAM bandwidth. The CPU simply halts if it attempts to access RAM. If the CPU gets an NMI, it's given priority over the display, but I'm not sure you can induce this state under software control.

(I got away without having to think about this for Electron BeebLink. The transfer is not timing-sensitive, and so things are just (even more) slower in Modes 0-3.)

--Tom

[!FOZ!]

Without the UPURSFS ROM installed I get the same issues - which I assume is likely a clash between ADT and Plus 1 ROM. For those interested it’s reproducible by doing *ROMS then pressing break which then hangs - it requires a Ctrl+Break to fix (topic for another thread clearly).

I've not noticed that (I'll check it out), however, I always use *PROMS * to ensure I always use the Support ROMs *ROMS - The '*' after *PROMS gives a full listing.

Dave H.

So *PROMs with ADT installed, and pressing break causes the machine to go to a yellow supervisor prompt.

[daveejhitchins]

Without the UPURSFS ROM installed I get the same issues - which I assume is likely a clash between ADT and Plus 1 ROM. For those interested it’s reproducible by doing *ROMS then pressing break which then hangs - it requires a Ctrl+Break to fix (topic for another thread clearly).

I've not noticed that (I'll check it out), however, I always use *PROMS * to ensure I always use the Support ROMs *ROMS - The '*' after *PROMS gives a full listing.

Dave H.

So *PROMs with ADT installed, and pressing break causes the machine to go to a yellow supervisor prompt.

I always have ADT installed and have never seen this issue - something else is causing this . . . ? - Dave H.

[!FOZ!]

I've not noticed that (I'll check it out), however, I always use *PROMS * to ensure I always use the Support ROMs *ROMS - The '*' after *PROMS gives a full listing.

Dave H.

So *PROMs with ADT installed, and pressing break causes the machine to go to a yellow supervisor prompt.

I always have ADT installed and have never seen this issue - something else is causing this . . . ? - Dave H.

Ah ok that’s good to know. I have ROM/RAM solution installed for the Plus 3 and EXMON IIe and BE so plenty to go at tracking down. I just know that it works when I don’t have ADT 1.78 enabled, that said, as its 32k ROM, when I disable ADT (jumper) that also disables EXMON….