Pi Compute Module

RISC OS built into an NEC display? https://www.raspberrypi.org/blog/compute-module-nec-display-near-you/

I have been dreaming of creating a board that would take the Compute Module and turn it into an upgrade-able micro computer for quite a while now (basically a Compute Module, SATA or mSATA on board and all the connectors on the back-edge to allow for a neat little case). Essentially it would get around the fact that the existing Pi has connectors coming out all over the place. I guess the trick would be to get it small, working and cheap enough for general users to buy. Then I also guess that the 700MHz ARMv6 is probably not really great for most of the user base (who realistically would end up running Linux on it…). Maybe I could build it into a keyboard? :—)

How compatible is RISC OS Pi with ARMv6 in the Compute Module? I wonder if future versions with have an ARMv8 like the Pi 3…?

How compatible is RISC OS Pi with ARMv6 in the Compute Module?

Fully:-) IIRC RISC OS need slight tweaking because the EMMC behaves slightly different to an SD card.
We and numerous other Forum posters had RISC OS running on a compute module a few weeks after it was available!

n.b. I think NEC are only going to offer it on their 40"+ monitors aimed at video signage etc. It would be nice in all monitors and TVs!

I wonder if future versions with have an ARMv8 like the Pi 3…?

Yes, I believe there’s a BCM2837 version of the compute module in the works.

n.b. I think NEC are only going to offer it on their 40"+ monitors aimed at video signage etc. It would be nice in all monitors and TVs!

I doubt they’d offer it for their consumer models. SBCs are small and lightweight enough for people to be able to easily mount them to the back of a TV/monitor themselves. In the office we’ve even used velcro to attach small computers (mac minis and similar) to the back of TVs.

In the office we’ve even used velcro to attach small computers (mac minis and similar) to the back of TVs.

Odds on you could fasten a Pi or beagle to the mount bracket points with four strips of Meccano.
Or going really cheap four strips cut from a tin can with appropriately drilled holes, or maybe lolly sticks…

Yeah I can definitely see the logic behind NECs decision.

A couple of jobs ago we used to use a Pi strapped to the back of a TV to display a corporate video at trade shows. The TV we used had a built-in video player but it had a massive delay every time the video looped through whereas the pi just kept it looping without any pause.

My dream would be to rebuilt an adaptor board (with 74LVC245) to interface with the podule expansion connector of my real Archimedes 440, dropping my old motherboard and replacing with this one (The compute module has enough GPIO ports to get datas and addresses at good place, adding also other necessary signals)… Then, the trick would be to reimplement software to use existing podules…

Then, the trick would be to reimplement software to use existing podules…

Ah, now there you hit difficulties.

The motherboard circuit diagrams are available via “Chris’s Acorns” if I remember correctly, so replicating that functionality is a electronic engineering task.

USB to IDE interface for your disc drive.

Then your problem with figuring out what the code is in/with the podule boards and making it 32bit or reverse engineering the whole podule and building an equivalent.

Of course you could just emulate the 440 on a Pi, and mount the Pi inside the 440 case.

Alain, what existing podules would you like to use?

There would be no point in doing it for USB, RS-232, SCSI or a printer port, for example. In fact I can’t right now think of any existing podule that would be useful. I hope you will enlighten me!

(MIDI is on its way.)

The compute module has enough GPIO ports to get datas and addresses at good place, adding also other necessary signals

You will need, I think, 42 GPIO lines to support a basic IOC podule.

But that’s not the hard part. The hard part is going to be sorting out the timing and how those signals behave with respect to each other. That’s why early machines talked to the IOC and the IOC talked to the podules. In this way, one writes bytes to word aligned addresses and these become podule accesses.
Details are here: https://www.chiark.greenend.org.uk/~theom/riscos/docs/expspec.pdf

Then, the trick would be to reimplement software to use existing podules…

Let’s ignore the 32 bit issues and look instead at how you would:

• Provide reliable 8MHz and 2MHz clock signals
• Read/write the hardware according to the clocking (the offset from podule base address specifies the speed of access).

I could sort of imagine allocating some memory in the podule address range and having it abort when accessed which your abort handler will use to talk to the podule via GPIO and pass up the data as if actual hardware was used, but I don’t see how you can assure that the timing of everything is bang-on. Remember, your podules will be relying upon the timing provided by the host.

So I’ll echo Dave and repeat:

Alain, what existing podules would you like to use?

…

or a printer port, for example.

Does RISC OS work with a USB to parallel port dongle?

And to reply to something much earlier:

but it had a massive delay every time the video looped

