Wires? Pah.....

[MartinB]

This is fun, exciting even?

So, on the same day that scientists created life in the laboratory, I did this...



What the...?

Answers on a postcard to MartinB, c/o STH

[station240]

Traitor, but I like having cables everywhere.

Anyway its quite simple, you just attached a [mumble mumble] to [indecipherable]. Sorry I have a cough still, you'll have to figure it out for yourselves

[BeebMaster]

Since we didn't actually see you typing on the Beeb keyboard in the first half, I reckon the telly is connected to another Beeb out-of-shot, under the table, with your glamorous assistant typing away at the required moment.

[retroclinic]

Bluetooth RS232 RX connected to the Beeb serial port, using the BT in the netbook is my guess.....?

[MartinB]

And Mark wins the coconut (although this implementation is not actually RS232)

Just before I became an unemployment statistic , I was working on ways to clean up the cabling associated with some military equipment. Unfortunately, there were EMC issues with Bluetooth versus armed aircraft and I never got chance to resolve them and pursue the technology before I got my UB40 . Subsequently and with more time on my hands than usual, I suddenly made the connection (sic) between what I'd been trying to do at work and a similar application on the Beeb.

The basic gadget that's needed is already out there in a thousand retail shapes and sizes and the most common is loosely known as a Bluetooth Serial Adaptor. These units are equipment independent and are completely protocol focused. Essentially, the standard gadget can be used in pairs to replace a hard-wired RS232 connection between two devices. Once set up via a hard-wired RS232 connection to a PC, they become completely stand-alone and require nothing more than power, which many draw from the serial port itself. The dearer ones can even act as a Master device and initiate a connection to a slave.
Now, my first Beeb application thoughts were centered around these RS232 devices because the other devices I had appraised were Centronics based and the Beeb isn't a printer and doesn't have that interface. However, I am always slightly unsettled with RS232 on the Beeb since it doesn't reliably support the higher data rates and I've never felt that it was a truly robust implementation. Further, since the Beeb doesn't support DTR, DSR etc., there may need to be a bit of trickery in the interface connection to the gadget so that the latter will recognise the Beeb as a true RS232 host. For these reasons, I decided to investigate the parallel Centronics route and my first task therefore was to allow the Beeb to emulate the Centronics interface, as if it were a printer, and then to replace the parallel cable with a Bluetooth Centronics Adaptor.

At first sight, the Centronics interface wouldn't be too difficult but I had two targets which were (a) that no additional electronics could be used and that (b) no special software would be used on the PC. I won't go into the technical details just yet but suffice to say that the job was actually quite tricky since I had to use the User Port (which had too few control lines) and the Centronics interface spec. has some pretty fast relative edges which were at first hard to replicate.
Anyway, I got there in the end and using the new cable and minimal software on the Beeb I was able to make a PC talk to the Beeb as if were a genuine LPT printer. That done, I then added the Bluetooth gadget in place of the standard PC printer cable and hey presto - PC to Beeb wireless transfer. I've only written test routines on the Beeb thus far but my intention is to end up with a rom having four basic functions of PC SSD to real Beeb disc, PC DSD to real Beeb disc, PC <any_binary_file> to a file on a Beeb disc and maybe PC <textfile> to Beeb screen.

The interface thus far works perfectly but lacks the hoped for speed of a parallel interface - more of that later. I will look at the serial side too since the gadget I have opted for is a dual device which supports both serial and parallel interfaces. The pics below show what was hidden inside the Beeb.

Any questions, comments or suggestions are welcome. I think this could be quite an exciting venture with many potential uses on Acorn kit.

Pico Plug 1.jpg (53.89 KiB) Viewed 14148 times

Pico Plug 2.jpg (61.83 KiB) Viewed 14146 times

Pico Plug box.jpg (59.44 KiB) Viewed 14145 times

Pico Plug Centronics connector.jpg (43.15 KiB) Viewed 14144 times

[Greybeard]

Interesting stuff (which I shall need to look at a bit more closely later ... with my cocoa)!

But take my tip Martin ... forget all about "working for the man". Set up by yourself, Mate. Or (if I may suggest it) perhaps a partnership with other Beeb wizards well known to this forum!

[MartinB]

