RP2040 replacement for IPC ?

Nagging hardware related question? Post here!
andy_edin
ROM Dongle
Posts: 11
Joined: Wed Aug 23, 2023 9:05 am
Location: Wellington, New Zealand

RP2040 replacement for IPC ?

Post by andy_edin »

Hi,

I've been looking at the IPC and its comms protocol with the ZX8302. I'm wondering if the IPC could be replaced with by an RP2040 with 3v3-5v level converters ? This might allow easier connection of a PS2 keyboard and better serial handling.

The 4/8bit IPC protocol looks fairly speedy (say for an ATMEGA) but the PIO of the RP2040 could work well.

Before I start to get my head around the PIO sub-system, has anyone explored using the RP2040 as a replacement for the IPC ?

Thanks.


User avatar
Pr0f
QL Wafer Drive
Posts: 1563
Joined: Thu Oct 12, 2017 9:54 am

Re: RP2040 replacement for IPC ?

Post by Pr0f »

The protocol itself is basically 1 bit - and given the 8048/9 is not the fastest of Microcontrollers, an ATMega or a PIC could easily do this - so no reason why an RP2040 couldn't handle this.

For me the amazing thing about the IPC is just how much they managed to squeeze into this 2K memory.

It provides keyboard scan (and therefore also joystick)
It provides serial receive function for 2 channels
It provides sound
It's possible that it originally also provided some kind of debug facility using INT7

What ever you replace it with - it will need to do the first 3 of these.


Derek_Stewart
Font of All Knowledge
Posts: 4756
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

Re: RP2040 replacement for IPC ?

Post by Derek_Stewart »

Hi,

Maybe a programmable joystick interface could be implemented.


Regards,

Derek
User avatar
tofro
Font of All Knowledge
Posts: 3123
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: RP2040 replacement for IPC ?

Post by tofro »

Pr0f wrote: Tue Oct 08, 2024 8:28 am It provides keyboard scan (and therefore also joystick)
It provides serial receive function for 2 channels
It provides sound
It's possible that it originally also provided some kind of debug facility using INT7
Unfortunately, it does none of this very well. That's the *less amazing thing*. (Well, it
does mostly work most of the time, maybe that was good enough for Sinclair.

If you look more closely, it becomes obvious that the IPC has never been in the original design and was a late afterthought to be able to get rid of yet another custom chip. Keyboard works rather well, normally, serial is a mess, and the decision to put the simple 1-bit-beeper into the IPC behind a slow serial interface makes the sound capabilities even worse than on the ZX Spectrum. That was a totally anachronistic design decision at a time where most home computers offered 3-channel programmable sound chips.


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
andy_edin
ROM Dongle
Posts: 11
Joined: Wed Aug 23, 2023 9:05 am
Location: Wellington, New Zealand

Re: RP2040 replacement for IPC ?

Post by andy_edin »

Thanks for your quick replies and the background.

I've captured some example comms between the IPC and 8302 on the trace below (brown and red COMCTL and COMData signals - ignore the top reference clock):

Image

Here is the 8301 is issuing a status update command (0x01) to the IPC and the IPC is responding with status byte (0x45). There appears to be one valid COMDATA bit for each two pulses of COMCTL - and the data bit is sampled/valid on the falling edge of the second pulse. For the initial 4 bit command issued by the 8302, there's roughly 5.5uS between pulses (181KHz) - and for the 8 bit reply by the IPC, there's roughly 11uS between pulses (90KHz).

Given the clock rate of the link, I was thinking it would need a hardware input channel - say SPI on an ATMEGA or PIO on a RP2040. I would need to work out how to sample/send data on the rising edge of the second clock pulse for each bit.

Am I on the right lines here - or is there something obvious I'm missing ? :-)


User avatar
dilwyn
Mr QL
Posts: 3112
Joined: Wed Dec 01, 2010 10:39 pm

Re: RP2040 replacement for IPC ?

Post by dilwyn »

In case it helps (if you haven't already seen it) there's a partially commented disassembly of the 8049 on my site:

https://www.dilwyn.theqlforum.com/qlrom/ipc8049.zip

May be of some help to you to know what the code expects by way of timings and signals, maybe.


martyn_hill
QL Wafer Drive
Posts: 1093
Joined: Sat Oct 25, 2014 9:53 am

Re: RP2040 replacement for IPC ?

Post by martyn_hill »

...you'll also find a beautifully comprehensive description of the ULA/IPC 'interface' in the Minerva ROM source, thanks to our friend Mr Reeves :-)


User avatar
Peter
Font of All Knowledge
Posts: 2449
Joined: Sat Jan 22, 2011 8:47 am

Re: RP2040 replacement for IPC ?

Post by Peter »

tofro wrote: Tue Oct 08, 2024 9:01 am If you look more closely, it becomes obvious that the IPC has never been in the original design and was a late afterthought to be able to get rid of yet another custom chip. Keyboard works rather well, normally, serial is a mess, and the decision to put the simple 1-bit-beeper into the IPC behind a slow serial interface makes the sound capabilities even worse than on the ZX Spectrum. That was a totally anachronistic design decision at a time where most home computers offered 3-channel programmable sound chips.
It would have been better to omit the IPC completely, attach keyboard and beeper the Spectrum way and save time-to-market, board space and costs. Just one serial port in that case, but a decent one.


User avatar
Peter
Font of All Knowledge
Posts: 2449
Joined: Sat Jan 22, 2011 8:47 am

Re: RP2040 replacement for IPC ?

Post by Peter »

andy_edin wrote: Tue Oct 08, 2024 5:51 am This might allow easier connection of a PS2 keyboard and better serial handling.
You are aware of SuperHermes (Lite) which already does that?


User avatar
Pr0f
QL Wafer Drive
Posts: 1563
Joined: Thu Oct 12, 2017 9:54 am

Re: RP2040 replacement for IPC ?

Post by Pr0f »

Peter wrote: Tue Oct 08, 2024 9:49 pm
andy_edin wrote: Tue Oct 08, 2024 5:51 am This might allow easier connection of a PS2 keyboard and better serial handling.
You are aware of SuperHermes (Lite) which already does that?
Strictly speaking - not all PS2 keyboards - there are some it won't recognize - it has something to do with the scan code sets and initialization of the keyboard - which is why the SuperHermes boards won't work with a lot of the 'inteligent' KVM switches.


Post Reply