Tube coding 101! Help wanted please.

bbc micro/electron/atom/risc os coding queries and routines
User avatar
Lardo Boffin
Posts: 2176
Joined: Thu Aug 06, 2015 7:47 am
Contact:

Tube coding 101! Help wanted please.

Post by Lardo Boffin » Sun May 10, 2020 9:44 am

I’m looking for some simple (!!!) assembly code to demonstrate running an endless loop of sending bytes to a raspberry pi (running as a pi not a 6502 co-proc etc.) over the tube and ideally have the beeb check for a response from the pi (but move on if nothing is received, e.g. assume that 0 is no response). Is there such code knocking about anywhere or any tutorials / documents I can read that will explain how to do it? I have a basic grasp of assembly but only basic at this stage!

I’m looking to do something directly on the pi (that listens for bytes from the beeb and may or may not send bytes back) so if there are any example of how this works (ideally in a high level language - I’m only part the way through the Pi Assembly guide I have) that would be fantastic as well thanks!

I know I should do the appropriate research / go through the trial and error process to learn this stuff but I have such limited time I would rather do something productive than figure the basics of what people already know.

Not asking for much I know... :D
Adventure Language on GitHub
Atom, issue 5
Elk
A number of econetted (is that a word?) Beebs
BBC Master, Datacentre + HDD, pi co-proc, econet, NULA

User avatar
BigEd
Posts: 3450
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Tube coding 101! Help wanted please.

Post by BigEd » Sun May 10, 2020 9:50 am

(Edit: just to note, for visitors from the future, this query isn't about the usual setup of wanting to run an application on a Tube-connected second processor. That's usually completely automatic and simple. This is trying to get the Pi to fulfil a different role, but still, possibly, Tube-connected.)

Are you planning to run native ARM code on top of PiTubeDirect running the Native ARM variation of second processor? Or planning to write your own bare-metal equivalent of PiTubeDirect? The former is a great deal easier, but it does raise other questions, because the native ARM code will be running in a second processor context, and the host Beeb or Master will normally be running the usual host code which polls for information coming back over the Tube.

Every second processor has a boot ROM, and if you substitute your own code for that ROM, that's a sort of intermediate position.

But in none of these cases is the Pi running Linux or another standalone OS, so there are facilities like networking which you won't have.
Last edited by BigEd on Mon May 11, 2020 4:10 pm, edited 1 time in total.

User avatar
Lardo Boffin
Posts: 2176
Joined: Thu Aug 06, 2015 7:47 am
Contact:

Re: Tube coding 101! Help wanted please.

Post by Lardo Boffin » Sun May 10, 2020 10:13 am

Thanks! At this stage I am mostly curious as to how it all works.
Ideally as a first stage I would like to send a number to the pi and it shows the number on the screen but crucially it needs to show the output via the HDMI of the pi (and therefore ignore the beeb screen) - if that is possible based on what you have said?
Assuming so then I guess it would be ARM running on the native ARM Co-proc?
Writing my own piTubeDirect is well outside my skill set. :shock:
Adventure Language on GitHub
Atom, issue 5
Elk
A number of econetted (is that a word?) Beebs
BBC Master, Datacentre + HDD, pi co-proc, econet, NULA

User avatar
richardtoohey
Posts: 3986
Joined: Thu Dec 29, 2011 5:13 am
Location: Tauranga, New Zealand
Contact:

Re: Tube coding 101! Help wanted please.

Post by richardtoohey » Sun May 10, 2020 10:15 am

Does it have to be over the Tube? You could use serial for this?

Assuming you are interested in the Tube but asking just in case ... :D

cmorley
Posts: 1320
Joined: Sat Jul 30, 2016 8:11 pm
Location: Oxford
Contact:

Re: Tube coding 101! Help wanted please.

Post by cmorley » Sun May 10, 2020 10:18 am

If you aren't implementing a copro (or not yet anyway) then you can just read/write to the tube memory area FEE0-FEFF (IIRC).

Note if you do it from BASIC with ? you'll get double accesses because BASIC uses LDA/STA zp,Y.

