On the BBC Micro, the byte after the BRK instruction held the error number, followed by the error message string terminated with 0x0D. CALLing the address of the BRK instruction would cause an error to be raised.
Update with example, as a runnable BBC BASIC program:
10 DIM b% 32
20 ?b%=0: REM BRK
30 ?(b%+1)=42: REM Error number 42
It seems the diagrams are not accurate. I wrote a test program that traces INT1 invocations (and delays execution during INT1 to increase the chance of getting hit by timer interrupts) while executing the following machine language fragment:
mov ax, 300h ; 100h = TF; 200h = IF
popf ; This instruction sets the trace flag
Without issuing a CLI, no further interrupts can occur (until EOI, at least, where flags are restored by the RTI instruction). As this is a raster interrupt, you need to acknowledge that as well for another one to happen, which the seemingly benign $D019 manipulation achieves earlier in the interrupt handler, cf. the linked FLI routine.
In this specific ...
was there a risk that the user program had left the stack pointer close to wrapping round, so that the interrupt itself (which pushes three words onto the stack) or the code running in the interrupt would overwrite part of the stack segment?
Yep. The 8086 required space to put 6 bytes on the stack:
The processor status
The current instruction pointer
The BRK instruction on the MOS 6502 seems to be one of the more ill-documented features of the processor. [...]
Given the lack of documentation about this
It is documented quite well and in depth in the corresponding MCS 6500 Microcomputer Family Programming Manual of January 1976 (and all follow ups). Check page 144 and after for description, reasoning ...
In a 100% compatible PC, NMI is used only to communicate unrecoverable errors — normally a RAM parity failure, but possibly something else, which should reveal itself via one of the system control ports, specifically you should check:
b4: watchdog timer status;
b6: channel check failure (i.e. a bus failure, likely a peripheral device);
An I/O device will monitor IORQ, M1, and the address bus to determine whether to respond to an I/O cycle. As soon as the CPU negates IORQ the I/O device will stop responding. This ensures the CPU is always in control of how long an I/O device is driving the bus.
If an I/O device continued to drive the data bus after IORQ was negated then it would be a ...
You're correct; the only interrupts on offer in a Vic-20 are those from a VIA — they're plain old 6522s in the Vic-20, not 6526s. The original VIC chip exposes the current scan line via a couple of registers so instead you'd perform a busy loop until it got to the number you wanted, then cue the VIA.
I'm not a C64 expert but besides the lack of hardware ...
As indicated by e.g. this description of the Phoenix BIOS, possible NMI sources are
Memory parity errors
x87 Coprocessor errors
I/O card NMI (for whatever reason the I/O card decides to invoke it)
DMA bus time-out errors (AT only)
Additionally, the Programmable Interrupt Timer (PIT; 8253 or 8254) could generate an NMI using a watchdog and possibly also on ...
The First Part Done bit is used to signal whether a specific part of an instruction (the "first part") is done already or not.
It is only set on instructions like ILDB ("Increment and load byte") and ILDW ("Increment and load word") that address a pointer to a byte/word in memory, increment that pointer, and then fetch the byte or word that is referenced ...
We need to distinguish here between the "stack," which is a data
structure in the imagination of the programmer, and what the CPU does
with stack registers and the memory pointed to by them, which is a
mechanical process. When the CPU pushes a value on the stack it simply
changes the values in the stack pointer register and certain memory
locations; whether ...
The SOS operating system written for the Apple /// used BRK for operating system calls. The byte following the BRK holds the OS function number.
Of course, the two bytes after that are also used as inline data, so you can argue that it's not a true example of BRK with a signature byte. Still, it's an example of "real world" code using inline data after a ...
The 0xDD does not allow an interrupt to happen after it's been fetched, no matter what comes next in the instruction stream.
As Wayne Conrad pointed out, otherwise the CPU would have to time travel into the future to find out what instruction is going to get fetched.
You might want to consult the chapter for 'Interrupt Response' of the CPU manual (Chapter 8 on p.55 of the 1976 issue) and 'Interrupt Servicing' from the PIO manual (Chapter 6 on p.15 of the 1977 issue).
In general the Z80 supports 3 different interrupt modes:
Mode 0 - like 8080, here the interrupting device must place an instruction on the bus - usually ...
The 6502 is designed to be used in systems with devices that may need to cause an interrupt. The way this is accommodated is by having each device use an open-collector/open-drain output to drive the /IRQ pin, which is passively pulled up with a resistor. If any device wants the /IRQ pin low, it will be low. Only if no device wants it low will it be high.
Yes, games like Rescue Raiders and Silent Service used interrupts to queue music and sound effects while other things were happening on the screen. Perhaps the best example of the technique is Skyfox, which had music playing during the frenetic dogfight action.
The option to have simultaneous graphics and great sound without cycle-counting was one of the ...
The 8254 system timer calls interrupt 08 at regular intervals (18.2 times per second by default), and the latter calls interrupt 1C which is the one you should hook into. You hook into this in the standard DOS way: store the current address at vector 1C, place your routine's address there, and make sure you chain to the previous address from your routine. ...
On the IBM PCJr, the NMI was used by the keyboard device to signal the CPU.
(Source: “The Peter Norton Programmer’s Guide to the IBM PC”, chapter 3, under “Changing Interrupt Vectors” while discussing CLI)
Interrupt Mode 2 is not a ZX Spectrum feature, it's a feature of the Zilog Z80 CPU itself.
Per Raffzahn@'s comment, the answer to your question kinda depends on what kind of threading you're talking about.
There are generally two levels of abstraction when it comes to multithreading, and two meanings of the term. First is the hardware level Simultaneous ...
Not simultaneously, as it only has one CPU, but it has a 50 Hz timer interrupt, so it can do time sharing processing, provided that programs are well behaved, as there is no memory protection and no supervisor mode in the CPU.
As a proof of concept, I've written a small task scheduler and tasks that are executed in a time sharing fashion (with a 20ms ...
As I know it probably do not any effect on IRQ routine. Or do it?
No, it does not. Well, it does, but that depends.
Before entering an interrupt routine the interrupt disable flag (I) is set, preventing the CPU from accepting other interrupts so it can setup the environment needed to do its job without being interrupted again. Basically an implied SEI, ...
The original IBM 5150 Personal Computer (the IBM PC) connected the Non-Maskable Interrupt to the I/O Check signal, which could be driven by an add-in card, or by the on-board memory. If the systems memory detected a parity error, it would trigger a NMI, and the systems software would halt the machine and display an on screen error. You can read about this in ...
All of the popular, early 8-bit CPU's support hardware and software interrupts. Therefore, they can all theoretically support preemptive multitasking, which I think is what this question is really asking.
The relevant article from Wikipedia states:
In simple terms: Preemptive multitasking involves the use of an interrupt mechanism which suspends the ...
Based on my findings above, it seems that there is no need to identify the IRQ source in interrupt handlers, or at least it is not a regular practice. Why?
Because there are no unknown/unexpected interrupts?
The C64 is a rather simple machine, originally developed as a game console. Later usage is still much like one. C64 software assumes to be loaded as ...
To save space and execution time (and partly of necessity, cf. below), interrupt handlers are typically set up for the context they are used in with assumptions on expected system interrupt sources.
If you were to set up a context in which you might be receiving interrupts from both the VIC (maybe raster or sprite collision interrupt) and a CIA (maybe a ...
In the original PC/AT Architecture, the FPU exception signal that should be connected directly to a dedicated input pin on the main CPU and should appear as INT 10h gets re-routed by glue logic to the second IRQ controller so that it appears as IRQ 13 (i.e. INT 75h) instead. Most of the other conflicting vectors are of such a nature that the hardware-defined ...
The VIC keeps the CPU interrupt line activated until the cause for the interrupt is acknowledged, so if you don't tell the VIC which of the interrupts are now handled it won't release the CPU interrupt line and CPU keeps executing the interrupt routine.
I have looked this video - Altair 8800 - Interrupt Acknowledge Cycle and have few questions (I have read wikipedia Intel 8080 article, Altair 8800 Operator's manual, Charles Petzold "Code" and few article on the internet, like this and didn't found answer yet):
Maybe to start with the obvious: Not every device needs to be interrupt driven.
Altair 8800 ...
1 I/O port <> 1 hardware device
1 RST vector <> 1 interrupt from one device
You have read the datasheet under false assumptions.
There is no such thing as a 1:1 correlation between these concepts.
Actually, I/O devices that hold only one single I/O port are pretty rare. A typical floppy controller, for example, the WD1772, has four registers (...