Wires? Pah.....

[MartinB]

Chet - I’ll send a PM with my email address and we’ll go from there.....

[MartinB]

As promised, for chrisH (and others), here’s the link to the recommended USB-to-RS232 adaptor and supplier......

https://www.tronisoft.com/store/adaptor ... -90cm.html

[chrisH]

Perfect - thanks!

[MartinB]

@ Chris and Stuart - all being well, should be able to post in the morning but I’ll email to confirm.....

[aerworuld]

Martin, thank you so much!

Now that I have UPURS for my Master 128, my world is complete again! Outstanding piece of kit, just like Elk EUP

To celebrate, here's a piccy that I drew in AMX Super Art and transferred across to the PC to test the new cable out. AMX Super Art is state of the art compared to the AMX Art that I'm used to on the Elk... colour and everything!

Now i just need to figure out how to have both the mouse and the UPURS plugged into the User Port on the 128 at the same time to save switching plugs

thanks again,
Stu

[daveejhitchins]

Stuart . . . That's why you have an Electron and AP5

Dave H

[MartinB]

Nice work Stuart, you never disappoint.....

Regarding User Port conflicts on the Master, Simon (sydney) confronted this problem by adding a second User Port via the Master's internal Econet connector - have a read of the thread here. I produced a special version of UPURS to be compatible with this new second port so in his case, he can use UPURS with other User Port peripherals such as mice or MMC systems. I'm not sure if anyone mass-produced Simon's design (?) but maybe someone could assist you to realise one....?

[hoglet]

Regarding User Port conflicts on the Master, Simon (sydney) confronted this problem by adding a second User Port via the Master's internal Econet connector - have a read of the thread here. I produced a special version of UPURS to be compatible with this new second port so in his case, he can use UPURS with other User Port peripherals such as mice or MMC systems. I'm not sure if anyone mass-produced Simon's design (?) but maybe someone could assist you to realise one....?

Steve Picton has a couple of these left:
https://www.ebay.co.uk/itm/223335751689

Dave

[MartinB]

That looks perfect Dave - I see the base address is as per Simon's implementation but with Steve's device not being based on a genuine 6522, I presume it will behave the same on the outside-facing interface down to a microsecond level...? I only ask because as you know, my bit-banged RS232 is asynchronous and so unlike MMC interfaces, it isn't immune to subtle timing differences. Assuming it is directly equivalent to the 6522, it would work out of the box with the UPURS 5.9 version I produced for Simon.

Can you rustle up another £14 Stuart?

[danielj]