That's how I started with my verilog TubeULA implementation - just echo characters back to the Beeb. Also how the FTDI interface works.

User avatar
BigEd
Posts: 3450
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Tube coding 101! Help wanted please.

Post by BigEd » Sun May 10, 2020 10:59 am

Getting the Pi to do both the HDMI output and the Tube emulation is a bit tricky, although @hoglet did get it working on the Atom tube so there are feasible approaches.

If you want the Pi to be able to indicate what's going on, then the Pi's serial port is a good way to do that. I think you need a suitable adapter to connect the 3.3V serial to a PC's serial port or to a 5V serial adapter.

Writing to the Tube registers from the host might seem like a simple first approach, but those registers don't even exist unless the Pi is already running the Tube emulation in the way that PiTubeDirect does it. It's a delicate dance, between GPU code, interrupt context on the ARM, and the mainline code on the ARM.

If you write native ARM code on the Native ARM second processor, it's all a lot more straightforward. The application running on the ARM is in charge, and all I/O is over the Tube to the host. (Edit: oh, except you do still have the Pi's serial port for debug I/O)

But possibly that's not the universe you're trying to explore.

User avatar
BigEd
Posts: 3450
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Tube coding 101! Help wanted please.

Post by BigEd » Sun May 10, 2020 11:14 am

Parenthetically:

(
There's entirely another approach which might be of interest, which revaldinho has cooked up:
https://github.com/revaldinho/cpc-cplink/wiki

The idea is to use real TTL FIFO chips, so the host really does see a register (or four), and the Pi can run very ordinary code (in Linux even) to push and pull data over the two channels. It's much easier then to construct a homebrew protocol which moves data between the retro machine and the Pi.

I'm not sure there's yet a 6502 compatible version, the original being for z80, but there's no reason why this kind of peripheral couldn't be hooked to the 1 MHz bus.

The thing about the actual Tube connection is that you ideally need an actual Tube chip, and the host will be running Acorn's host code, and that's already some way removed from passing data to a Pi from a program running on the Beeb. (The usual Acorn-envisioned way of using the Tube is that the application runs on the second processor, and the Beeb is spinning in a tight loop running the official host code. You can expand on that, as Rob has and as Tube Elite does, and as Dave has for the Tube Life, but again it gets a bit involved.)

Possibly a good starting point is Rob's recipe for native ARM applications written in C using his library. But it is a different starting point, and I don't want to squash the original idea.
)

User avatar
hoglet
Posts: 9449
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Tube coding 101! Help wanted please.

Post by hoglet » Mon May 11, 2020 11:26 am

In case it's of any use in your experiments, there is an active development branch of PiTubeDirect that includes some frame buffer code:
https://github.com/hoglet67/PiTubeDirec ... s/beeb_vdu

This is actually at reasonably advanced stage of development:
- it's current, i.e. the beeb_vdu branch is a branch of gecko-dev
- it gives you a 640x480 frame buffer (80x40 characters) with a choice of 8/16/32 bits per pixel
- it's using both GPU cores (one for the normal Pi Firmware blob, the other for the Tube handling code)
- it implements a fairly complete set of VDU calls, accessed via a single address on either the parasite or the host
- it includes the additional drawing primitives from Roland's atom_vdu work (circles, rectangles, parallelograms, flood filling)
- the 8-bit per pixel mode allows use of the GPU's hardware palette via standard VDU 19 calls
- full cursor editing on the Pi display is possible with a small amount of parasite side 6502 code, reimplementing OSWORD0. This code is included in memory at startup, but needs to be manually invoked (e.g. CALL &F700).

There still are a few issues, but these shouldn't impact a bit of experimentation:
- the frame buffer mode (8-bit, 16-bit, or 32-bit) is currently a compile-time option
- the V3d Triangle Drawing is broken in the 8-bit frame buffer mode
- too many palette changes in a short period seem to cause the palette to get messed up

To make use of this, you really need to get the GCC ARM tool chain in place so you can build the PiTubeDirect kernel yourself. This is easy to do under linux, which is what I would advise. If you don't have access to a linux machine, I would recommend installing Ubuntu 18.04 in a VM and building on there. If you have Windows 10, it might be possible to use the bash shell, but don't use Windows 10 myself.