Cheers Geoff. If you're still fighting the good fight with medical equipment, there may be kit with RS232 cabling which could benefit from these devices? The RS232-only devices can be had for around £25 and the Pico-Plug was only £15 but I had to pay another £12 in postage to get one from the single source in Germany. (Although the real postage cost was about half that )

This wireless RS232 facility might appeal to people such as irrelevant Rob (irrelevant ) who presumably uses serial data for a lot of his modem etc. work?

[irrelevant]

This wireless RS232 facility might appeal to people such as irrelevant Rob (irrelevant ) who presumably uses serial data for a lot of his modem etc. work?

Yep, but mostly the modems are sat next to the Beebs - it's rare that (at least in what I'm doing with the Beebs) I'd need more than a meter or two long serial link. Even telephone lines I can put where I want, now, thanks to using VoIP ATAs.

Now, my last job involved supporting various multi-user accounts systems, and, only 10 years ago, we were still running serial dumb terminals at vast distances across buildings. (Although by then we were installing Cat5 to connect them so as to facilitate upgrades.) I can see this sort of thing would have been useful for that!

Rob

[iomanoid]

I've got no real idea what this is (TL;DR ) but I want it anyway.

[Greybeard]

Yes Martin, I'm still plodding away trying to turn ***** into gold (that is, repair and refurbishment etc. of "good used" medical equipment). In fact I'm happy to report that my buddies and me have more work than we can easily handle. But that's really how things have to be on the Dark Side (of the Force) ... that is, for small independent (non-government funded) operators in the Private Sector.

We do a fair amount of work for veterinary practices and also for medical charities sending kit overseas, and this allows a bit of (shall we say) leeway (scope, whatever) for "imaginative" fixes that would be a bit, er, frowned upon within the NHS.

So, yes. This one could be of interest as yet another possibility for connectivity. As you may well imagine, the propietary methods and protocols pushed by the big manufacturers are all good and jolly, but not only cost the proverbial arm and a leg, but getting information out of those guys is like drawing hens' teeth.

Meanwhile, folk had better grab one of these quickly before demand surges!

http://cgi.ebay.co.uk/ws/eBayISAPI.dll? ... 0468767253

Just in case anyone still doesn't know, the Germans like to call their mobile phones a Handy (which is fair enough, when you think about it)!

[station240]

Well the device itself looks like a mutant iMac addon. Its hideous, no wonder you hid it inside the casing.

Poor ebay seller is going to be wondering why this particular device starts selling rather well.

[MartinB]

I will publish full details of the parallel cable because this can be used in conjunction with a standard PC printer cable (25-way D-Type to 36-way Centronics) to transfer files from a PC to a Beeb using software that I will also make available when it's finished. As I intended, there is no software needed on the PC and the Beeb can be treated as a generic/text printer (if anyone can think of a use for that) or files can be sent to the Beeb through a Command Prompt window using copy /b <filename> lpt1:
The Pico-Plug can then be used to replace the printer cable on any device that has a Bluetooth capability. You can even use PDA's or fancy mobile phones if you want.

I will produce the Beeb transfer software first and then will look at improving the speed of the parallel interface. I will also in due course add a serial option for anyone that has an RS232 only Bluetooth adaptor.

[BeebMaster]

I still think my idea of Debbie McGee under the desk is more fun

[MartinB]

As promised, here are the details of the Beeb (User Port) to PC (Printer Port) parallel cable which, in conjunction with the appropriate software (to follow) on the Beeb side, allows the PC to send files of any type to the Beeb via it's LPT port. The Bluetooth adaptor isn't needed for this, you can just add a standard PC Centronics printer lead and away you go.

The first photograph shows the detail of the Centronics socket (locking clamp removed for clarity) and how I manipulated the individual cores of the 20-way ribbon cable to avoid the need for soldering. Doing it this way is a little fiddly and does require some degree of experience in using IDC connectors but does produce a neater end result. Note that I have also extended the cores from Beeb Pin1 (+5v) and Pin5 (0v) in order to supply power (max. 120mA) to the Bluetooth adaptor but these are not needed for cable-only transfer.

Electrically, the connections in the cable are as follows :

Code: Select all

  Beeb Signal       Beeb Pin       Centronics Signal       PC Pin

       D0               6              Data Bit 0             2
       D1               8              Data Bit 1             3
       D2               10             Data Bit 2             4
       D3               12             Data Bit 3             5
       D4               14             Data Bit 4             6
       D5               16             Data Bit 5             7
       D6               18             Data Bit 6             8
       D7               20             Data Bit 7             9

       CB1              2               /STROBE               1
       CB2              4                 BUSY                11

       +5v              3                /FAULT               32
        0v              9                 POUT                12

