Hello everybody.
I am trying to understand how the SBC works, which I chose to study 68k. Much has been simplified here in order to reduce the number of IC's, including connecting the IRQ outputs of the ACIA 6850 to the microprocessor. The usual in such cases 74148 is absent here and the outputs of the two ACIA's are connected directly to the IPL0 and IPL1 inputs of the processor. In this case, as I understand it, autovectors 1 and 2 are used.
The question is as follows. What happens if interrupts from both ACIAs arrive simultaneously. A low levels at the inputs IPL0 and IPL1 means a third level interrupt, but there is no handler for this interrupt.
Did I miss something?

Description and diagram of SBC are here:
http://marc.retronik.fr/motorola/68K/68 ... 1-1984.pdf

Interesting... seems about right, from my very limited understanding. But I think it's a minor software problem, isn't it, to create a handler for autovector 3?

ref: https://www.atarimagazines.com/v5n2/Exc ... rupts.html

The prototype may not have used irq's, as this was a basic machine, but had them reserved.
2K ram is rather, limited did they have a later upgrade? As a thought 128Kb ram is about the same as 64kb ram for a 8 bit machine, since for most 16 bit cpu's things are word rather than byte sized.
Ben.

Yes, we can see something similar in the Atari ST. 74148 is missing, but there is a GLUE chip that switches the HBLANK, VBLANK and MFP interrupt lines. Low on IPL1 causes HBLANK interrupt, IPL2 = VBLANK, IPL1 and IPL2 = MFP. But, HBLANK and VBLANK are not two ASIAs. These impulses are strictly periodic events that can never coincide by accident. Events in the ASIA happen asynchronously. The only question is, what is the probability of a coincidence. If it is less likely than a meteorite to hit the discussed SBC, then everything is OK, I can't worry.

To oldben:
There is a section in the SBC description called "Interrupt Handling".
The SBC uses IRQ's.

I do not think you missed anything.

Do you have a ROM listing? What is the autovector #3 set to? It may point to the same location as autovector #1 or #2 giving one of the ACIAs a higher priority than the other. There does not need to be a separate handler if one of the handlers is reused. That is also quite an old article, 1986. I would be tempted to make updates to the system. More ram 628512’s and a better UART. It may be easier to find newer parts. 4kB ram is not very much. With a meg of ram and most of the OS in eprom it may be possible to run uLinux on the SBC. I seem to recall seeing a 68008 system running uLinux. If you are after a small system a 68008 requires fewer parts.

Other vectors point to RAM:

DC.L #1,ININT ;Terminal Vector
DC.L #1,LPINT ;Download-line Vector
DC.L #1,$1028 ;User Autovector No.3
DC.L #1,$102C ;User Autovector No.4
DC.L #1,$1030 ;User Autovector No.5
DC.L #1,$1034 ;User Autovector No.6
DC.L #1,$1038 ;User Autovector No.7

I can change the design and I always do it. It is an opportunity that attracts me in the design of computers.

That is my problem too, often about 3 am.
With a board like that I can see only one uart in use at a time like the console or second
serial port for some other I/O. I would replace the 6850 because it has hardware IRQ
service bug if you get a RX & TX req at the same time.

(quick google to see if I can find the bug).
Can't seem to find it again, but I did find another 68000 project.
It looks to run 68000 cp/m from compact flash.

https://sites.google.com/site/oldcpusrus/
"April 2019 ... 32k EPROM and a single 512k x 8 SRAM along with a 68681"

Maybe, reusing one of the existing handler is the best solution. In the event of a level 3 interrupt, one ASIA (priority) will be serviced first, and then the other, in the usual way. Thanks robfinch.

I have not heard about the bug in 6850. About 6551 on 6502.org something similar was discussed. Perhaps each IC has its own bugs. I will google and look for. More precisely, my ICs are HD63B50P.
Thanks for the link, I'll read it.

Because the system is single-tasking?
May be. I'll think it over.

One thing about human beings using unreliable equipment: we quickly learn to avoid things which cause trouble. So, if it turns out that one must not type while the communications link is active, that might become a habit (a superstition, if you like) and the bug in the design doesn't matter so much.

I would call this " formation of a conditioned reflex". A person avoids what causes pain and strives for what is pleasant.
In general, each human personality is a set of conditioned reflexes. Sorry for offtop..

I thought about your words, oldben. It seems to me that if a file is being downloaded, the console should still work. Can I interrupt receiving a file using the keyboard? And multitasking has nothing to do with it, I said it in vain.

I would fix the system with PAL 16V8 for the irq decode and address decoding.
CP/M and MS DOS got away with crappy serial I/O but a real OS needs IRQ's.
XMODEM file transfer could poll the keyboard after checking for serial input I suspect,
thus IRQ's are not needed.

Thanks oldben.
AN1012 is a good document, it explains a lot. Although there are some incomprehensible places. For example, Figure 2 says that during GRANT INTERRUPT, the processor 'ASSERT DATA STROBE (LDS)'. And Figure 3 says that the processor asserts LDS and UDS.
UDS? What for?