If you want to get started with this, I'm happy to help.

Dave

User avatar
BigEd
Posts: 3450
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Tube coding 101! Help wanted please.

Post by BigEd » Mon May 11, 2020 2:24 pm

[Thanks Dave!]

So, to regroup and recap, with a little bit of help from a PM conversation...

The idea is to have the host Beeb (or Master) exchange bytes with a Pi, and have the Pi do video output on the HDMI. So the Pi needs to be running some sort of program, to know what to do, but the main application is to run on the Beeb side. And somehow the Pi needs to be connected to the host.

To move data in one direction, and not drop or duplicate bytes, somehow there has to be some coordination: the receiver needs to be ready, the sender needs to present a byte, the receiver needs to store the byte, and the sender needs to know that the byte has been taken.

When using the Tube connector, you get to run at 2MHz, and the byte will be presented and then withdrawn on a timescale of somewhat less than 250ns, according to the clock and the decoded address. In Acorn's usual setup, there's a Tube chip which operates at that speed, with internal FIFOs, and with status bits so each side can be aware that something happened on the other side. If you don't have a Tube chip, you can use a CPLD, or an FPGA, to do the same thing. In PiTubeDirect, the GPU is just about fast enough to emulate this Tube chip function in real time.

The Tube connector is certainly the fastest way to go, but in addition to the host and the cable and the Pi you somehow need the function of the Tube chip, or something like it. (You also need a level shifter because the host operates at 5V and the Pi operates at 3V. But the level shifter doesn't do any more than shift the levels.)

Because the original idea seems to be to write something on the Pi which does something useful on behalf of an application which is running on the host, there's an additional thing, which is that the host normally sits in the OS servicing the Tube, and programs normally run on the second processor, which is in this case the Pi. So, to stick with this idea, there's more to be done, to have a Pi connected usefully to the Tube, running the software in question, but without acting as a second processor. This is tricky (but not impossible.)

Because of this last point, connecting the Pi to the 1MHz bus might be a simplification. Look to Dominic's project which does just that for some hints.

There is another way, a fourth way: connect the Pi to the User Port. I'm not sure anyone has done this, so that makes it potentially interesting new territory. You still need to build or adapt a level shifter for the voltage difference. But now, you have the VIA (the 6522) to help you. When you put a value on the user port, it stays there. The Pi no longer needs to be running at bus speed to catch a momentary event. You'd use the handshake lines to negotiate transfer of each byte, and (hand wave) to decide whether the next transfer is in the output or the input direction. (Or use the Printer Port for output, and the User Port for input.)

Lots of possibilities, none of them very simple, if you want to build your own project from the ground. Less work to do if you pick up from Dave, Rich, or Dominic.

User avatar
hoglet
Posts: 9449
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Tube coding 101! Help wanted please.

Post by hoglet » Mon May 11, 2020 3:04 pm

BigEd wrote:
Mon May 11, 2020 2:24 pm
Because the original idea seems to be to write something on the Pi which does something useful on behalf of an application which is running on the host, there's an additional thing, which is that the host normally sits in the OS servicing the Tube, and programs normally run on the second processor, which is in this case the Pi. So, to stick with this idea, there's more to be done, to have a Pi connected usefully to the Tube, running the software in question, but without acting as a second processor. This is tricky (but not impossible.)
It's completely possible to make use of the frame buffer on the Pi from the host, without needing to make any changes to PiTubeDirect.

On a Master with an internal level shifter you need to:

Code: Select all

*CONFIGURE TUBE
*CONFIGURE EXTUBE
<Ctrl Break>
*FX 151 230 14
<Ctrl Break>
(There is a good reason for *CONFIGURE EXTUBE even though an internal level shifter is being used).

The Master operates as if there is no Co Processor attached, but crucially the beeb_vdu code framebuffer driver is still active and is waiting for writes to a new VDU FIFO at &FEE2.

The following code on the host will print an "A" on the Pi screen:

Code: Select all

LDA #65
STA &FEE2
RTS
The only caveat is that doing the same with ?&FEE2=65 will not work, because only certain 6502 addressing modes are supported.

You can effectively execute any VDU commands you like by writing the same commands to the VDU FIFO at &FEE2.

If you want to try this out, I've uploaded a complete PiTubeDirect build from the beeb_vdu branch here: dropbox
(this is using an 8-bit/pixel frame buffer).

If the goal here is to go beyond just using the frame buffer, and have sone custom processing code running on the Pi, that would be possible. The simplest approach would be to start with the null Co Processor (link) and design a simple custom protocol that would re-use one of the existing tube registers.

Just to clarify what's going on in the Null Co Processor, the disable_tube() call prevents writes to tube register R1 from happening, so the host doesn't detect a Co Processor. I'm pretty sure that reads/writes to the other tube registers can still happen. So your custom protocol is free to use tube register R2 for example.

Hope this helps.

Dave

User avatar
BigEd
Posts: 3450
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Tube coding 101! Help wanted please.

Post by BigEd » Mon May 11, 2020 3:13 pm

Oh, that's really good, thanks Dave! (A new use for the not-a-second-processor-after-all setting of PiTubeDirect?)

User avatar
Lardo Boffin
Posts: 2176
Joined: Thu Aug 06, 2015 7:47 am
Contact:

Re: Tube coding 101! Help wanted please.

Post by Lardo Boffin » Mon May 11, 2020 3:19 pm

Wow! This is all sounding good thanks. I just need to re-read it several times to try and get my head around it.
Adventure Language on GitHub
Atom, issue 5
Elk
A number of econetted (is that a word?) Beebs
BBC Master, Datacentre + HDD, pi co-proc, econet, NULA

User avatar
jgharston
Posts: 4121
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Tube coding 101! Help wanted please.

Post by jgharston » Mon May 11, 2020 4:38 pm

Tube registers are "standard" byte-with-handshake registers, each port is one 8-bit data port and two handshake bits, TxRDY and RxRDY, see TubePorts.

Writing to a port you'd do:

Code: Select all

.TxLoop
BIT PORT+0
BVC TxLoop ; Wait for TxRDY in bit 6
STA PORT+1 ; Send byte
Reading from a port you'd do:

Code: Select all

.RxLoop
BIT PORT+0
BPL RxLoop  ; Wait for RxRDY in bit 7
LDA PORT+1  ; Get byte
or, more normally:

Code: Select all

BIT PORT+0
BPL go_and_do_something_else
LDA PORT+1
Reading the Tube Host code might give you an insight.

Eg reading:

Code: Select all

\ Tube idle loop
\ --------------
.L0036
BIT TUBES1:BPL L0041          :\ No character in R1, check for command in R2
.L003B
LDA TUBER1:JSR OSWRCH         :\ Get character from R1 and send to OSWRCH
.L0041
BIT TUBES2:BPL L0036          :\ No command in R2, loop back
BIT TUBES1:BMI L003B          :\ Deal with pending character first
LDX TUBER2:STX P%+3           :\ Get command from R2 and index into &0500
JMP (&0500)                   :\ Jump to command routine

Code: Select all

\ Wait for data via R2
\ ====================
(snip)
.L06C5
BIT TUBES2:BPL L06C5  :\ Loop until data present
LDA TUBER2:RTS        :\ Get byte
and writing:

Code: Select all

\ Send byte in A via R1
\ =====================
.L06BC
BIT TUBES1:BVC L06BC  :\ Loop until R1 free
STA TUBER1:RTS        :\ Send byte

\ (snip)

\ Send byte in A via R2
\ =====================
.L0695
BIT TUBES2:BVC L0695  :\ Loop until R2 free
STA TUBER2:RTS        :\ Send byte

\ (snip)
:
\ Send byte in A via R4
\ =====================
.L069E
BIT TUBES4:BVC L069E  :\ Loop until R4 free
STA TUBER4:RTS        :\ Send byte
And it's similar from the Client side.

For most purposes you don't need to be aware of the "depth" of the ports, it's just a byte port with handshaking bits.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.32
(C) Copyright J.G.Harston 1989,2005-2020
>_

User avatar
roland
Posts: 4050
Joined: Thu Aug 29, 2013 9:29 pm
Location: Born (NL)
Contact:

Re: Tube coding 101! Help wanted please.

Post by roland » Mon May 11, 2020 7:26 pm

hoglet wrote:
Mon May 11, 2020 3:04 pm
If you want to try this out, I've uploaded a complete PiTubeDirect build from the beeb_vdu branch here: dropbox
(this is using an 8-bit/pixel frame buffer).
Is this (almost) the same version that I used with the Atom? If so then there is quite a range of VDU commands that are already implemented, like printing text, drawing lines, triangles, rectangles and circles.
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:

User avatar
hoglet
Posts: 9449
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Tube coding 101! Help wanted please.

Post by hoglet » Mon May 11, 2020 7:43 pm

roland wrote:
Mon May 11, 2020 7:26 pm
Is this (almost) the same version that I used with the Atom? If so then there is quite a range of VDU commands that are already implemented, like printing text, drawing lines, triangles, rectangles and circles.
Yes, it includes the extra VDU commands that you added.

It's different in one important respect: where the new VDU registers are in the memory map. If you remember, on Atom Tube we connected up A3, which let the VDU registers be placed at BEE8/BEE9. We can't do the same on the Beeb, because none of the level shifters connect up A3, and in fact A3 is not present on the Internal tube interface as all. So the VDU register is placed at FEE2 (and is currently write-only). So there is currently an unresolved issue with flow control.

Dave

rodders
Posts: 62
Joined: Thu Jun 25, 2020 3:40 pm
Location: Somerset
Contact:

Re: Tube coding 101! Help wanted please.

Post by rodders » Mon Jul 13, 2020 9:15 am

This is interesting stuff! I'm a bit confused about the VDU register though.
hoglet wrote:
Mon May 11, 2020 3:04 pm

The following code on the host will print an "A" on the Pi screen:

Code: Select all

LDA #65
STA &FEE2
RTS
and
jgharston wrote:
Mon May 11, 2020 4:38 pm
Tube registers are "standard" byte-with-handshake registers, each port is one 8-bit data port and two handshake bits, TxRDY and RxRDY, see TubePorts.

Writing to a port you'd do:

Code: Select all

.TxLoop
BIT PORT+0
BVC TxLoop ; Wait for TxRDY in bit 6
STA PORT+1 ; Send byte
As I understand it &FEE2 is the R2 status address and &FEE3 is R2s data address, so should I be writing to &FEE2 as hoglet says or &FEE3 as jgharston says?
Sorry to be a newbie :)
BBC Model B 32k ICL issue 3, WE ROM/RAM board, Speech Processor, TurboMMC, PiTubeDirect
BBC Master 128

