Trying to find HW register details

[MIST]

Hi!

I'd like to understand some of the details regarding the QLs hardware in order to re-implement it in HDL.

Some registers like the mc_stat registers are a) pretty simple and b) sufficiently documented and it was rather trivial to implement the video logic based on the available information. The attached image shows what i get on a tv screen using only some ram, rom, cpu and the video controller. But to proceed i need to understand some more parts ...

But I am missing the details of the the interrupt register and the registers used to talk to the ipc. Unfortunately the emulator sources for e.g. uqlx are not very helpful as they patch rom routines rather than implementing the hardware.

I am sure there are people having the missing knowledge here. So what do the bits in the interrupt controller byte do? How is an irq acknowleged or cleared? By reading the register (that's at least what uqlx does)? But the rom routines only service one interrupt per call, so clearing all irqs will cause some to be lost. But at least that approach partly works and i see the frame irq handler being called and also the 8049 handler. But i don't even know if a key being pressed should trigger the "interface irq".

Also the IPC RD and WR registers are somewhat unclear: It seems the 5 bit command (4 command bits and another 1 bit) seem to be written via bit 1 at 18003. Bits 2 and 3 are set to 1. What do these mean?

It's a rather funny experience to implement a machine that i haven't even ever seen in real life.

Any help is appeciated and any result will be published as open source.

[dilwyn]

Hi Mist,
Welcome to QL Forum.
I'm afraid I don't have the knowledge to help with this particular query, but my website does have a lot of documentation files to download, including the official tech documentation:
http://www.dilwyn.me.uk/docs/hardware/index.html and
http://www.dilwyn.me.uk/docs/manuals/in ... techguides

Apart from uQLx sources, you might also get insight from the SMSQ/E sources for the QL, from Wolfgang Lenerz's website at http://www.wlenerz.com/smsqe/

Another source of some scanned books is a Spanish site http://sinclairql.speccy.org/archivo/docs/docs.htm

There are some unscanned books such as the QL Advanced User Guide by Adrian Dickens (publisher: Adder, out of print but occasionally available second hand) and QDOS Companion by A. Pennel (publisher: Sunshine, also out of print but commonly available second hand).

Good luck with the project - the QL is still quite a fascinating machine to work with.

[Paul]

Wow! I'm afraid I also can't help in any way. But I would really love to see the QL on a MIST board.
I would immediately buy one!
Are you documenting you progress somewhere?
kind regards Paul

[tofro]

art from uQLx sources, you might also get insight from the SMSQ/E sources for the QL, from Wolfgang Lenerz's website at http://www.wlenerz.com/smsqe/

Even better (Because not blurred by non-QL hardware) are the Minerva sources available from Dilwyn's site.

Some stuff is also in this thread: http://theqlforum.com/viewtopic.php?f=19 ... ter#p10612

and here
http://theqlforum.com/viewtopic.php?f=2&t=894

Judging by your nick - are you in any way related with the Atari MIST project?

Tobias

[MIST]

Hi,

the MESS sources actually contain the best explanations i've seen so far:
https://github.com/mamedev/mame/blob/ma ... e/zx8302.c

Doing IRQ handling the way these comments suggest seem to be ok. Next will be to decode the IPC requests to be able to reply with keycodes. In the end it would probably the best to add a HDL 8049 and run its firmware.

And yes, i am the one who built the MIST. I am trying to implement a QL for the MIST but i won't promise that i'll ever finish it. I am still trying to figure out how complex this is and whether it's worth the effort.

The IPC commands (and their replies) are documented best in the 8049 sources i've read.

I am not sure if i'll document anything separately. A HDL implementation actually is already a nice way to document hardware. And a running system based on it by itself proves that the description is to a certain extent complete and correct.

[tofro]

OK. First "Welcome!", second: "Hey, good to have you here", third: "Sounds like a plan"

Let me see what else we have:

And yes, i am the one who built the MIST. I am trying to implement a QL for the MIST but i won't promise that i'll ever finish it. I am still trying to figure out how complex this is and whether it's worth the effort.

Got one at my desk at home Great work done so far. And no, it can't be complex HW - It's Sinclair, after all And: Anyone here will tell you: It's definitely worth the effort

There's a reasonably good explanation of how IPC comms works in the Minerva sources:

* Communication with the IPC is done using the following bit serial protocol.

* Commands and data are sent msb first, by writing a byte containg %11x0 to
* location pc_ipcwr ($18023), where the "x" is one data bit. Bit 6 at location
* pc_ipcrd ($18020) is then examined, waiting for it to go zero to indicate
* that the bit has been received by the IPC.

* Receiving data from the IPC is done by writing %1110 to pc_ipcwr for each bit
* of the data, once again waiting for bit 6 at pc_ipcrd to go to zero, and
* then reading bit 7 there as the data bit. The data is received msb first.

* The reason behind effectively sending a one bit for each read is the way the
* hardware functions. There are only two wires between the PC and IPC to work
* with, and only one is bi-directional. Even this is limited, in that either
* end can force it to zero, but both ends must agree to make it a one. Hence
* when the PC is trying to read data from the IPC, it must be asserting a one
* in order to see whether the IPC is returning a one or zero bit.

* Note: pc_tdata ($18022) is where full 8 bit data bytes are sent for serial
* output, with the PC interrupting whenever it is ready for more.

Now some description of the 8302:

* The peripheral chip is selected by addresses in the range $18000 to $1bfff.
* The hardware does not decode bits 13-7 and 4-2 of addresses, so the following
* are actually the minimum addresses that perform the given functions.
* On some older ql's, bit 6 is also not decoded, but later m/c's distinguish
* the mc_stat register by decoding it as having bit 6 set.
* It could be unwise to assume that bits 13-7 can be anything but zero.
* It would be novel to redefine the $1800x versions by adding $1c, thus making
* the whole set more conveniently addressable.

And some description of the Interrupt register:

*************** pc_intr is read to supply the current set of pending
* interrupts, and is written to clear them and/or enable some of them.
* sv_intr [tofro: that's a system variable shadowing pc_intr, as its contents cannot be read]
holds the current setting and is managed carefully, on a bit basis.
* The three msbs must be set to enable their corresponding interrupts.
* On read, bit 7 is the baud rate clock, pulsing up and down once per bit.
* Bit 6 is normally set, but is clear while an mdv is running. dunno why...
* Bit 5 is the lsb of 1/65536ths of a second, i.e. straight x2 crystal.
* The five lsbs are set on read to indicate which interrupts are pending and
* writing a set bit will clear such an interrupt once it has been serviced.
* At boot, $1f is written here twice, then $c0 is put in sv_intr to start off
* with transmit and IPC interrupts enabled.
* The second write of $1f, one gathers, is because a bug in the h/w sometmes
* causes the first one to fail.
* The IPC interface interrupt deserves a mention. It was useless, and was
* ignored on Minerva until v1.94. Then Hermes finally got it right, and uses it
* to signal serial input buffer data ready (every 8 bytes).
* It actually also happens whenever data transfer goes on between the CPU and
* the IPC, which could be a problem for people who do not use mt.ipcom, but
* all internal routines clear this interrupt before returning.

If you have more specific questions, I'll go and dig deeper

Regards,
Tobias

[MIST]

Excellent information. Especially about the interrupt register.

I have some basic keyboard stuff running and f1 and f2 now sort of work and I can get to the main screen.

I am still missing information on the bit 3 in the first nibble returned in the answer to ipc command 8. This seems to be 1 on key press and 0 on key release. But is that always valid for all up to seven keys returned? So several key presses can be sent as well as several key releases? But not a mix?

And finally I am searching for a map of all the keycodes. It seems I can find it in the sources of the uqlx emulator. But a real map would be helpful as well just in case you have one ...

Once I can type in commands I'll post a core here for those of you that have a mist. So far I get this red or red/white screen but no cursor. Maybe it's waiting for some not yet existing hardware....

[M68008]

AFAIK that bit is set if there is any key down on the keyboard.
The other 3 bits are the number of keypresses (not releases, regardless of bit 3) being sent from the IPC buffer.

The QL manual has a keyboard map, but be careful, my manual was an early one and had major errors.

The cursor starts appearing once you send interrupt 2 at 50 Hz.

What is a mist? Sounds interesting! Official link?

Btw, if you find out the interrupt 2 timing inside the VDA cycle, I'd be interested in that information!

Thanks,

Daniele

[tofro]

What is a mist? Sounds interesting! Official link?

Daniele,

MIST is an FPGA-based "anything"-computer that started as an Atari ST on FPGA.
https://code.google.com/p/mist-board/

It has evolved from there and can now emulate quite some 8- and 16-bit computers beyond the ST from ZX81 to the Acorn Archimedes. It's about time that it gets to know how to do a QL

Tobias

[tofro]

Maybe there is a minor misunderstanding in what the IPC does - IPC function 8 sends a stream of keypresses - Never releases (Or, rather, full press/release cycles). Bit 3 only tells the computer that the last keypress in the stream that you just received is still being held down (that's used for auto-repeat only, to my knowledge). If that last key is then released, the IPC will just send it again without bit 3 set. So Bit 3 only applies to the very last key you've seen. All other information is keys that have been pressed and released thereafter.

Erm, whether the IPC continues to send that last key being held down until it's released, I honestly don't know (but would somehow assume that). Maybe someone else does.

In case the OS really wants to see key presses and releases, it will use IPC function 9 (Direct matrix read). But that's incredibly slow......

Tobias