Engineering mules....
Engineering mules....
Does anyone know of any early hardware prototypes of the QL ?
Any add on boards - for instance, what ever the CTL ALT 7 intercept device was, was it only software, or was there hardware for that too?
Just curious to know what is out there...
Any add on boards - for instance, what ever the CTL ALT 7 intercept device was, was it only software, or was there hardware for that too?
Just curious to know what is out there...
Re: Engineering mules....
My guess is the debugging device was software only (Some specific ROMs). I have, however, never heard of any of such versions that would have survived. So I'd guess another time and assume these ROMs were made on the go when looking for a specific problem and later discarded.
Tobias
Tobias
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
-
- Font of All Knowledge
- Posts: 4031
- Joined: Mon Dec 20, 2010 11:40 am
- Location: Sunny Runcorn, Cheshire, UK
Re: Engineering mules....
Hi,
The only solution to CTRL ALT 7 was in Minerva and Superhermes.
I can not remember any hardware that would perform interception.
Maybe a project for the future.
The only solution to CTRL ALT 7 was in Minerva and Superhermes.
I can not remember any hardware that would perform interception.
Maybe a project for the future.
Regards,
Derek
Derek
Re: Engineering mules....
Was the code to allow redirection of the CTRL-ALT-7 interrupt not present in earlier ROM's then?
From the 8049 disassembly it seems to stop all interrupts in the 8049 IPC, and then go into a double loop of counting down before restarting the IPC, but it does set that Interrupt IPL2 line, which with the IPL0/1 would give you the non maskable interrupt. I did wonder if there was a hardware address watcher that sprung into life when that vector was read... - similar to rom paging that Sinclair did on the ZX interface 1
From the 8049 disassembly it seems to stop all interrupts in the 8049 IPC, and then go into a double loop of counting down before restarting the IPC, but it does set that Interrupt IPL2 line, which with the IPL0/1 would give you the non maskable interrupt. I did wonder if there was a hardware address watcher that sprung into life when that vector was read... - similar to rom paging that Sinclair did on the ZX interface 1
Re: Engineering mules....
Hi, just wandering what is the line, ZX8302 uses to raise `mdv gap interrupt' to MC6800.
IPL1?
There was a code handling NMI-7 `warm reset' published in some magazine, I have corrected.
http://qlforum.co.uk/viewtopic.php?f=3& ... warm+reset
It clears the screen, jumps to some init vector, and enters S*BASIC main loop. It seems the only way to reset IPC, too.
As it resets system vars, it would be interesting to also save a snapshot of system vars to fully recover from a QL crash.
Tom
IPL1?
There was a code handling NMI-7 `warm reset' published in some magazine, I have corrected.
http://qlforum.co.uk/viewtopic.php?f=3& ... warm+reset
It clears the screen, jumps to some init vector, and enters S*BASIC main loop. It seems the only way to reset IPC, too.
As it resets system vars, it would be interesting to also save a snapshot of system vars to fully recover from a QL crash.
Tom
Re: Engineering mules....
Although it does interrupt IPC comms and screw up keyboard access for a period of time, it should be possible for the interrupt handler to resynch it by discarding all the current work, which would mean any open serial ports, any current keyboard requests, any sound being produced...
I think the only reasons it screws up the IPC comms is that the 8049 goes back to an 'as started' state, and the poor old QL doesn't do the same. So a cleanup on the QL side, and then re-establish IPC comms should work.
I think the only reasons it screws up the IPC comms is that the 8049 goes back to an 'as started' state, and the poor old QL doesn't do the same. So a cleanup on the QL side, and then re-establish IPC comms should work.
Re: Engineering mules....
Yes, it would be a nice exercise.
As for QL ROM development archetypes, I remember seeing some collected by Urs Koening at one of his sites, at least I think they may be the prototypes you look for.
Tom
As for QL ROM development archetypes, I remember seeing some collected by Urs Koening at one of his sites, at least I think they may be the prototypes you look for.
Tom
Re: Engineering mules....
The simplest you can do is have QMON loaded in your QL - That redirects the level 7 interrupt into the debugger.
Tobias
Tobias
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
- janbredenbeek
- Super Gold Card
- Posts: 637
- Joined: Wed Jan 21, 2015 4:54 pm
- Location: Hilversum, The Netherlands
- Contact:
Re: Engineering mules....
It's used to read the microdrives - when a gap on the tape passes the head the interrupt is triggered so the 68008 can read in the sector or sector header.tcat wrote:Hi, just wandering what is the line, ZX8302 uses to raise `mdv gap interrupt' to MC6800.
IPL1?
It's also used for the 50Hz interrupt - QDOS only uses Level 2 interrupts which is the IPL1 line on the 68008. The IPL0-2 line raises Level 5 interrupts which are ignored by the ROM, and when both IPL0-2 and IPL1 are activated a Level 7 interrupt is triggered.
I remember that article from QL User, but can't remember whether it actually worked. It apparently doesn't attempt to reset the 8049.There was a code handling NMI-7 `warm reset' published in some magazine, I have corrected.
http://qlforum.co.uk/viewtopic.php?f=3& ... warm+reset
It clears the screen, jumps to some init vector, and enters S*BASIC main loop. It seems the only way to reset IPC, too.
As it resets system vars, it would be interesting to also save a snapshot of system vars to fully recover from a QL crash.
I have dealt with this in my MULTIMON monitor by duplicating part of the initialisation code from the ROM:
Code: Select all
EXINTL7 MOVE.L A3,-(A7)
LEA $18020,A3
SF -$1E(A3)
MOVE.L #$061F0000,(A3)
MOVE.B #$1F,1(A3)
MOVE.B #1,-$1D(A3)
MOVE.L (A7)+,A3
JSR SAVREGS
LEA INTL7MSG,A1
BRA.S MAINERR1
Jan.