User avatar
jgharston
Posts: 4121
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Tube coding 101! Help wanted please.

Post by jgharston » Mon Jul 13, 2020 10:07 am

rodders wrote:
Mon Jul 13, 2020 9:15 am
As I understand it &FEE2 is the R2 status address and &FEE3 is R2s data address, so should I be writing to &FEE2 as hoglet says or &FEE3 as jgharston says?
Sorry to be a newbie :)
In the standard Tube hardware API, even addresses are read-only status ports, odd addresses are read/write data ports (except &x0 which is writable to control the hardware setup). What Hoglet and others have done is appropriate the read-only ports and added write functionality to them to add extra functionality, such as the CPU selection at address &x6.

What port you should be writing to depends on what you're trying to do. Whether there is any flow control on the extra writable ports depends on what has been implemented in the hardware.

The standard ports use b7/b6 of even address for data at odd address, so there are six spare bits for flow control for writing to the status ports. All existing code tests b7 and b6 regardless of the state of b5-b0, so adding bits is highly unlikely to break existing code.

If, for instance, the hardware added a TxRdy bit in bit 5, you would do something like:
PHA
.loop
LDA &FEE2
AND #&40
BEQ loop
PLA
STA &FEE2

The usefulness of having status bits in b7 and b6 is that the BIT instruction reads them directly into the flags.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.32
(C) Copyright J.G.Harston 1989,2005-2020
>_