The remaining Beeb 0v lines will naturally connect in the Centronics IDC to PC 0v lines at 19, 20, 21 etc.

The specification for the Centronics interface specifies that the PC will strobe a byte across to the printer (for us, the Beeb) using /STROBE and will determine that the byte has been read by the printer when /ACK is returned a short time later. Additionally, the PC will expect to see BUSY go high immediately after /STROBE or at any time when the printer cannot accept data. Since there are only two control lines available at the Beeb user port, CB1 and CB2, my original thinking was to drive /ACK actively and to tie BUSY low on the basis that the Beeb would not be printing the data (slow) but would mostly be buffering the data (fast) for occasional writes to disc (slow). To cater for the latter activity I anticipated withholding /ACK during writes to disc and all would be well. However, it soon became apparent that when using the PC LPT port in DOS or through a command prompt window and therefore bypassing and printer driver, /ACK is not read at all by the PC and all the handshaking is controlled via /STROBE and BUSY alone. So, quick remake of the cable, re-jig of the software and nope, still not working - I was getting characters but seemingly about one in every hundred!

At the Beeb end I am using /STROBE to generate a CB1 interrupt and on receipt, my IRQ code was checking the interrupt source, setting BUSY (CB2) high, printing the character to the screen, setting BUSY low again and looping. However, it seems that the Centronics interface is an extremely impatient beast and unless it sees BUSY set high within 500ns of its setting /STROBE low, it sends the next character hot on the heels of the last. Now, 500ns is equivalent to just one Beeb 6502 CPU cycle (where one full instruction probably averages 3-4 cycles) so it is immediately apparent that we have absolutely no chance of setting busy high in response to /STROBE within that time interval – at least not via software.

At this point, I was about to give up because it looked as if I was going to have to abandon one of my two original aims which were (a) not to have any extra hardware or circuitry in the Beeb and (b) not to have any bespoke software within the PC. I then recalled seeing that the 6522 has built-in handshaking modes called Read Handshaking and Write Handshaking which automatically control the state of CA2 or CB2 in response to an edge on CA1 or CB1. Not surprisingly though in this tale of woe, it transpires that Read Handshaking (for accepting data as in this application) is only available on the ‘A’ side of the 6522 which is already being used in the Beeb for the printer port and as such is buffered to be output only. Both ‘A’ and ‘B’ sides of the 6522 can employ write handshaking but since in this application I am reading data from the port rather than writing data to it, it looked as if this was also a lost cause.

There isn’t a very detailed description of these handshaking modes in the 6522 data sheets but if Write Handshaking is actually viewed in reverse (for the purposes of this application) and Data Ready is regarded as BUSY with Data Taken being regarded as /STROBE, it can be seen that once the sequence is triggered with a write to Port B, we actually have just what we’re after. Therefore, I configured the basic code for this mode and tried performing a dummy write to the input port before each character and it works fine. BUSY (CB2) nominally sits high but is set low by the dummy write which then prompts the Centronics interface to send a character and set /STROBE (CB1) low. This both generates an IRQ and also simultaneously sets BUSY high within 500ns allowing the Beeb to read just one character before requesting the next with another dummy write. I haven’t actually scoped the timings yet but it’s 100% reliable and most importantly remains fully Centronics compatible such that the (not easily fooled) Pico Plug can be dropped in to replace the PC printer cable.

I am going to do some more work on the interface to see if I can think of a way to speed up a little because the 6522 handshaking mode is currently slower than I’d like. The speed you’re seeing in the video is about half that attainable because I was using a hybrid Basic/Assembler test program and all-assembler is of course somewhat faster. I’m on with producing a full transfer package but if anyone wants to build a cable and have a play I can publish the test program to show how to control the transfer sequence.

Beeb to Centronics IDC detail.JPG (81.21 KiB) Viewed 14026 times

Beeb to Centronics complete.JPG (32.73 KiB) Viewed 14029 times

[regregex]

Neat work Martin Nice inventive solution on the BBC side, although does it mean the link is one way?