If you're going to spend £14, I'd consider the gotek (especially on a Master as it's got the DFS gubbins built in)?

d.

[hoglet]

That looks perfect Dave - I see the base address is as per Simon's implementation but with Steve's device not being based on a genuine 6522, I presume it will behave the same on the outside-facing interface down to a microsecond level...? I only ask because as you know, my bit-banged RS232 is asynchronous and so unlike MMC interfaces, it isn't immune to subtle timing differences. Assuming it is directly equivalent to the 6522, it would work out of the box with the UPURS 5.9 version I produced for Simon.

Steve's device is based on a genuine 6522 (a WD65C22 to be precise).

But (and this is quite a big but) it's clocked at 2MHz because that's what's available on the Econet header.

So your code would run slightly faster.

Given this, it might be best then to use the internal user port for MMFS rather than UPURS.

Dave

[MartinB]

Ah, ok thanks Dave - I confess that I saw the square surface-mount device and glazed over assuming it was a CPLD VIA emulator or something - my bad

Regarding the 2MHz clocking with no access slow-down, the 'special' UPURS v5.9 was exactly for that purpose (and at the new base address) because Simon's extra 6522 used the same Econet connector and hence was also clocked at the full 2MHz so I re-adjusted the cycle timing for the higher speed clock rate. Hence my comment about Steve's gadget together with UPURS 5.9 working 'out of the box' (now you've confirmed it's a 6522.)


.

[aerworuld]

hehe, don't worry Dave, the Electron is still a happy elk with all systems go, I just always wanted a 128 too

Thank you Martin; glad you like the piccy lol

With the User Port, I was thinking more of a switcher or similiar as I thnk I would only need to use one or the other, not both at the same time.Just wanted to save wear by plugging and unplugging al the time

[SpaceFlightOrange]

Sorry to change subject, but I've been reading about UPURS since Mark's mention. Im struggling to find any decent info on it, but It sound like its just what im looking for! I have a bunch of corrupt floppies that I'd like to try and save. Can you point me in right direction, please? I understand it's your baby

Thanks

>Moderators note: Part of this post has been transferred from the I2C 4 U thread. Mark

[MartinB]

For the latest package clicky here and for some supporting back-story, have a look at Paul Vernon's Retro-Kit UPURS pages.

If you have any questions or comments, you can post on the first linked 'Wires? Pah...' thread.


If you need to get a USB-RS232 adaptor, here’s the link to the recommended device and supplier......

https://www.tronisoft.com/store/adaptor ... -90cm.html

[SpaceFlightOrange]

For the latest package clicky here and for

Thanks Martin.

I have one of these:

I originally picked it up for flashing the Gotek but I have used it with CoolTerm on the Mac to talk to a Pi. Once I get hold of a Domino Din plug, I want to have a play at connecting to the Beeb. Will this suffice?

[1024MAK]

I have one of these:
<snip>
I originally picked it up for flashing the Gotek but I have used it with CoolTerm on the Mac to talk to a Pi. Once I get hold of a Domino Din plug, I want to have a play at connecting to the Beeb. Will this suffice?

Which chip is it using?

In theory any USB - RS232 converter should do. But some do not correctly implement the hardware flow control (RTS/CTS). UPURS requires the hardware flow control signals to work correctly.

The voltage levels are not important, as long as the connecton to the Beeb is at TTL (5V) logic levels, or at RS232 official voltage levels (and the cable is constructed to the published UPURS design).

Note that signal polarity is important. If using TTL levels without a RS232 level converter, you may need to invert the signals using say a 74xxx series chip such as a 74LS04.

UPURS connects to the User Port, NOT the Beebs RS423 serial port, so no 5 pin domino DIN plug required.

And if you are not sure if hardware flow control is implemented, why not try it and see what happens

Mark

[MartinB]

Hmmmm....

Can you see what the chip is on which it's based - in particular, is it an FTDI device? Secondly, and very importantly, any such gadget MUST correctly implement CTS and RTS handshaking - an area where many many adaptors fall over because much of our familiar modern computer equipment doesn't bother with hardware handshaking and the adaptors lazily implement a flawed system.


EDIT : I see Mark got in first but I presume we've said similar things.....


Except....

And if you are not sure if hardware flow control is implemented, try it

Sometimes, inferior adaptors can appear to work but the data is full of drop-outs so I always advise that unless you know for sure that CTS/RTS is correctly implemented, assume it isn't and buy a Tronisoft FTDI device!



.

[SpaceFlightOrange]

Yeah, sorry, I did mean to include that in the post.

it's an FT232RL FTDI and its switchable between 5v & 3.3v via the jumper. It's set to 5v in the picture. I'm not sure about the flow control, to be honest.

[MartinB]

If its FTDI then it should be ok. For the UPURS connection to the Beeb User Port via the cable (you will be making ), you need to be able to clearly identify TxD, RxD, RTS, CTS and Ground on the adaptor. If you can't, then it's potentially a more difficult job.


.

[SpaceFlightOrange]

If its FTDI then it should be ok. For the UPURS connection to the Beeb User Port via the cable (you will be making ), you need to be able to clearly identify TxD, RxD, RTS, CTS and Ground on the adaptor. If you can't, then it's potentially a more difficult job.

It has all those.

I was reading your manual about the lead from the user port. presumably I still need to make it up in the same way, with the diodes, etc?

[MartinB]

Hi James - well, if you know that a given module can only drive all the RS232 lines at 0v to +5v (no negative) then no, you don’t need either the diodes or the resistors and for the latter, just connect the lines straight through.

The passive components are there to protect against the legitimate use of up to +-12v levels for the RS232 signals.

Easy job then!

Thought 1 - also, your module won’t be using a D-Type and won’t have (I presume?) such things as DSR and DTR etc so ignore the shorting link too.

Thought 2 - do check those levels before you ditch the passives, particularly the possible use of a -5v to +5v swing which, without the diodes, would potentially damage your 6522.



.

[IanS]

Hi Janes - well, if you know that a given module can only drive all the RS232 lines at 0v to +5v (no negative) then no, you don’t need either the diodes or the resistors and for the latter, just connect the lines straight through.

Though the TTL signals will need inverting. RS-232 "1" is a negative voltage, TTL "1" is a positive voltage. The Diode and resistors just clamp the signal to TTL levels.

[MartinB]

I was thinking perhaps that being an FTDI-based TTL module, the signal states would be as per the likes of the Tronisoft adaptors and yes, I do perform inversion in the UPURS RS232 core engine.

(I do know what the diodes and resistors do btw, I designed it remember.... )


.

[MartinB]

Actually Ian, a while ago we did have a long discussion about using these modules with UPURS in another thread....

viewtopic.php?f=3&t=10586&p=136538#p128748

What I can’t deduce from that is what the conclusions were?

You suggested then that you had one or two modules to try in order to determine the facts in relation to the inversion (or not) issue - did you conclude anything?

@ James - this is why I always just cut to the chase and tell folk to get a Tronisoft adaptor. It invariably saves a world of pain for everyone....



.

[IanS]

You suggested then that you had one or two modules to try in order to determine the facts in relation to the inversion (or not) issue - did you conclude anything?

Nope, not tried it yet, it's still on the list, just not a high priority.

[1024MAK]

Info from the datasheet. The FT232R chip used supports RTS/CTS and DSR/DTR handshaking. So it is a case of if the DSR/DTR signals are connected on the PCB for the module. And on the configuration of the chip.
Also according to the datasheet, the FT232RUART interface UART signals can each be individually inverted. This feature is configurable in the EEPROM.

Datasheet here.

So external inverters are not required if the FT232R chip is correctly configured. But if you don’t have software to reconfigure it, it may just be quicker to connect up a 74xxx chip (such as a 74LS04 or 74HC(T)04) instead...

Mark

[tom_seddon]

Can anybody comment on the licence for the UPURS read/write routines used in the UPURSFS ROM? (https://sweh.spuddy.org/Beeb/UPURSFS/) I'm hoping to use them in BeebLink, which is GPL v3 or (at your option) any later version.

The readme has a note about the code maybe not being GPL v2 compliant, but I'm hoping to get a bit more clarity :)

The comment in the code says:

Code: Select all

\ This is a rewrite of the core Read/Write routines by hoglet
\ With luck this might also reduce the dependency on FTDI chips
\ by improving CTS handling.  But no promises!

I'm not sure how much of the code this covers, so maybe some is by MartinB or sweh as well...

I'm covered for all the FS bits, and the underlying protocol. I'm just hoping to use the pre-cycle-counted byte send/receive routines to get bytes between BBC and PC... my track record with bit-banging serial transfer code is very poor, and I'd much rather reuse somebody else's pre-tested routines.

--Tom

[1024MAK]

Can anybody comment on the licence for the UPURS read/write routines used in the UPURSFS ROM?

Hi Tom

All the original UPURS code is by Martin (MartinB) and as far as I know, he has not so far released the source code.
The adaptation is by Stephen (sweh).
hoglet is Dave.
I suggest you ask all three.

Mark

[sweh]

So it probably depends on what part of the code you're looking to re-use. If it's just the "Low Level I/O routines" stuff then...

Dave's code is primarily in "txgo". You can see his changes in github hoglet-core branch ( https://github.com/sweharris/ROM_Source ... oglet-core ).

The UPURS code starting at "Low Level I/O routines" in the hoglet-core branch are either his or Martin's original code. My changes are minimal and just for integration. if they are happy with you taking a copy for BeebLink under GPL then I have no objections.

(Hmm, why did I never merge that branch? The published version includes it! I'll look at this over the weekend... )

If you want code from outside of the I/O core then let me know and I'll try to identify who to blame^Wask