Faster CPU plug in extensions, How?

[Ruptor]

A Pi is not fast enough at memory mapped IO to keep up with the QL's bus speed. Nor does it have enough continuous MMIO to make a sufficient sized word to make transfers efficient.

I hear what you are saying from your experience but I don't understand how an 800 MHz cpu can't keep up with an 8 MHz and not sure what MMIO has to do with it? There might be a problem with the number of IO lines on the RPi but a speed problem. I suppose an experiment would answer the question so I shall have a think.

[Derek_Stewart]

Hi,

It is more likely that there is one one to write the low level device drivers on the QL and Raspberry Pi.

This has been done on a BBC Micro, by using the Tube interface and lot of ARM assembler.codr to make the system work.

What benefits do look for if a Raspberry Pi could be interfaced with a QL?

[Ruptor]

What benefits do look for if a Raspberry Pi could be interfaced with a QL?

Same as any other super charging board speed & RAM plus HDMI, USB and SD card for starters all at very low cost. How much quicker is an RPi Linux emulator than the real QL? I saw some figures somewhere but can't remember.

[Peter]

I hear what you are saying from your experience but I don't understand how an 800 MHz cpu can't keep up with an 8 MHz and not sure what MMIO has to do with it? There might be a problem with the number of IO lines on the RPi but a speed problem.

Firstly, the RPi GPIO, SPI etc. are unproportionally slow, even a standard >50 MHz microcontroller is better in those diciplines. You can not judge things by clock rates etc. but must take into account the gaps between accesses. Secondly, even if the RPi had good throughput on the GPIO connector (which it has not) one needs "hard" realtime performance to emulate a CPU. Which means it must always meet timing constraints under all circumstances, not just in 99.9% of the circumstances. Here comes the second problem, as the RPi usually needs to run an OS to meet expectations. Programming a "hard" realtime system on a bare metal basis is not an easy task, and very restrictive when it comes to the features people are used to from Linux.

(I just say "hard" realtime to make clear that I mean realtime. "Soft" realtime is no realtime, but many don't fully understand that matter.)

[Derek_Stewart]

Hi,

I think that writing an QL emulator, which is writen in C, ported to the RPi is one thing.

Converting the QL emulator to a "Bare Metal" emulator is another totally difference problem. Which I mean, the C code must be re-written in ARM assembly code, which I do not see many people in the RPi world interested in ARM assembler.

In addition to this, how many users of the RPi would take advantage of this type of "Bare Metal" ARM application.

Personally, I like assembly code, but I lack the creativity to perform it correctly.

But I am prepared to have a go, do not expect anything soon, as I am only beginning in ARM assembly programming.

[Pr0f]

I think the issue with the pi is that despite it's speed and graphics - getting it to behave as an accessory such as a video card would not be workable because you can't get memory updates for the emulated QL screen in fast enough.

If the PI took on more of the role of a QL to avoid this issue - using it's own RAM / CPU etc, it would then need to emulate the QL at a hardware level or software level - the software emulation has been done - but making a hardware emulation is a massive amount of work for how many people?

[Peter]

Converting the QL emulator to a "Bare Metal" emulator is another totally difference problem. Which I mean, the C code must be re-written in ARM assembly code, which I do not see many people in the RPi world interested in ARM assembler.

It could still be in C, but once you go "bare metal" most of the luxury is gone.

(When I mentioned emulation in my previous post, I was referring to hardware emulation of the 68008 by the way. Pure software emulation would at least not suffer from the realtime issues.)

[Ruptor]

Personally, I like assembly code, but I lack the creativity to perform it correctly.But I am prepared to have a go, do not expect anything soon, as I am only beginning in ARM assembly programming.

These days optimising compilers are just as good as assembler so it is best to learn how to tweak the compiler to give you what you want.
I asked about RPi bit bashing a while ago for another project and the answer was a maximum of about 25 to 30 MHz which I guess is your point about the I/O being slow but it is still fast enough I think. The timing only has to be critical for each 68K instruction to QL it wouldn't matter if the processor hung around for 1uS in between and it wouldn't matter if the RPi hung around, interrupts disabled, for each instruction since it can easily catch up. I don't know anything about the critical timing points on the QL like you guys do so if you would like to suggest the worst case timing situation I could use that as a test point and see if I have any chance of doing it on an RPi.

[Derek_Stewart]

Hi,

If you are okay with C compiled programmes, then there are 2 QL emulators already, just download the source and compile the emulator.

I do not know how to use the GPIO pins, but I guess it is more mapped.

[mk79]

Did exactly that https://www.kilgus.net/2019/04/21/ql-vga-part-1/ and eventually went another route. It can work, mostly because the ARM-CPU your code runs on is actually only a secondary CPU, the hard part of the hardware initialization including loading of the kernel from SD is done by a master CPU that is part of the chipset. But still, doing hard realtime with a Pi is difficult to program and very badly documented. Also, most PIs don't have enough pins for all bus signals. Also, you need a bunch of voltage converters, of course.