PIC for 8049

Nagging hardware related question? Post here!
User avatar
Ruptor
Gold Card
Posts: 418
Joined: Fri Dec 20, 2019 2:23 pm
Location: London

Re: PIC for 8049

Post by Ruptor »

Pr0f wrote:Hermes is in the flash of the PIC - and I don't think it can be accessed easily - but I haven't tried
What a dipstick I should have twigged the code is in different chips but it doesn't matter to the questions I have asked. :roll: So the hex as well as the source asm doesn't exist then? If the PIC protection bits are not set the ROM could be read I think although I can't remember if one time programmable devices automatically have them set, probably since people want to protect their code.
Pr0f wrote:The other information relating to original IPC or Hermes, and the contents of the ROM (Minerva sources) are well documented enough to re implement the protocol on another device.
Can you point to the asm please? I find it very difficult to find information I want about the QL bits seem to be all over the place. I couldn't find the Hermes stuff just a manual and trying to run uQLX I needed help because there are different versions in different states. Couldn't the Wiki have the stuff? It talks about the Hermes but the actual circuit and code are buried somewhere else. One is supposed to get more patient with age but I seem to be going the other way. :lol:
What is your opinion about one chip doing both jobs, 8049 & ZX8302?


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

Re: PIC for 8049

Post by Pr0f »

you could combine the functions of both chips into something larger - but then it starts to become a question of how much compatibility to the original QL you want to maintain.

Certain things are expected at certain addresses, such as the RTC, Interrupt registers and mask - and the serial write registers - but you could spoof those accesses or even furnish registers at those addresses to provide the same information / function - how much work do you want to do?

Since the access to the IPC is supposed to be done via the trap - mt.ipcom

You should check out dilwyn's site http://www.dilwyn.me.uk/

which will get you Minerva source, tecnical guide and the original IPC code with good notes

In the Minerva source you want to look at M\mt\ipcom.asm and the include files there in - that will give you the general idea of the protocol between the 2 chips - and the commands supported.


User avatar
Ruptor
Gold Card
Posts: 418
Joined: Fri Dec 20, 2019 2:23 pm
Location: London

Re: PIC for 8049

Post by Ruptor »

Thanks I will take look.


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

Re: PIC for 8049

Post by Nasta »

Pr0f wrote:you could combine the functions of both chips into something larger - but then it starts to become a question of how much compatibility to the original QL you want to maintain.

Certain things are expected at certain addresses, such as the RTC, Interrupt registers and mask - and the serial write registers - but you could spoof those accesses or even furnish registers at those addresses to provide the same information / function - how much work do you want to do?

Since the access to the IPC is supposed to be done via the trap - mt.ipcom

You should check out dilwyn's site http://www.dilwyn.me.uk/

which will get you Minerva source, tecnical guide and the original IPC code with good notes

In the Minerva source you want to look at M\mt\ipcom.asm and the include files there in - that will give you the general idea of the protocol between the 2 chips - and the commands supported.
A long time ago I had the idea to make a rather extended 'IPC' which is actually a whole 68008 system with RAM and I/O and interfaced to the rest of the QL using a dual port RAM chip. In fact, the dual port RAM would be used to download code to the 'IPC', which makes the whole thing quite flexible.
A modification of this idea is possible using a suitable MCU. The first 64 bytes of the dual port RAM have a small address re-map scheme. This is done because something like an 8302 uses the same address to read the status of a piece of hardware, and write to completely different hardware. This is of course different from RAM where if you write something to an address, you expect it to be read back from the same address with absolute fidelity.
The address re-map uses the read/write signal as an address of sorts so that when it reads a set of addresses it actually addresses one part of the dual port RAM, while reading from the same addresses as they appear to the CPU, actually reads a different set of addresses in the dual port RAM, so that the read and write functions are separated. The remap works in the opposite way on the other dual port RAM port, so that the addresses that are 'write' on the CPU side, are 'read' on the MCU side, and vice versa.
That being said, the grand majority of the dual port RAM appears as real RAM, just accessible from two sides. The recommended size would be about 2-4k bytes, that would fit nicely in the I/O address area at $18000 without upsetting other things, and also be large enough for advanced stuff like sector buffers. This is because it is conceivable the MCU could be programmed to do quite advanced stuff, like control a floppy dive, and also implement large buffers for serial comms.
It goes without saying that the whole thing can still work using a 68k CPU as the 'MCU', perhaps a 68SEC000. Given that t needs some RAM and ROM, the most efficient single chip solutions for that already imply something like 512k bytes of RAM and Flash, so certainly plenty of space for any software to drive things, the rest depends on what I/O hardware is included.


Post Reply