PDA

View Full Version : Interrupts and 8080



pavery
September 11th, 2016, 05:45 PM
Hi all

I wish to know how interrupts are handled, if at all, under CP/M on an 8080. On this system which I'm implementing CP/M, keyboard scanning is done on the Int 7.5, so a return address can be plonked on the stack at anytime. Now with the scenario of a user program using the stack & SP in any way they want, enabling interrupts all the time maybe unwise.

This brings me to only enabling them during bios operations, specifically Conout & Conin, and using my own 'bios' stack. However, how would a ctrl-c work and break out of a program if it wasn't updating display or accepting input? MBasic springs to mind, one has to be able to break out of a loop and interrupts wouldn't be enabled in this instance.

Many thanks
Philip

Randy McLaughlin
September 11th, 2016, 06:15 PM
Hi all

I wish to know how interrupts are handled, if at all, under CP/M on an 8080. On this system which I'm implementing CP/M, keyboard scanning is done on the Int 7.5, so a return address can be plonked on the stack at anytime. Now with the scenario of a user program using the stack & SP in any way they want, enabling interrupts all the time maybe unwise.

This brings me to only enabling them during bios operations, specifically Conout & Conin, and using my own 'bios' stack. However, how would a ctrl-c work and break out of a program if it wasn't updating display or accepting input? MBasic springs to mind, one has to be able to break out of a loop and interrupts wouldn't be enabled in this instance.

Many thanks
Philip

In the 8080 world interrupts are a hardware function not to be confused the software restarts (rst). Interrupt controllers for 8080's often use software restarts for isr's which can be a problem because lower RAM that rst's use are usually CP/M reserved addresses.

CP/M is non-reentrant. Interrupts under CP/M are user discretionary, they are sometimes used in special application environments (process control etc). They can be used for print spooling and other I/O functions but CP/M must not be aware of them since it is non-reentrant.

MP/M on the other-hand can be run w/o interrupts but then it is a dog.

So for CP/M if you want to develop interrupt drive software go for it but don't call CP/M functions inside your isr or expect big headaches. You can handle the stack by having your own but be very very careful.

Mbasic has a polling loop so it does not use interrupts - just checks the keyboard while running.


Randy

Chuck(G)
September 11th, 2016, 06:27 PM
INT 7.5? Are you sure that you're not running an 8085?

I've done interrupt-driven CP/M BIOSes where almost everything was interrupt-driven--disk, screen, keyboard, printer and time-of day. It can be done. It helps some if you have a PIC (priority interrupt controller) vectoring the interrupts, although a Z80 using IM 2 would be nearly as useful--the idea is to keep the various interrupts separated and prioritized.

Basically, if you're only to use a couple of registers and are high priority, you can use the user's stack. However, if you're going to push the entire register set, it's best to set up your own private stack. Your ISR typically will have interrupts disabled, so you don't really need to worry about any other code barging in and corrupting your stack. You can even be clever and spawn a task to be performed after the interrupt is serviced, but before control is returned to user program--for example, as a "print screen" function.

As far as Ctrl-C goes, CP/M treats it as a special character, in they keyboard stream. No special preempting of processes involved.

pavery
September 12th, 2016, 12:09 AM
Yes, silly of me Chuck, it's actually an 8085.

That answers my question - it'll be cleaner & simpler to have INT 7.5 enabled only in my Conin routine as I'm making use of ROM routines that do keyboard scanning & flashing cursor. Plus, safest to have my own stack for this.

Thanks guys, my thoughts have now crystallised.

Dwight Elvey
September 12th, 2016, 05:45 AM
Yes, silly of me Chuck, it's actually an 8085.

That answers my question - it'll be cleaner & simpler to have INT 7.5 enabled only in my Conin routine as I'm making use of ROM routines that do keyboard scanning & flashing cursor. Plus, safest to have my own stack for this.

Thanks guys, my thoughts have now crystallised.

What funny business are you doing on the stack that would make
it dangerous to have an interrupt?
The whole idea of a stack is to treat it as a LIFO. The only
issue is then stack overflow.
Dwight

Chuck(G)
September 12th, 2016, 08:21 AM
...and it's simple enough to create your own private stack for interrupts. It's a little tricky for nested interrupts, but not difficult (only the lowest-priority interrupts gets to set/release the private stack).

Dwight Elvey
September 12th, 2016, 09:58 AM
...and it's simple enough to create your own private stack for interrupts. It's a little tricky for nested interrupts, but not difficult (only the lowest-priority interrupts gets to set/release the private stack).

How does one do that?
An interrupt comes in and pushes stuff on the stack.
The return address will always be pushed.
How do you stop that?
Dwight

Chuck(G)
September 12th, 2016, 11:25 AM
Yes, but that's it--just the return address and probably the AF pair. Subsequent "nested" higher-priority interrupts don't affect the user's stack.

If there's not enough room for 4 bytes on a user stack and said user didn't disable interrupts, I submit that the user is fatally short-sighted. I can't recall a single instance of a commercial application that behaved so badly.