I can see how a serial solution would be harder since the device is of course a serial modem, with a built in modem cable effectively. However if an ordinary Beeb to PC serial cable loops DTR back to DSR and DCD (I think - or is that from the one that blew my drivers up?) then the connection to the Dongle-on-Steroids would just need the appropriate level fed into DTR - plus a power supply on whichever pin (RI?) Although, decades of confusion over RS232 may mean the actual byte-level handshake is done over DSR/DTR instead of RTS/CTS.

I have doubts about the handful of different cable wiring schemes on teh intarwebs as my current cables don't halt the PC sending while the Beeb's buffer is full, and have been meaning to make up a new cable to check my ideas - so I don't speak with authority until then

[MartinB]

Cheers Greg

Yes, currently only one way because I was only really throwing (yet) another transfer-to-Beeb option into the ring which in it's simplest form requires just the adaptor cable and a touch of Beeb software. Once I've done the software, probably as a sideways rom, anyone with an LPT equipped PC and a bog printer cable can use the method without any other expense. Of course, if you do add the Pico-Plug then it's actually a pretty neat way of getting stuff from the Web onto yer Beeb

On the serial side, I shall be exploring that interface and I'm sure the device can be 'fooled' into playing ball. I'm guessing though that it won't be a total doddle because it was really fussy about believing that the Beeb was a Centronics printer which is why I had to stick to the 'rules' for the latter. In fact, when you plug the Pico-Plug into the Beeb, it sits there flashing (meaning "I'm trying to decide what I am") until I run the program and assert the lines correctly to their default states. Unfortunately, the down-side to this gadget is that you don't get much technical data so I don't 100% know what it's full criteria are for determining that it is connected to a valid Centronics or RS232 device but having deduced the former, for the latter I'm expecting that DTR/DSR/DCD are going to be involved. It may indeed be as simple as providing static levels but I'll let you know.

BTW - One nice use I thought of for the serial side is that of a remote keyboard facility in that you could redirect the Beeb's input to RS423 with the BT dongle connected and then with TeraTerm (or similar) on your BT laptop you can sit across the room from the Beeb which is of course in turn connected to and sat under your 52" plasma

[station240]

Ah cool, I was trying to make one of these link cables, only I couldn't get the handshaking to work. Didn't use enough wires by the looks.

Post the code you have, in theory I have all the bits of machine code to make this work. Bought a book on machine code that turns out to mainly cover hardware devices, didn't know it and that time but its what I needed.

There is another style of plug out there, the PCs have D Sub 25 pin on the back. If you get the old printer header cable, and swap the 25 pin socket to a plug, you get a really nice backshell to cover the cable mess. Best of all its a good use for those old XP/AT PCs which are scrap metal anyway.

[MartinB]

Yeah, all PC's with a built-in LPT use the 25-way D-type but I used the Centronics socket so that I could at the end drop in the Pico-Plug. You can make a lead which goes straight to the D-type but assuming most folk have a D-type to Centronics plug lead hanging around, I'd keep your options open and do the lead as I have. For non-parallel equipped PC's (like my netbook) many of the USB to Parallel port adaptors also use a Centronics connector (assuming you'll go straight to a printer) and so again, the Beeb cable is best fitted with the Centronics socket.

Here's the simplest possible driver which I've left as a Basic/MC hybrid and hence is very easy to tinker with. Don't be offended by the verbose comments, just there to help the unfamiliar....

Code: Select all

10 CFLAG=&70:?&70=0                     \character rx'd flag, init to zero

20 CSTORE=&71:?&71=0                    \rx'd character store, init to zero

100 FOR I%=0 TO 3 STEP3

110 P%=&B00                             \code @ $B00 (function key area)

120 [OPTI%

125 LDA&FE6D:AND#&10:BEQ FIN            \test IFR bit 4 for CB1 interrupt which
                                        \is STROBE (lo) - if not exit no action

130 LDA&FE60:STA CSTORE:INC CFLAG       \STROBE (CB1) rx'd, get character from
                                        \Input Reg B, save in CSTORE and set
                                        \rx'd flag (CFLAG) by increment

140 .FIN LDA&FC:RTI                     \IRQ exit duplicating system code

150 ]

160 NEXT I%

170 PRINT:PRINT"Ready..."

200 &FE62=0                             \Data Direction Reg B = 0 = 8 Inputs

210 V%=?&FE6C                           \get a copy of Peripheral Control Reg
                                        \which sets the behaviour of Cx1 & Cx2