rodders
Posts: 62
Joined: Thu Jun 25, 2020 3:40 pm
Location: Somerset
Contact:

Re: Tube coding 101! Help wanted please.

Post by rodders » Tue Jul 14, 2020 6:47 am

OK so the PiTubeDirect code repurposes the R2 status address for VDU requests (which is my main interest).
Have the other Tube addresses been assigned to specific purposes?
BBC Model B 32k ICL issue 3, WE ROM/RAM board, Speech Processor, TurboMMC, PiTubeDirect
BBC Master 128

User avatar
BigEd
Posts: 3450
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Tube coding 101! Help wanted please.

Post by BigEd » Tue Jul 14, 2020 9:33 am

(Just to reiterate, this isn't the usual PiTubeDirect code, this is a particular development branch with the extra feature of having a VDU driver that paints to the Pi's framebuffer.)

rodders
Posts: 62
Joined: Thu Jun 25, 2020 3:40 pm
Location: Somerset
Contact:

Re: Tube coding 101! Help wanted please.

Post by rodders » Tue Jul 14, 2020 10:45 am

Yes, I'm aware of that, I've cloned the beeb_vdu branch.
Any thoughts on increasing the frame buffer size to the full Beeb resolution of 1280x1024?
BBC Model B 32k ICL issue 3, WE ROM/RAM board, Speech Processor, TurboMMC, PiTubeDirect
BBC Master 128

