Could you plug a pi into a matter cartridge slot?

[tricky]

I don't know why, but I was wondering about plugging a pi into the cartridge slot of a master, or I guess an electron.

Why, will you can't have too many pis connected to your Beeb

It might seem overkill for mass storage, but it could also communicate or run code a little like the serial tube bad Apple demo by cmorley.
I can't remember if sound input is available in the cartridge port.

[davidb]

Something like myelin's Elk PiTubeDirect?

[Marvin]

I can't remember if sound input is available in the cartridge port.

If I Remember Correctly...

On an Elk it's a simple no.

On a Master yes but it's only as an analogue signal to be mixed into the audio circuitry feeding the speaker, the host CPU is completely unaware of it.

On both machines the computer's sound output is available there for a cartridge to use.

[tricky]

I meant sound input the the master's amp as an output from a cartridge - but worded very badly.
A bit like ElkPiTubeDirect, but I was only thinking of it looking like a rom or two from the master/elk side.

[RobC]

I've been thinking about something like this for a while. Either as a kind of "every ROM" board or as a way of getting better sprite/graphics performance via dynamic code generation using load imm, store abs etc.

[rharper]

I have a Pi + level shifter connected to a Tube cartridge on an Electron, an AP5 would also do the trick.
Ray

[rmbrowngr]

I have a Pi + level shifter connected to a Tube cartridge on an Electron, an AP5 would also do the trick.
Ray

The AP5 provides a Tube port for this to work. I would think you would need to provide the Tube in the cartridge on the Master to connect a Pi.

[sydney]

Would it need to work via a tube interface? Would it be possible for the pi to appear as 32k of sideways ram that both it and the elk/master can read from and write to.

[tricky]

I've been thinking about something like this for a while. Either as a kind of "every ROM" board or as a way of getting better sprite/graphics performance via dynamic code generation using load imm, store abs etc.

That is kind of where I was going, especially perf wise on the Elk, but you could probably include the the 1MHz bus PI type extras albeit with patched ROMs, as well as speech and maybe a 6522 for the ELK.

I know all this can be done on the PiTube (well not sound without a flying lead), but I like the idea that it is it's own ROMs and that the window for directly executing code is 16K instead of 32 bytes.

The electronics is above me and I would never get around to writing the code, so I feel a little awkward even suggesting it, but, well we all like to say "what if" now and again.

[davidb]

I suggested the Tube board because it's one way to use a Pi via a cartridge - at least, on the Electron.

I experimented with other ways to use a Pi, though they were quite slow. The idea was to be able to run a fairly standard OS on the Pi, rather than just bare metal code, so that other facilities like networking could be used. It would be fairly straightforward to use the Pi's video out and turn it into a simple graphics and sound card.

I tried the bare metal approach with a Teensy 3.1, and kernelcrash made an STM32F4-based non-cartridge board that pretends to be sideways ROMs. I think the Pi could be made to handle ROM accesses with bare metal code given that its CPU is much faster than the ones on these boards. The problems with this approach are that it ties up the Pi with just pretending to be ROMs, and it needs a lot of level shifters.

The Teensy code I wrote could fairly reliably return 16 bytes of data from its own ROM or RAM, though it wasn't doing much address decoding. However, I thought about other solutions where the Teensy, Pi or something else could return the first few bytes of a ROM which would contain code to talk to the board via a simpler, slower interface. Then you would have the advantage of plug-and-play without the need for a separate filing system ROM. It would be slow, but it could download code into RAM and run it. I thought that approach might be worthwhile for bootstrapping other systems.

[BigEd]

Might be worth noting that the 1MHz Pi system has the advantage of only needing to keep up with a 1MHz bus. The Pi Tube system has to keep up with a 2MHz bus, and that's tricky, but fortunately it only has to pretend to be a few Tube registers. A cartridge slot would also be a 2MHz access. Whether a Pi could keep up while serving a selection of ROMs, I'm not sure: any cache misses on the Pi and it's game over, so the amount of sufficiently-fast cache might be the limiting factor. This is dp11's territory!

[mr-macrisc]

On elk I imagine it could do 1mhz bus and tune pi as both buses were avail as cartridges. In master I am less sure as they already have those buses so may clash with same on cartridge?