220 V%=V% AND &0F                       \clear bits 7-4 (CBn) leaving bits 3-0
                                        \(CAn) untouched

230 V%=V% OR &80                        \Bit 4=0 (CB1:STROBE) which is -ve edge
                                        \and bits 7-5 = %100 which sets CB2 to
                                        \'Handshake' mode

240 ?&FE6C=V%                           \write the CB1/CB2 settings to the PCR

250 ?&206=0:?&207=&B                    \point IRQ2V to our code at $0B00

260 ?&FE6E=?&FE6E OR &10                \Enable CB1 interrupt in IER by setting
                                        \bit 4 (Note bit 7 must be a '1' to do
                                        \this (is set when the IER is read)

300 ?&FE60=0                            \perform a dummy write to the input
                                        \register to initiate 'Handshake'
                                        \sequence

310 IF ?CFLAG=0 THEN 310                \and wait for a character to
                                        \be rx'd by polling CFLAG <> 0

320 PRINT CHR$(?CSTORE);                \print the rx'd character to screen

330 ?CFLAG=0                            \reset chr rx'd flag

340 GOTO 300                            \and goto get next character

I am playing with different handshake methods (e.g using 'Pulse' mode on CB2) to see if I can get a quicker interface because the 6522 Write Handshake does impose some minimum times on the signal transitions. Feel free to experiment

[station240]

Ok I'll see if I can get my hardware interupt machine code and other bits to work with this. In theory it works, but I didn't have a PC to connect it to when I was testing it, so it was tested using aligator clips.

[sorvad]

It's allways amazing seeing what you'll come up with next Really impressed

[MartinB]

Why thank-you Steve

I've done some up-front transfer timings with an optimised all machine-code driver buffering the data without printing to screen and it's achieving about 1378 bytes/sec. Therefore, if we were sending across disc images for on-the-fly conversion and writing to real DFS disc, I think a typical one-game SSD would average about 30 seconds with a fully loaded DSD compilation taking around 4 minutes. A 16k rom image written to disc would take about 15 seconds. Overall then, I guess that's about 30% faster than using RS423 @ 9600 Baud.

A Bluetooth virtual com port accessing the Pico-Plug in parallel Centronics mode is much faster than this so with either a direct LPT cable or via Bluetooth the Beeb 6522 will be the bottleneck and will dictate the speed as above.

[station240]

For a "user port" it sure is painful to program.
I'm sure a device in the 1mz bus would be faster, at the expense of requiring actual electronics. Would be easier to type in the software.

[MartinB]

For a "user port" it sure is painful to program.

Not sure what you mean by that - yes, for any given use the port needs to be set up as required but here, once done, we only do a write to $FE60 to request a byte and an IRQ sync'd read of $FE60 to get the byte.

I'm sure a device in the 1mz bus would be faster, at the expense of requiring actual electronics.

There are of course many ways to control parallel transfer but as ever, I'm trying to offer something that requires only minimal effort and expense such that it remains within the reach of as many people as possible. If we start adding a bespoke hardware interface then it'll just become a curiosity and folk might just as well use one of the many removable media options.

I could write software for the PC end which would directly control the LPT port and improve the speed but in the modern versions of Windows (any maybe other OS), direct hardware control is a little fraught and again this would reduce flexibility.

One the software is finished I will have a system where I throw a disc into the Beeb, type a * command and from wherever I'm sitting with my PC I can send an image over in the backgound and still carry on working in the meantime. Nice, no?

[station240]

I could write software for the PC end which would directly control the LPT port and improve the speed but in the modern versions of Windows (any maybe other OS), direct hardware control is a little fraught and again this would reduce flexibility.

One the software is finished I will have a system where I throw a disc into the Beeb, type a * command and from wherever I'm sitting with my PC I can send an image over in the backgound and still carry on working in the meantime. Nice, no?

You can do that already, just use the obscure dos commands that redirect CON: to PRN: . What you type in dos gets sent down the printer cable. As google sucks I have to go get the dead tree reference book.

I tried the link software with my cable, found two problems.
1) I forgot to put the user 6522 back in, its been borrowed from the dead board only it wasn't today. Only found out after I'd typed all the code in, but carefully placing the chip on the socket and belting it in fixed that.
2) The 20way userport cable has been plugged in upside down, and somehow still worked electrically. Stupid keyed socket and plug don't do their job.