rodders
Posts: 62
Joined: Thu Jun 25, 2020 3:40 pm
Location: Somerset
Contact:

Re: Tube coding 101! Help wanted please.

Post by rodders » Thu Sep 17, 2020 11:24 am

I've just fitted an internal tube board to my master and now the beeb_vdu doesn't seem to work any more. Does the internal tube use a different address i.e. not &FEE2
BBC Model B 32k ICL issue 3, WE ROM/RAM board, Speech Processor, TurboMMC, PiTubeDirect
BBC Master 128

User avatar
hoglet
Posts: 9449
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Tube coding 101! Help wanted please.

Post by hoglet » Thu Sep 17, 2020 2:22 pm

rodders wrote:
Thu Sep 17, 2020 11:24 am
I've just fitted an internal tube board to my master and now the beeb_vdu doesn't seem to work any more. Does the internal tube use a different address i.e. not &FEE2
The internal tube uses the same address.

If you are using PiTubeDirect on the internal Tube on a Master, and nothing on the external Tube, then it's actually best to use *CONFIGURE EXTUBE. This setting just controls the order in which the two tube ports are probed; it's always better if PiTubeDirect is on the port that is probed last.

Does the beeb recognise the PiTubeDirect 6502 Co Processor?

rodders
Posts: 62
Joined: Thu Jun 25, 2020 3:40 pm
Location: Somerset
Contact:

Re: Tube coding 101! Help wanted please.

Post by rodders » Thu Sep 17, 2020 2:47 pm

I've tried setting EXTUBE along with NOTUBE but no joy.
The PiTubeDirect VDU Driver displays it startup message but sending output to &FEE2 does nothing. I'm intercepting the OSWRCH vector to send to &FEE2, I don't suppose the vectors are different?
The PiTubeDirect 6502 co-processor is recognised fine and I can run the sphere demo.
I'll try reverting to the external tube and see if that still works.
BBC Model B 32k ICL issue 3, WE ROM/RAM board, Speech Processor, TurboMMC, PiTubeDirect
BBC Master 128

rodders
Posts: 62
Joined: Thu Jun 25, 2020 3:40 pm
Location: Somerset
Contact:

Re: Tube coding 101! Help wanted please.

Post by rodders » Thu Sep 17, 2020 2:52 pm

I'm using a RetroClinic model A internal co-processor board. I don't suppose the level shifters could be the source of the problem?
BBC Model B 32k ICL issue 3, WE ROM/RAM board, Speech Processor, TurboMMC, PiTubeDirect
BBC Master 128

User avatar
hoglet
Posts: 9449
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Tube coding 101! Help wanted please.

