8302<>8049 communications...

Nagging hardware related question? Post here!
User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: 8302<>8049 communications...

Post by Dave »

I apologize humbly. I made a typo. I am trying to replace the 8049. Not the 8032.

I am looking to do this with an ESP32S. It is TTL friendly as output, and is 5V tolerant on some inputs. That said, a simple level shifter is justified. The keyboard matrix will happily run off 3v3. Serial can be moved to a UART. BEEP can be recreated.

The 8302 is also replaceable, but requires more work. We don't need to worry about serial or microdrives. The QLNET is useful. Clock and reset functionality is critical but trivial to shift off.
Last edited by Dave on Wed Feb 07, 2018 10:37 pm, edited 2 times in total.


User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: 8302<>8049 communications...

Post by Dave »

Pr0f wrote:That's slightly cheating as it has a couple of voltage translators on board. However, Dave is gifted in the hardware design area, so a 3.3V i/O based FPGA with some form of input conditioning, or a 5v tolerant device such as the device used in the QL_SD board (Lattice 4000 series?) - I know that's a CPLD, but the 4128 and 4256 have a good number of macro cells for building logic from.
It's not cheating! :P

Also, I would not say I am gifted. I would say Nasta was gifted.


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

Re: 8302<>8049 communications...

Post by tofro »

Dave wrote: The QLNET is useful.
The 8049 is not involved with QLNET.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: 8302<>8049 communications...

Post by Dave »

tofro wrote:
Dave wrote: The QLNET is useful.
The 8049 is not involved with QLNET.
I did, of course, mean the 8302! I jumble them up a LOT. Both four digit numbers beginning with 4 and having a 0 in the middle. I see the 8049 as a simple IO expander for the 8302.

(Note: I mixed them up in this post too, and rechecked it before posting!)


User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: 8302<>8049 communications...

Post by Peter »

Pr0f wrote:
Peter wrote:
Pr0f wrote:There are a number of small FPGA boards arround that could probably fill the role of the ZX8302/8049 as a combo and be plug in compatible to the 8302 socket.
Examples would be welcome! I don't know any available FPGA board with 5V tolerance. Let alone a board which is small enough to plug into that DIL socket.

Peter
https://shop.trenz-electronic.de/en/Pro ... nik/GODIL/
Thanks. An FPGA board with level shifters indeed. Although I don't think it would be useable (price and dimensions).

I had at some time considered an FPGA board for th 68008 socket, allowing decent video, but the level shifter / space issue made it problematic.


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

Re: 8302<>8049 communications...

Post by Pr0f »

Peter wrote:
Pr0f wrote:
Peter wrote: Examples would be welcome! I don't know any available FPGA board with 5V tolerance. Let alone a board which is small enough to plug into that DIL socket.

Peter
https://shop.trenz-electronic.de/en/Pro ... nik/GODIL/
Thanks. An FPGA board with level shifters indeed. Although I don't think it would be useable (price and dimensions).

I had at some time considered an FPGA board for th 68008 socket, allowing decent video, but the level shifter / space issue made it problematic.
Yes - it's a nice idea, but with a limited number of pins - 40 or 48 and no access to the other pins on the FPGA, it does limit functionallity to what you can put in the FPGA. But the module does allow power and ground to be selected for several pins, so it will replace any 40 pin or 48 pin device. Dimension wise, they aren't much bigger than the DIP footprint they plug into.

But it's a good way of replacing / enhancing a ULA in an old retro machine...


User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: 8302<>8049 communications...

Post by Dave »

I have some 5v tolerant ispMACH 4000v devices - but there's an ever growing selection of level shifters... Also, resistor dividers for input or transistors for output can be very cheap these days. However, the device I chose is tolerant to 5.5v if run off 3.6v and 5.2v if run off 3.3v.


Nasta
Gold Card
Posts: 443
Joined: Sun Feb 12, 2012 2:02 am
Location: Zapresic, Croatia

Re: 8302<>8049 communications...

Post by Nasta »

My question here would be, what parts of the 8302 (and through it the IPC) are actually used on the application level.
After all, we do have SMSQ/E running on various hardware platforms that do not have an 8302 nor a 8049 and as far as I know these are not strictly emulated.

MT.IPCOM is a great example as I wonder how often it is used in applications - and I would bet mostly in OS extensions like Toolkit II etc, as there are higher level OS calls that may use it to produce sound or check keyboard rows for pressed keys.
As strange as it may sound :) I am convinced that changes to OS code to 'emulate' parts of the hardware specific code to target different hardware is less complicated to do than exactly replicate existing hardware, which actually is.. well, not really a perfect design, to put it mildly. For instance, there is an OS call equivalent to the Sbasic 'keyrow' function which is what you would call to check for pressed keys in an application, not go directly communicating with the IPC.
Other parts of code such as serial port and even microdrive drivers are also replaceable with completely different code when a different hardware is used to implement them (as we would perhaps want to, given the limited capabilities of the original hardware). This is never directly addressed by applications.
As far as I know, the only part of the 8302 hardware that is actually accessed on the hardware level is the 4-byte second counter that implements the real time clock function, and that is read only.


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

Re: 8302<>8049 communications...

Post by tofro »

Nasta wrote: MT.IPCOM is a great example as I wonder how often it is used in applications - and I would bet mostly in OS extensions like Toolkit II etc, as there are higher level OS calls that may use it to produce sound or check keyboard rows for pressed keys.
MT.IPCOM actually is the only way to do those two things (keyboard direct scan, joystick input, BEEPing) in an at least somewhat HW-independent way, even on SMSQ/E. All the QL gamers would be quite unhappy without this call (not abstracting these two things is actually a serious omission in SMSQ/E, as all newer QL derivates had to at least somewhat emulate IPC communications in order to implement direct keyboard scan and sound. Even the Q68 does it.
Nasta wrote: As strange as it may sound :) I am convinced that changes to OS code to 'emulate' parts of the hardware specific code to target different hardware is less complicated to do than exactly replicate existing hardware, which actually is.. well, not really a perfect design, to put it mildly. For instance, there is an OS call equivalent to the Sbasic 'keyrow' function which is what you would call to check for pressed keys in an application, not go directly communicating with the IPC.
There's no such thing as an OS abstraction of KEYROW. But it rather should, I agree.
Nasta wrote: Other parts of code such as serial port and even microdrive drivers are also replaceable with completely different code when a different hardware is used to implement them (as we would perhaps want to, given the limited capabilities of the original hardware). This is never directly addressed by applications.
As far as I know, the only part of the 8302 hardware that is actually accessed on the hardware level is the 4-byte second counter that implements the real time clock function, and that is read only.
Most of serial and even microdrive code sits behind an abstraction layer. Programs that do microdrive direct sector access (so is everything that checks copy-protection), however, have to access the hardware directly. But running copy-protected microdrives is maybe not a thing that happens often nowadays ;)

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: 8302<>8049 communications...

Post by Peter »

Nasta wrote:My question here would be, what parts of the 8302 (and through it the IPC) are actually used on the application level.
At first glance I'd say: Realtime clock, microdrive for copy protection, and (although it makes no sense) keyboard direct hardware access in very few games.
The Q68 does not implement the latter two in hardware.

Peter


Post Reply