At work we have a fairly recent laptop running Ubuntu plugged into a big flat panel TV (something in the order of 40"). It provides employee information and promotional stuff in a sort of Powerpoint slideshow.
What should I comment on first?
The fact that for some utterly unknown reason the TV is connected by VGA and is set to 800×600. I mean, damn, this thing has to be at least FHD.
Or maybe the fact that, like every PowerPoint slideshow ever, it has animated effects – like text being unrolled over top of a picture, or stuff sliding in from the side. It hiccups, it misses stuff, it drops frames like crazy. It’s really quite awful. I actually wonder if it would work better if it was recorded to an mp4 and simply played in a loop using VLC. I’m not sure if it’s the computer that is struggling (why, it isn’t that old!) or if the slideshow app used with Ubuntu is just rubbish.

And to the top… NEC have a 98" monitor. Which translates to two metres sixteen by one metre twenty one (screen size), with a resolution of 3840×2160 (60Hz). Or, to ram home the size of that thing:

[looks at pictures shown: ho ho, what is that – Skytree and Omi Jingu?]

Does RISC OS work with a USB to parallel port dongle?

Nobody uses a printer through a parallel port these days.

Gutter strapping is probably cheaper than Meccano. Let’s be honest.
With all that talk about using a parallel module it’s what I call going full circle. I go through it regularly before concluding that something is pointless.

I like the idea of a compute module based board. I tried something like it with a Pi zero with a right angle GPIO header, which was plugged into a strip board prototyping HAT, which also had an RTC, OLED, and I2S DAC.
It seemed like a great idea until it came to plugging in the Pi. USB, and especially HDMI was its undoing. Besides obvious fabrication issues it would have worked nicely with a compute module.

Nobody uses a printer through a parallel port these days.

Oh, I’m sorry. I must have missed the RISC OS drivers for the plethora of USB printers available these days…

And if someone really did want to start using a parallel printer port, it would be far more sensible to use GPIO pins directly, and write a replacement Parallel module. This would be far easier and have much more chance of working correctly.

And if someone really did want to start using a parallel printer port, it would be far more sensible to use GPIO pins directly

Such as this one?

and write a replacement Parallel module.

…on the resources tab on the above linked product page.

Oh, I’m sorry. I must have missed the RISC OS drivers for the plethora of USB printers available these days…

There are the same drivers available as in the good old parallel times. Whatever Gutenprint supports, and PCL and PostScript.

And, IIRC, there was a USB-parallel adapter available for the IYONIX back in the Castle days. Again IIRC, I think it worked fine for all printers supporting the SPP, but not those that needed EPP/ECP or other bidirectional stuff.

Is there a list of those printers which are known to work via the GPIO-Parallel adaptor but which don’t work through a USB-Parallel adaptor?

From first-hand experience I do know that USB-Parallel adaptors are still being bought (and used) both by RISC OS and non-RISC OS users for use with legacy parallel port printers.

Nobody uses a printer through a parallel port these days.

Lexmark still make at least one current model printer (mono laser with PCL & PostScript) that has a parallel port!
We supply them to RISC OS users still using Risc PCs/A7000s etc.

Colour me amazed that people are still using parallel ports.

Nevertheless, if someone’s starting with a Raspberry Pi, I still think it makes sense to use the GPIO pins and an appropriate Parallel module.

My original question to Alain Lowet still stands unanswered: what existing podules would you like to use?

Of course it would need USB driver support, but I just spent a good 20 seconds on AliExpress to search for “USB parallel port” and found quite a few adapters for around $AUD5.

Of course it would need USB driver support, but I just spent a good 20 seconds on AliExpress to search for “USB parallel port” and found quite a few adapters for around $AUD5.

Most ‘well behaved’ USB-Parallel adaptors are already supported, aren’t they? Plug one in and up pops a window from !Printers asking you which Printer Definition File you’d like to use with it

The compute module has 45 lines available to do the task of connecting a simple podule (without B pins), 2,4,8 Mhz will be produced by an external oscillator on the interface board along with the necessary 74LVC245 to make the level transitions.
/S4 signal and LA21 will also be generated through GPIO’s along with the other CTRL signals.
I agree there will certainly be problems on timings, but i think it could be achieveable. The reason is simple for me, i am really in love with my ARC 440 (the design, the inside, etc…), and i want to continue to have a very same feeling but with new technology, so using my old keyboard, my old mouse, and my old podules (user ports, midi ports, etc…)

By the way, i found a very interesting Compute Host board by waveshare wich is extended in regards of the original RPI one, and contains lot’s of goodies that could be useful at a time (e.g. an ardion uno compatible connector, ADC’s, RTC clock…)
Just give a look and your opinion, have a nice day everybody!

i want to continue to have a very same feeling but with new technology, so using my old keyboard, my old mouse, and my old podules (user ports, midi ports, etc…)

Nostalgia is a powerful thing (I say, listening to an online radio station that only plays music from the ‘80s (hmm, I wonder if they’ll ever play anything by Jackson ever again?)).

However you are going to have to accept some compromises as technology moves on. For instance, forget ADFS floppies. USB drives can’t understand them.
As for MIDI, I created a module that has more or less the same API as the old Acorn one (basically because Maestro is the only music software I have), and Dave has picked it up to add many improvements and enhancements. To this end, if you want to use a MIDI device with RISC OS, it’s as simple as plugging in the USB lead (or a serial adaptor). As for the user port, is there a multi I/O “hat” for the Pi? Probably, but it’s not something I’ve looked at. Anyway, assuming there is, it just needs some interface software to make it look like something RISC OS can understand.
[Edit: I’m thinking of something like this: https://www.sparkfun.com/products/14148]

Wait, hang on… User ports, MIDI… You don’t mean the AKA10 do you? That thing was MASSIVE!

Oh, yes, and i totally forgot an important point for me, as you know, the Broadcom Soc is a very versatile computing device, the GPIO’s can be programmed in several ways (a least five different mode are supported), and, on the other hand, i like also the DIN41612 connectors available on the podule bus, that are real connector contrary to all those ‘end of cards’ connectors. So my idea is to use the middle line of the connector to pass specific signals from the Broadcom CPU, to open the way for designing new cards… Trying to have: best of both worlds :-)
I know it sounds technically difficult, but why i understand that the ARC had a IOC, an MEMC, a VIDC, don’t underestimate de capabilities of the Broadcom chip who has also a lot of integrated capabilities…

and…yes…i admit, AKA10 is on my list ;-)