Post by hoglet » Thu Sep 17, 2020 2:54 pm

rodders wrote:
Thu Sep 17, 2020 2:47 pm
The PiTubeDirect VDU Driver displays it startup message but sending output to &FEE2 does nothing. I'm intercepting the OSWRCH vector to send to &FEE2, I don't suppose the vectors are different?
Is your OSWRCH intercept code running on the Host or the Co Pro?

If it's running on the Co Pro, then VDU driver address is &FEF8, and the write needs to happen using absolute addressing (e.g. STA &FEF8).

Give me a minute and I'll replicate your setup.

Dave

rodders
Posts: 62
Joined: Thu Jun 25, 2020 3:40 pm
Location: Somerset
Contact:

Re: Tube coding 101! Help wanted please.

Post by rodders » Thu Sep 17, 2020 3:09 pm

I believe my code runs on the I/O processor. I'm redirecting WRCHV (&20E) to my code which simply does STA &FEE2, JMP OSWRCH.
I've just tried ?&FEF8=65 and that doesn't work either.
BBC Model B 32k ICL issue 3, WE ROM/RAM board, Speech Processor, TurboMMC, PiTubeDirect
BBC Master 128

User avatar
hoglet
Posts: 9449
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Tube coding 101! Help wanted please.

Post by hoglet » Thu Sep 17, 2020 3:15 pm

hoglet wrote:
Thu Sep 17, 2020 2:54 pm
Give me a minute and I'll replicate your setup.
OK, I have it running now.

I've tried two different internal level shifters (Kjeill's one and the IFEL one), and both work.

I've just tried two things:

1. From the 6502 Co Processor, "CALL &F700" will initialize the built-in OSWRCH redirector (that supports cursor editing).

2. To test from the Host side, you need to first disable the 6502 Co Processor, but crucually the MOS needs to leave the Tube addresses (&FEEx) pointing to the internal tube hardware. The following should do this, and produce a "A" on the Pi Display:

Code: Select all

*CONFIG TUBE
*CONFIG EXTUBE
<Ctrl BREAK>
*FX 151,230,14 
<Ctrl BREAK>
?&FEE2=65
Dave

User avatar
hoglet
Posts: 9449
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Tube coding 101! Help wanted please.

Post by hoglet » Thu Sep 17, 2020 3:21 pm

rodders wrote:
Thu Sep 17, 2020 3:09 pm
I believe my code runs on the I/O processor. I'm redirecting WRCHV (&20E) to my code which simply does STA &FEE2, JMP OSWRCH.
I've just tried ?&FEF8=65 and that doesn't work either.
A couple more thoughts...

In your redirector, what value is OSWRCH? (If it's &FFEE this won't work!)

What type of Pi are you using?

rodders
Posts: 62
Joined: Thu Jun 25, 2020 3:40 pm
Location: Somerset
Contact:

Re: Tube coding 101! Help wanted please.

Post by rodders » Thu Sep 17, 2020 3:26 pm

That's magic, thanks Dave. I'd forgotten to run the *FX to disable the co-processor.
I must have done this in the past and have been running my code with the external device recently without doing that. Does it remember somewhere?
My plan is to fill in some of the missing functionality in beeb_vdu eventually, I'll let you know how I get on.

I get OSWRCH from WRCHV, i.e. OSWRCH = !WRCHV AND &FFFF

I'm running on a PiZeroW at the moment but I've bought the Model A board so I can upgrade.

Thanks again.
BBC Model B 32k ICL issue 3, WE ROM/RAM board, Speech Processor, TurboMMC, PiTubeDirect
BBC Master 128

rodders
Posts: 62
Joined: Thu Jun 25, 2020 3:40 pm
Location: Somerset
Contact:

Re: Tube coding 101! Help wanted please.

Post by rodders » Thu Sep 17, 2020 3:32 pm

The wiki says *CONFIGURE NOTUBE should do the same as *FX 151,230,14 but that doesn't seem to be the case.
BBC Model B 32k ICL issue 3, WE ROM/RAM board, Speech Processor, TurboMMC, PiTubeDirect
BBC Master 128

Post Reply

Return to “programming”