Engineering mules....

Nagging hardware related question? Post here!
User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Engineering mules....

Post by tofro »

janbredenbeek wrote: I remember that article from QL User, but can't remember whether it actually worked. It apparently doesn't attempt to reset the 8049.
Jan.
Jan,
as far as I remember, this shouldn't be necessary - The 8049 resets itself already when seeing <CTRL><ALT>7 after sleeping for a while. Before that, it issues the level 7 interrupt. What is needed is on the QL side only.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
janbredenbeek
Super Gold Card
Posts: 629
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: Engineering mules....

Post by janbredenbeek »

tofro wrote:
janbredenbeek wrote: I remember that article from QL User, but can't remember whether it actually worked. It apparently doesn't attempt to reset the 8049.
Jan,
as far as I remember, this shouldn't be necessary - The 8049 resets itself already when seeing <CTRL><ALT>7 after sleeping for a while. Before that, it issues the level 7 interrupt. What is needed is on the QL side only.
Well I remember after adding this code the CTRL-ALT-7 code did work better - I've even noted it in the changelog. It's not only the 8049 that gets reset but also the interrupt register at $18021 which need to be written to in order to reset the interrupts.
It might as well be that the code from the QL User article does jump to the same initialisation code (which is just after the memory check).

Jan.


tcat
Super Gold Card
Posts: 633
Joined: Fri Jan 18, 2013 5:27 pm
Location: Prague, Czech Republic

Re: Engineering mules....

Post by tcat »

QL User article does jump to the same initialisation code (which is just after the memory check).
Yes, I think that is precisely what it does, but that is not enough for a full recovery.
I wonder what else is needed, close all channels, save system vars, but how to restore them, other?

EDIT, this what QL Technical guide says
It is also possible to generate a level 7 (non-maskable) interrupt: the treatment of this can be redirected on a per-job basis. Pressing CTRL-ALT-7 on the keyboard generates level 7 interrupt and also resets all communication with the IPC: a suitable handler could be written to perform a warm start on the system to allow partial recovery from a crash.
Full recovery may not be possible.

Tom


User avatar
janbredenbeek
Super Gold Card
Posts: 629
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: Engineering mules....

Post by janbredenbeek »

tcat wrote: Full recovery may not be possible.
True, you don't know what already has been corrupted by the time you press CTRL-ALT-7. It's use is mainly to inspect memory and registers for debugging purposes rather than to give you a chance to save your work after a crash (which you should do regularly anyway).

Jan.


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

Re: Engineering mules....

Post by Nasta »

The first thing to remember is that due to the limitations of a 48-pin case, the 68008 used in the QL has only 2 interrupt pins, but one of them is bonded internally to two inputs, so there is IPL0/2L and IPL1L. The pins are active LOW. IPL0/2 is a bit of a misnomer, as IPL2/0 would have been more intuitive - this pin generates the higher interrupt levels with respect to IPL1L.
Therefore, on the QL interrupt levels 2 (IPL1L = L), 5 (IPL2/0 = L) and 7 (NMI) (both IPL lines = L) are implemented.

Now things get complicated because the 8302 ULA only has one interrupt output pin, and it is tied to IPL1L. The IPC has 2 pins tied to an interrupt line each. The problem is that the 8302 is not aware of the IPC pins so strange combinations can happen which must be taken care of in the software.

As far as I remember, CTRL-ALT 2, 5 and 7 are all implemented in the IPC (though this may depend on the version), and were used in some sort of debug mode to cause the corresponding level interrupts. Other than that, ALL normally used interrupts on the QL are level 2, and are generated by the 8302. Because the 68k CPU is level sensitive as interrupts go, when an interrupt is handled, part of the handler must find out what the actual interrupt source was, and clear and handle that interrupt. Not clearing it (via the already mentioned interrupt register in the 8302) will just cause re-interrupting the CPU as soon as it comes out of interrupt processing.

Here is where things get complicated - the IPC communications are also handled via interrupt. Hence, when something like CTRL-ALT-7 occurs, if the IPC resets itself, there might be an interrupt condition left hanging inside the 8302, which needs to be cleared 'blindly'. The reason for this is the IPC sets both IPL lines low and waits for a while to insure the CPU recognizes them. However, because there is no way to mask interrupt level 7 (except implicitly when the CPU enters the interrupt 7 handler), it may well be expected that the interrupt handler may be invoked repeatedly while the IPC keeps the interrupt lines low, as there is no way to tell it (easily) to reset them high unless the IPC is re-initialized in the handler routine (which will release the interrupt lines).
That being said, things are much more complicated with interrupt level 5. This is normally ignored by the OS but because (again) the 8302 is not aware of the IPL lines on the IPC, under certain circumstances a level 2 interrupt can be generated (say, if the MDV is spinning or frame interrupt occurs) which will make the 8302 pull down the IPL1 line indicating it wants a level 2 interrupt serviced, but because the IPC might be keeping IPL2/0 low, this will now turn into a level 7 interrupt - and make a mess.
It may well be possible (though I have not tested this) that key roll-over (for example CTRL-ALT pressed, while pressing 4 and 5 simultaneously) may result in the above condition as CTRL-ALT-4 is a regular key-press and will be signaled via IPC comms through 8302 IPL1, and then IPL0/2 will occur when 5 being pressed is detected.

The main problem here is within the IPC, the fact it re-initializes. Unfortunately I have no idea how Hermes does it (no doubt much more clever), but a look into Minerva code might shed some light.
It is a pity the interrupt levels are not properly priority encoded, having a well controlled higher priority and a non-maskable interrupt would be a nice addition to the OS.
Last edited by Nasta on Fri Nov 17, 2017 12:33 pm, edited 1 time in total.


User avatar
janbredenbeek
Super Gold Card
Posts: 629
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: Engineering mules....

Post by janbredenbeek »

Hi Nasta,

Thanks for the extensive explanation, though I have one small correction: IPL1 generates interrupt level 2, not 1. The original 68000 had three lines IPL0, 1 and 2, corresponding to the binary equivalent of the interrupt levels. On the 68008 IPL0 and 2 are tied together giving Level 5 when IPL1 is not active and Level 7 when IPL1 is active.
As for CTRL-ALT-5, as far as I remember this never did anything, not even crash the QL. The vector is hardcoded to point to a RTE, even in Minerva.
With Hermes fitted, the key combination to generate a L7-interrupt has been changed to CTRL-ALT-ESC-7. There is an IPCEXT command to set P23 low which will generate a permanent L2 interrupt but not one to set P22 low (which would generate L5 or L7).

Jan.


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

Re: Engineering mules....

Post by Nasta »

Yes of course, level 2 - I have corrected the text.
I have seen the error but for some reason could not edit the post (keyboard input ignored) until I restarted the PC...
Are there extended IPC operations to reset the IPL pins?


Post Reply