How are Interrupts handled by the Atom❓

[Louis.m]

Please HELP, I'm stuck

Doing some research concerning the way in which the Atom reacts to an IRQ (Interrupt ReQuest) I didn't get any further than the following:

1. On an IRQ signal (at pin 4) the 6502 jumps to the address found in #FFFF-#FFFE, this is #FFB2.
2. There the processor basically finds the instruction JMP (#0204), contents of #0205-#0204 is #A000.
3. At #A000 the processor finds a value of #40 whits is a RTI (ReTurn from Interrupt).

This can't be all there is to an interrupt . . . What am I missing

I have but one source for this: the three volumes of "Atomware".
Is there any other (more thorough) documentation about the way IRQ (and NMI) are handled by the Atom

[IanS]

On a basic atom, nothing uses interrupts. So just an RTI sounds fine. Anything that needs interrupts will modify it as needed.

[Louis.m]

On a basic atom, nothing uses interrupts. So just an RTI sounds fine. Anything that needs interrupts will modify it as needed.

Sorry Ian, but that's not a very helpful answer.

I don't think, a 6522, a 6821 or an 8271, when plugged into the Atom bus, "magically" starts working.
The Atom needs an Interrupt Handler of some kind and I like to know how that works and want to learn how to program/modify such.
That's why I like to have more documentation about the Atom concerning this subject

[IanS]

I don't think, a 6522, a 6821 or an 8271, when plugged into the Atom bus, "magically" starts working.

The dos (for 8271) or econet rom will install their own interrupt handler when initialised. An unexpanded Atom doesn't need an interrupt handler, so RTI is enough to stop the machine hanging if anything does generate an interrupt.

There is no software support for the 6522 to generate interrupts, and you have to specifically add LK2 if you want to even see interrupts from the chip. You then need to add your own handler.

[roland]

Ian is right, on the default Atom no interrupts are used. On a very basic, unexpanded Atom there isn't even any device that can generate an interrupt. So every program that needs interrupts will need to set up its own IRQ (or in case of DOS or NETwork NMI) handlers.

There is a (Dutch) article about interrupts on the Atom at https://site.acornatom.nl/documentatie/ ... 846012.gif Maybe that is a good start for understanding interrupts.

[Louis.m]

Sorry guys, you're both pointing at the fact that a default/basic/unexpanded Atom does not need/uses IRQs, but that's no answer to any of my questions.

On a basic atom, nothing uses interrupts. So just an RTI sounds fine. Anything that needs interrupts will modify it as needed.

How does it modify and to what ?

Ian is right, on the default Atom no interrupts are used. On a very basic, unexpanded Atom there isn't even any device that can generate an interrupt. So every program that needs interrupts will need to set up its own IRQ (or in case of DOS or NETwork NMI) handlers.

There is a (Dutch) article about interrupts on the Atom at https://site.acornatom.nl/documentatie/ ... 846012.gif Maybe that is a good start for understanding interrupts.

I am familiar with the article in AN 1984 nr.6 that Roland mentioned, but that is not much more than a resume of (a part of) the info about IRQ and NMI that is present in Atomware and some schematics of a switch connected to the IRQ (or NMI) line of the Atom Bus (PL6/7) with a little program to detect the state of such a switch.

It doesn't deal with the case in which IC1 (the 6522), LK2, IC50 (a 74LS244) and/or a printer are installed/connected,
let alone when Big Benny is also present (and don't forget an Eprommer) !
Besides, the article is incomplete because the twice mentioned table is missing . . .

What I am interested in is how IRQs are/can be used and handled in an Atom,
more specific, I like to have info (application examples) about subjects like:

• Which technique(s) is/are actually used in an Atom (polled, programmed,
  interrupt driven, direct or a hybrid like interrupt driven polling).

• How is detected which peripheral/controller is generating an IRQ.

• How are conflicts avoided in case of simultaneous IRQs.

• How did Acorn dealt with priorities of multiple IRQs.

• Are routine addresses auto-vectored, bus-vectored, non-bus-vectored, or else.

• Are any interrupts masked and if so which, when, why and how.

• Etcetera . . .

I admit that it is quite a list of, sometimes deeply technical, questions,
but I like to have these answered so I might be able to design some I/O.

[1024MAK]

• Which technique(s) is/are actually used in an Atom (polled, programmed,
  interrupt driven, direct or a hybrid like interrupt driven polling).

For systems where there is no interrupt hardware, or it’s not used, then the only options are polled. Either regularly as in a loop, or intermittently.

Where suitable interrupt hardware exists and the software has been written to use it, then this will be interrupt driven.

There are two main types used in 65XX systems:

A simple timed type where the hardware just pulses the processor interrupt pin. This can work well if there is only one hardware device that can create an interrupt. The software puts in place an interrupt subroutine, which does whatever is needed. then a return instruction gets the processor back to the main program.

The more complex system where the processor has to acknowledge the interrupt source. This is normally considered essential if there are multiple interrupt sources in a system. Normally with this system, the device that wants attention activates and maintains the interrupt signal. The interrupt subroutine then has to check each possible hardware I/O device by reading a status register to find out which one is the source of the interrupt. Depending on the particular hardware, either reading the status register or reading or writing to another register will acknowledge the interrupt, the device will then deactivate its interrupt line, thus removing the interrupt signal to the processor. The interrupt subroutine will then perform whatever other actions (if any) are required, then return to the main program.

Which system is used very much depends on a number of factors, including cost, what chips are available for the task, speed of operation and what other tasks the processor needs to do.

• How is detected which peripheral/controller is generating an IRQ.

By testing a register in each I/O device that may be generating the interrupt.

• How are conflicts avoided in case of simultaneous IRQs.

Assuming there is no priority hardware (see *1 note), by the order in which the interrupt subroutine checks the I/O devices. If two interrupt sources simultaneously signal at the same time, whichever gets checked first gets serviced. Then the next, and so on until all have been serviced.

*1 note: priority can be handled in hardware, but this means more circuitry, which costs more, so unless there is a very good reason, this is not normally provided.

• Are routine addresses auto-vectored, bus-vectored, non-bus-vectored, or else.

In most 6502 based systems, none. As vectored interrupts need additional hardware, the 65XX family not supporting this system.

• Are any interrupts masked and if so which, when, why and how.

All interrupt sources connected to the /INT pin can be masked, as under software control the processor can be told to ignore interrupts on this pin. Hence why it’s sometimes described as a maskable interrupt system.

In addition, some I/O devices have control registers that can enable or disable one or more interrupt sources within them. Hence under software control, the program can select which parts of the I/O device(s) can generate interrupts.

The /NMI pin on the 6502 (and similar processors) cannot be disabled or masked (hence the name: Non-Maskable Interrupt or NMI). So the processor will ALWAYS respond and jump to the interrupt routine.

You can however still connect I/O devices that can have their interrupt sources enabled or disabled by different values being placed in the relevant control register(s).

Why? If not needed. If a hardware device is not being used, why would you want to use processor capacity to service something that is not doing anything useful?
Or, the program may be running a routine that has timing critical code (writing a sector to disk for example), and hence the programmer doesn’t want an interrupt to err, interrupt it! After it’s finished, interrupts can be re-enabled.

Because the BBC Micro has a ‘system’ 6522 VIA as standard, if you want to know more about interrupts, you may want to investigate this system.

With regards to the Atom, which system and the exact mechanism depends on what additional hardware is connected. As simple systems were less complex and hence cheaper, generally the bare minimum was provided. What this is then varies with who designed each item of hardware. And if they wanted it to work with other hardware.

Mark

[lovebug]

if you want to use your own irq interrupts then load some interrupt code into ram and set the vector address at 204/205 to point to this code

[BigEd]

Is there some specific Atom project or product which uses interrupts, where we can show how the ISR is connected to the IRQ vector, and how the IRQ line is connected to the processor?

[roland]

The most common way to use interrupts on computers where the interrupts are not handled by the "operating system" like the Atom is to write a program that handles the interrupt of a specific device.

Suppose you want to write a program that reads a real time clock (like Big Benny) and displays the time on the screen. This program starts with initializing the interrupt vector. It writes the address of its own interrupt service routine (ISR) into the IRQ-vector (#204/#205 in the Atom). Then it enables the interrupts on that device and that's all to initialize. When an interrupts occurs, the ISR can assume that it's the only one in the system and just executes the main routine of the ISR (i.e. display the time on the screen in this example). Then clear the interrupt on the device and return operation to the current running program. This is what most interrupt programs on the Atom do.

But what if there are two interrupt sources, for example the real time clock and modem on a serial interface that waits for an incoming phone call?

A program that uses interrupts should always save the original IRQ-vector into its own work space before writing its own ISR to the vector address. In pseudo code it looks like this:

Code: Select all

REM disable interrupts 
SEI  (set interrupt flag in 6502 status register to disable IRQ, this does not work for NMI interrupts!)

REM save the original IRQ vector
load byte in #204
store in intsave
load byte in #205
store in intsave+1

REM initialize my routine
initialize my device
setup interrupts

REM set new interrupt vector
load low byte of my ISR
write to #204
load high byte of my ISR
write to #205

REM now enable interrupts again and end initialization
CLI (clears the interrupt flag in 6502 status register to enable IRQ)
RTS

When the first program (e.g. Big Benny) is initialized then the original IRQ vector points to #A000 which in most expanded Atoms contains an RTI instruction (#40). On an unexpanded Atom this will probably lead to an error or hanging Atom.
So, when Big Benny generates an interrupt the 6502 jumps via #204/#205 to the ISR of Big Benny. This ISR should check if the interrupt is really from the clock chip and if not, it must jump to the old vector. If the interrupt is from the clock chip then it can do its job (display the time and clear the interrupt from the clock).

In generic pseudo code:

Code: Select all

REM my ISR, first check if its my interrupt
load my interrupt status flag
is it mine?
NO, the jump to (intsave)
YES, then do your thing

REM after doing my thing
clear the interrupt status on my device
jump to (intsave)

In case we have two programs that use the interrupts we can initialize after each other. First initialize the modem and then initialize Big Benny. When the modem receives an incoming call then it generates an interrupt. The 6502 will first enter Big Benny's ISR. This checks if the clock has generated an interrupt. If not, it will directly jump to the saved ISR address of the modem software. The modem's ISR will check for an incoming call by checking its RI (Ring Indicator) interrupt. It finds this flag set so it answers the incoming call and does its job.

By setting up interrupts this way the limit of interrupt devices is set by the memory your Atom has. The more interrupt sources it has, the longer it will take to check every source and the more memory you need to store all these ISRs. And clearly the last added ISR had the highest priority.

Of course, you can also implement some centralized interrupt system, like the BBC Micro and Electron do. But also in those computers, the user interrupts are daisy chained and should save the original vector.

I hope these examples make it clear how to use multiple interrupts on an Atom.

[Louis.m]

Hello 0010 all ,

For systems where there is
[··]
with other hardware.
Mark

Mark, thanks for your extensive response , it certainly will add to my knowledge and understanding of the matter .
I'll look at it in detail later on when I am more at ease (and the coffee has cleared the clouds in my head ).

if you want to use your own irq interrupts then load some interrupt code into ram and set the vector address at 204/205 to point to this code

That's just what I intent to try as soon as I think I have enough information.

Is there some specific Atom project or product which uses interrupts, where we can show how the ISR is connected to the IRQ vector, and how the IRQ line is connected to the processor?

Those are some of the things I'm looking for, examples of hardware and software solutions
(I don't feel the urge to reinvent the wheel, although if I did it would be triangular )

The 6522 can be seen in the main Atom schematic, but I don't know where to find the associated interrupt handler routine software.
As I wrote in my initial post, the info in "Atomware" is more or less a dead end because of the RTI at #A000 (see top of this thread).

I also found a schematic and some software for the use of the 6821 controller (Big Benny) here and there in the Dutch club magazine "Atom Nieuws", but I have not (yet) found any specific info on how to avoid possible conflicts when using a 6522 and a 6821 (or other I/O controllers) combined in one Atom.

The most common way to use interrupts on computers where the interrupts are not handled by the "operating system" like the Atom is [··]

Yes, Roland, that's more like what I'm searching for, I'll look in to that/your post later on, after I have reset my mind and body with the aid of an appropriate dose of caffeine (see what I wrote to Mark above).

P.s., for those who like to read the above mentioned (Dutch language) "Atomware" and "Atom Nieuws",
it all (and much, much more) can be found by the following links:

• http://www.acornatom.nl/atom_handleidin ... mware.html

and

• http://www.acornatom.nl/atom_nieuws/default-an.html

[roland]

The 6522 can be seen in the main Atom schematic, but I don't know where to find the associated interrupt handler routine software.

You can keep searching for the associated interrupt handler routine software until the year 3000 but you won't find it. Simply because there is no such routine in the Atom rom. You have to write your own handler for your own purpose. An example can be found at https://site.acornatom.nl/documentatie/ ... 836058.gif which is the type-ahead routine by Ronald Boers. This routine uses the VIA timer to scan the keyboard and to store pressed keys into a buffer. The read character routine will read the keys from that buffer.

I also found a schematic and some software for the use of the 6821 controller (Big Benny) here and there in the Dutch club magazine "Atom Nieuws", but I have not (yet) found any specific info on how to avoid possible conflicts when using a 6522 and a 6821 (or other I/O controllers) combined in one Atom.

When you run the program to display the time on the screen, like in https://site.acornatom.nl/documentatie/ ... 846095.gif (Big Benny under interrupt) after you started the type-ahead program you will get a clash or conflict. This is because neither of those programs save the IRQ vector, they just claim it for them selves. So if you started Big Benny after the type-ahead program the 6522 will still generate an interrupt but Big Benny's ISR is executed. So, no keys are read and stored into the buffer and when the buffer gets empty, your Atom will not respond to key pressing any more. So, just because the programmers ((both!) of these programmes didn't daisy chain their routines you cannot run these programmes at the same time.

To avoid conflicts between multiple interrupt sources you must daisy chain your ISR like I described in my previous post. In the Atom there are no other ways to do this.


PS: In 1992 I wrote a routine to display the time on the screen using a DP8570 real time clock. Here's the (correct) initialization and usage of the ISR:

Code: Select all

:BB0   LDA @BB3%256     READ LOW BYTE OF ISR
       CMP #204         COMPARE WITH IRQ VECTOR
       BEQ BB1          EIND ROUTINE WHEN EQUAL (so don't change the vector)
       SEI              DISABLE INTERRUPTS
       LDA #204         SAVE OLD IRQ VECTOR
       STA BB2
       LDA #205
       STA BB2+1
       LDA @BB3%256     SET NEW IRQ-VECTOR
       STA #204
       LDA @BB3/256
       STA #205
       LDA @#7F         SELECT REGISTER 0 OF RTC
       STA D
       LDA @#08         ENABLE '100MS' INTERRUPTS 
       STA D+#3         WRITE TO INTERRUPT CONTROL REGISTER 0
       LDA @#00         SELECT PAGE AND REGISTERS 0
       STA D            WRITE TO MAIN STATUS REGISTER
       CLI              RE-ENABLE INTERRUPTS
:BB1   RTS              END
       
:BB2   BRK              SAVE IRQ-VECTOR LSB
       BRK              SAVE IRQ-VECTOR MSB

And here is the beginning of the ISR:

Code: Select all

:BB3   \ INTERRUPT SERVICE ROUTINE
  
       LDA D            READ DP8570 MAIN STATUS REGISTER
       AND @#04         GENERATED IT AN INTERRUPT?
       BNE BB4          IF SO, GO EXECUTE THE MAIN ISR
       JMP (BB2)        ELSE JUMP TO THE OLD VECTOR
:BB4   TYA              DO YOUR THING....
       PHA

[BigEd]

To rewind just a little bit:

What I am interested in is how IRQs are/can be used and handled in an Atom,
more specific, I like to have info (application examples) about subjects like:

• Which technique(s) is/are actually used in an Atom (polled, programmed,
  interrupt driven, direct or a hybrid like interrupt driven polling).

• How is detected which peripheral/controller is generating an IRQ.

• How are conflicts avoided in case of simultaneous IRQs.

• How did Acorn dealt with priorities of multiple IRQs.

• Are routine addresses auto-vectored, bus-vectored, non-bus-vectored, or else.

• Are any interrupts masked and if so which, when, why and how.

All these questions make sense, from a perspective of a sophisticated system with multiple interrupts, like Acorn's later Beeb, but in the case of the Atom, it looks like Acorn made the minimum possible effort:
- the IRQ vector points to code which indirects through RAM
- the indirect vector is initialised to point to expansion ROM
- the default for expansion ROM is to put an RTI at the indirected location

So, as noted above, everything sophisticated needs to be done by the projects and products which use IRQ, because Acorn's as-shipped Atom doesn't use IRQ.

The tactics for doing the right thing are known, and were known, and are outlined upthread. Namely, interrupt handlers need to insert themselves in a chain of handlers, and need to check their own hardware to see if it has raised an interrupt. (They also need to do the right thing in the case that other hardware raised an interrupt at the same time, or subsequently.)

It's still worth some exploration of what those tactics are - the least possible, and the best possible.

[roland]

BTW (a little off topic) .... there is a nasty CLI in the Atom reset routine:

Code: Select all

FF7C  a9 82     lda #$82
FF7E  85 12     sta $12
FF80  58        cli 
FF81  a9 55     lda #$55
FF83  8d 01 29  sta $2901

When you have an Atom with an expansion ROM that starts with #40 at #A000 or no expansion ROM at all, this might lead to a very hanging Atom in case an interrupt occurs before its accompanying ISR is set up. Such an interrupt will cause the RTI instruction to be executed but the source of the interrupt is still there and the 6502 will directly jump back to #A000 and so on.

The reason will probably be the automatic initialization of the Econet interface (and later also the AtoMMC by Sir Morris) but still nasty things can occur. Unfortunately there is no room in the ROM to write a decent system ISR that at least checks if there is a ROM at #A000 that can handle interrupts. I ran into this issue back in 1992 when I was playing with the DP8570 real time clock. It has no reset input so after a <BREAK> of the Atom it still generated interrupts and the Atom only kept jumping to #A000 because the was no way to clear the interrupt.

Nice to know: IRQ is triggered by a low level of the IRQ input. Interrupts are automatically masked so the ISR has "plenty" of time to remove the interrupt from the I/O device. NMI interrupts cannot be masked (switched off) so the NMI is triggered by a high to low level at the NMI input pin.

[1024MAK]

Well, as pointed out above, the simplest for a programmer, is not to consider any other hardware, just worry about the hardware for the software that they have written.

This was a similar situation on some other home computer systems where the manufacturer had not specified a particular method. Or sometimes even if they had.

It should also be mentioned that polling (instead of using interrupts), was fairly popular. It’s cheaper. And generally speaking, most home computers were only likely to be used with relatively slow I/O devices. Plus they were single tasking systems.

Hence for a computer that only has a keyboard for input, cassette tape for mass storage, a simple sound system and a video display for output, there was no need for an interrupt system.

Even for a parallel printer port, a RS232 serial port or other simple I/O device, you often don’t need interrupts.

However, there must certainly are some I/O systems where an interrupt system is essential.

Mark

[roland]

However, there must certainly are some I/O systems where an interrupt system is essential.

An example of that is the BeebOPL where the data to play the music is loaded while the tune is being played. It could be done by polling the OPL chip but since the individual tones can have different lengths it's more effective to use interrupts to play the tune. Also the SID player uses interrupts to play tunes while playing a game.

The Atom DOS also uses in interrupt but IMHO this is not strictly necessary. The 6502 can write commands to the 8571 and then poll for data. It would make things easier because after *LOAD or *SAVE the prompt return immediately while there has not been any data transfer. So you had to wait anyway.

[Louis.m]

Hi2all,

Thanks for all your (stimulating) response.

The tactics for doing the right thing are known, and were known, and are outlined upthread. Namely, interrupt handlers need to insert themselves in a chain of handlers, and need to check their own hardware to see if it has raised an interrupt. (They also need to do the right thing in the case that other hardware raised an interrupt at the same time, or subsequently.)

It's still worth some exploration of what those tactics are - the least possible, and the best possible.

I'm thinking about an ISR (a main Interrupt Service Routine, to which the µP jumps whenever an IRQ is generated) that detects the source of any IRQ signal by polling status registers (Interrupt Driven Polling so to say ) on the basis of a table of peripherals present and capable to generate such interrupts, then deciding what to do next on basis of pointers in that same table.
It seems possible to me to integrate I/O priority status and possible muting of IRQ from other sources as needed, in that same table.

It should also be mentioned that polling (instead of using interrupts), was fairly popular. It’s cheaper. And generally speaking, most home computers were only likely to be used with relatively slow I/O devices. Plus they were single tasking systems.
[··]
However, there must certainly are some I/O systems where an interrupt system is essential.

Because I'd like to keep things as compatible to the original Atom Bus as possible and there is little to no room for individual IRQ lines on PL6/7 (and PL8 ), and therefore also no way to use a real priority encoder, I suggested the "Interrupt Driven Polling" mentioned above.
When programmed well, it can integrate the best of both methods and have the flexibility and linking points to expand when needed.

All comment or suggestions are welcome, tips regarding (downloadable) literature on this subject are MORE THAN WELCOME

. . . and . . . thanks Roland, writing ones own ISR or not, that nasty CLI is certainly one to keep in mind

[Louis.m]

While I was busy typing,

However, there must certainly are some I/O systems where an interrupt system is essential.

An example of that is the BeebOPL where the data to play the music is loaded while the tune is being played. It could be done by polling the OPL chip but since the individual tones can have different lengths it's more effective to use interrupts to play the tune. Also the SID player uses interrupts to play tunes while playing a game.

The Atom DOS also uses in interrupt but IMHO this is not strictly necessary. The 6502 can write commands to the 8571 and then poll for data. It would make things easier because after *LOAD or *SAVE the prompt return immediately while there has not been any data transfer. So you had to wait anyway.

Duhnoh Roland, the 8271 announces its data transfer to the µP with a NMI . . .

[roland]

I don’t think its easy to build such a table because there is no standard for I/O devices except for the 6522 at #B800. You can build such a table for your very own peripherals but IMHO you cannot make it universal. For example, not every Atom has a real time clock (besides that, there are more designs than only Big Benny like my own DP8570 and there’s also a I2C rtc). Not every Atom has a WiFi card, or serial interface. Do you want to register every possible device in your table?

That would make the ISR very slow because it has to check probably 50 possible devices whilst there might be only two devices connected.

Don’t let me discourage you, I’m curious to your vision and how you try to implement it. I am looking forward to discuss your ideas during the upcoming ABUG in October

[Louis.m]

Hi Roland,

If you want to discourage me you have to do better, this is mere stimulating, it keeps me sharp (thanks for that)

Do you have 50 or more I/O controllers in your Atom that are capable of generate an IRQ

As I remember well, there was a day (before Plug & Pray) when someone, installing a game on a PC, personally had to enter the address of his sound card

If the ISR table has some headroom and is editable (unassigned zero page under battery backup or alike ?) every user can shape it to its own needs, which makes it utterly universal, even beyond any Atom.

Thus it won't be slow because it will only poll a hand full of addresses registered in the ISR table capable of generating an IRQ and only when such an IRQ occurs and only until the culprit is found.

[lovebug]

back in the day I fitted LK 2 ? to enable the 6522 interrupts and set timer1 as freerunning and enabled interrupts for T1
my interrupt code cleared the interrupt flag in the 6522 and then toggled the speaker bit on the 8255 port

so by setting the timer1 high and low latches with values equal to the half period of musical notes I was able to generate 1 channel music from the atom basic

was amazing to see the atom generating a tone and with the keyboard and basic running at the same time

simple times

however if the timer was set to a really short period for really high frequency then the main program (os/basic) would slow down a lot

[roland]

Do you have 50 or more I/O controllers in your Atom that are capable of generate an IRQ

No, I don't. But there might be 50 (or so) boards out there that can possibly be attached to an Atom. There are several serial boards, sound boards, I/O boards and other equipment that might generate an IRQ. Most Atoms will have only one IRQ source (the 6522) and perhaps there's something like a serial interface, WiFi board or an audio device (although the first two generally do polling and don't use interrupts).

If the ISR table has some headroom and is editable (unassigned zero page under battery backup or alike ?) every user can shape it to its own needs, which makes it utterly universal, even beyond any Atom.

That's another challenge.... based on the memory cards that I sold in the past years, there are almost no Atoms with battery backupped memory. And speaking of memory, there is no free memory available. Every byte of memory will be used some time. There are games that really need 32k of RAM; all zero page addresses are use by the Atom's ROM and the many utility ROMS.

On the other hand, I don't think that there are many people who do their day to day computing work on an Atom. So building a flexible IRQ system can still be a nice, challenging project. It will surely encounter some incompatibilities with the software that was written in the past but as a proof of concept it might be useful one day. After all, isn't this what we always did with the Atom: think - design - build - distribute and start all over again with something new

[BigEd]

Just had a thought: this discussion is somewhat like a discussion about choosing a data structure for something... on the one hand one might use an array, on the other hand one might use a linked list. As ever, there are pros and cons. But ideally all parties are already aware of both kinds of data structure.

[Louis.m]

Hello 0010 all,

That's another challenge.... based on the memory cards that I sold in the past years, there are almost no Atoms with battery backupped memory.

Isn't this a nice opportunity to (re)introduce it

And speaking of memory, there is no free memory available. Every byte of memory will be used some time.

There will always be space and beyond in the Atom Universe, if we can't go up or down we go sideways
Speaking of sideways, I think there aren't many people that have all the sixteen available toolbox spaces populated.
On the switchcard there is space for eight boxes (of 4K each) in the #Ax area (if I recall well), but looking at the SwitchByte (D0-D3 of #BFFF) we see it is possible to point at sixteen boxes, and if you analyse Branquart SOS it is allowed to use the "Rom"* command for numbers from zero up to fifteen (8×4K=32K) .
* I renamed "Rom" to "Box" because there is also RAM used there .

Besides that (pun intended), #Bx is mostly wasteland while the SwitchByte demonstrates that RAM in #Bx is very well feasible.
I'm still working on the idea to fill the holes in the I/O Emmentaler that BLockB is, with several small chunks (each 1000 Byte or so) of RAM.
Ideal for alocating the I/O table (that I suggested) because such a little amount of RAM is easily fed from a small backup battery and it is "just around the corner" (maybe it can even house some associated software ).

There are games that really need 32k of RAM; all zero page addresses are use by the Atom's ROM and the many utility ROMS.

Maybe we should start a questionnairy thread to inventorise the use of Atom Space
I have a list (on paper) somewhere in which I wrote everything I could collect about memory use, that might be a good start .
If I can find the energy to type a copy onto my PC, I'll publish it on *. and ask readers to complement it.

[··] building a flexible IRQ system can still be a nice, challenging project. It will surely encounter some incompatibilities with the software that was written in the past but as a proof of concept it might be useful one day.

Experience learned me that incompatibility can most times be solved by flexibility.

After all, isn't this what we always did with the Atom: think - design - build - distribute and start all over again with something new

Yep,

[roland]

Hi Louis,

I have a demo with multiple interrupt sources on my Atom. It displays the time and date with RTC interrupts and it plays a song with the DRO-player (BeebOPL).

View it here: https://youtu.be/teLJoQJ-828

[Louis.m]

Hello Roland,

I have a demo with multiple interrupt sources on my Atom. It displays the time and date with RTC interrupts and it plays a song with the DRO-player (BeebOPL).

View it here: https://youtu.be/teLJoQJ-828

Nice, but I'm interested in the theoretical structure of programming and hardware for multiple (simultaneous) IRQ by a 65C02
and that video doesn't explain anything.

Besides,what is producing the sound
Judging from it, it is not even a standard Atom but one with some extra sound card.

[Brian of Fairfield]

Hi,

Some small notes. The question was asked about priority for service routines. Service routines are threaded and hence get run in the reverse order to the registration. i.e. The first to register is the last to get 'called'. Since the OS at $A000 was 'first' it gets the last go.

The other thing is that when your routine finishes, irrespective of whether your source was interrupting or not, you shouldn't RTI, you should continue down the chain to the previous/earlier claimant. There may well be another extant interrupt waiting its routine to get control.

It is always useful to treat IRQs as persistent, so you should double check your own. Rather than

Code: Select all

IF (my_irq) THEN service_my_irq ENDIF go_to_next_handler

you should

Code: Select all

WHILE (my_irq) { service_my_irq } WEND go_to_next_handler

Brian.

[Louis.m]

Hello 0010 Brian,

about priority for service routines. Service routines are threaded and hence get run in the reverse order to the registration. i.e. The first to register is the last to get 'called'.

That's a good one to keep in mind.

when your routine finishes, irrespective of whether your source was interrupting or not, you shouldn't RTI, you should continue down the chain to the previous/earlier claimant.

O.K.

It is always useful to treat IRQs as persistent, so you should double check your own. Rather than

Code: Select all

IF (my_irq) THEN service_my_irq ENDIF go_to_next_handler

you should

Code: Select all

WHILE (my_irq) { service_my_irq } WEND go_to_next_handler

That seems like somkinda Basic, I'm talking SALFAA in Atom, so I dunno if that applies to my situation.

Anyway, Thanks for the reply with all advice.