[MartinB]

You can do that already, just use the obscure dos commands that redirect CON: to PRN:

I think you perhaps misunderstood my point. As designed, you can use any PC without any software provided it has a parallel port and you don't even need the latter if the PC has Bluetooth and you add the Pico Plug to the Beeb.

Using the parallel port through the cable is as easy as using copy/b <file> lpt1: in a command prompt window or through real DOS. You can even use Windows if you install a (pre-defined) Generic/Text Only printer and then just drop the file onto that printer. (Although I do need to check that Windows won't add any Linefeeds or Carriage Returns if it sees a $10 and/or a $0D.)

My point about bespoke software at the PC end is that you can use assembler IN and OUT commands (or their high level equivalents) to directly control the parallel port (data lines and control/status lines) when you would no longer be constrained by the Centronics interface protocol which is currently the speed limiting factor. However, I prefer to keep it this way for maximum flexibility and compatibility.

So, even given those two faux-pas, did you get it working? (Although I really don't see how it could have worked with the Beeb User Port connector arse-about-face )

[station240]

You can do that already, just use the obscure dos commands that redirect CON: to PRN:

I think you perhaps misunderstood my point. As designed, you can use any PC without any software provided it has a parallel port and you don't even need the latter if the PC has Bluetooth and you add the Pico Plug to the Beeb.

Using the parallel port through the cable is as easy as using copy/b <file> lpt1: in a command prompt window or through real DOS.

[snip]

So, even given those two faux-pas, did you get it working? (Although I really don't see how it could have worked with the Beeb User Port connector arse-about-face )

Actually you missed my point, which is by redirecting the PC keyboard to the beeb, you can issue extra commands. Might be handy if say you're bbc doesn't have a keyboard and you plan to use it as a L3 file server.

Anyway it didn't work at all once I'd fixed the cabling, so I gave up in disgust and moved the bbc closer to the high end PC with TV capture card I use instead of a TV. I'd put &10 where I should have put &80, plus I'd unplugged the PC half of the conjoined cable and forgotten.

It works now, but I have to upgrade your software so it puts stuff into the keyboard buffer.

[MartinB]

Ah ok, I see what you were getting at

I am well on with the file capture and conversion utilities but I'm away next week so they won't be available for a little while yet but I'm pleased that you have it working now

I'll also separately publish the fundamantal byte capture code in all-assembler so that users (such as yourself) can integrate the fastest possible routine into your own applications. I have tried other methods of upping the speed and have made some headway but I think this (if achievable) will have to wait until the main transfer utilities are finished.

[station240]

I've tried using the machine code version *FX 138 to insert the text into the keyboard buffer. No good its too slow, and the buffer fills up too quickly. Plus it needs to be 100% machine code so the OS/Basic is in control and there to clean out the keyboard buffer as it fills.

Only thought I have at the moment is to populate a big block of memory with the received text, but if you're going to that much trouble, might as well write tokenised basic in directly.

[MartinB]

Since the Beeb software interface uses 6522 Write Handshaking, you/the Beeb are fully in control of the byte flow by virtue of the fact that the PC will only send one byte each time we perform a write to $FE60 - the ?&FE60=0 in my example code. Therefore, you shouldn't need to have any issues with your buffer filling up to fast?

Apologies if I've misunderstood (again ) but I'm guessing that you're writing a Basic program on a PC text editor, then sending it over and using *FX138 to simulate typing the program on the Beeb? If so, you can set up a 255 byte buffer and examine each character as they arrive - if it is not a <cr> or <lf> (depending on how your text editor works) then put the character in the buffer but if it is an end of line then empty the buffer through a *FX138 loop and start again. You have as much time as you like after each character because you won't perform the $FE60 write until your testing/processing is complete.

The issue here as you have alluded to is that you can't simplistically use a Basic program as your interface driver because the incoming program will overwrite it but as I have said, there shouldn't be any buffer overrun issues.

[station240]

Any updates on how the transfer software for this project is going ?

From what I've learned so far, need to keep the keyboard buffer *FX 138 code out of the IRQ function. Is takes many times longer than the IRQ function to run, which results in dropped packets etc.

Only idea I've had so far is to use the hardware timers in the user 6522 as a second interrupt call, and use that to call *FX 138 as needed. I'm sure there is a much better way to do this though, just not sure what it is.