I'm more worried about a burst of data coming in from the serial port at 38Kbps when no-one's looking... how big are the serial receive buffers in the ATM8?

For clarification, these are not languages.

The Amiga is a computer whose OS was programmed largely in C. It is a modern architecture (even by today's standards) microkernel-type environment that relies heavily on the client/server architecture, largely obsoleting many of the backwardness of POSIX. Unfortunately, because human beings are gluttons for punishment and sadomasochism, AmigaOS died in the marketplace, and is largely ignored today.

The only significant flaw with AmigaOS today is that it is an unprotected, single-address-space environment -- hardly relevent to this thread.

POSIX is an open standard specifying what should exist and how things should behave in any operating system claiming to be compatible with Unix. As POSIX dictates a Unix environment, all POSIX implementations I'm aware of are written either in C or C++. ioctl() is a system call which is used to adjust settings on a file handle, and is highly non-portable, extremely confusing, and is widely acknowledged to be avoided at any costs in the general case. While POSIX specifies the existance of ioctl(), I'm not aware of any POSIX-required ioctl settings. Hence, it tends to be VERY platform specific.

Because POSIX is a Unix compatibility standard, it has to deal with all the time-sharing cruft from decades and decades of dealing with a multitude of different terminal types, ranging from RS-232-linked systems, to 3270 systems, to Apple-2-style direct-connect-matrix style keyboards.

Just as DOS compatibility in Windows makes Windows a hellish environment to maintain, so too does backward compatibility with paper tape readers make Unix console I/O and management a pain in the rear to deal with from an modern-day application coding perspective.

OK, I can do that, and use a control code to switch between this and ASCII mode.



I was figuring on some depth of buffer in the ATM8 for keyboard and RS-232 receive. Since the CPU will presumably be in control of RS-232 use, I would think it would know when to poll and when it didn't need to. For instance, if an opens the port, it would be responsible for polling or using a timer interrupt to service the port. Knowing the baud rate and buffer size, one could calculate the interrupt rate needed to prevent data loss.


I have added jumpers to select IRQ2 input to the 65SPI from VIA2 or ATM8. With that, a wire strap cound be installed to once of the VIA's handshake pins if you wanted the VIA2's IRQ to be active . Again, it would be up to the user.


The vblank is using the NMI line and can be controlled with software.

OK, so if we assume a timer running at 100Hz and processing serial data coming in at the maximum rate, with the typical 8n1 settings:

38400bps = 3840 bytes/s

3840 bytes/s
----------------- = 38.4 bytes/interrupt
100 interrupts/s

So if we round the buffer up to the nearest power of 2, 64 bytes, that should give plenty of overhead to allow for NMIs interrupting the IRQ routine, and still not swamp the CPU with IRQs. OK, you guys sold me - no need for serial or keyboard interrupts

Edit: actually, the worst case would be 38400bps, 7n1, giving 42.67 bytes/interrupt, but again a 64 byte buffer should cover it. I've not included the cost of siphoning data off the buffer, because at 2Mbps it's pretty much instantaneous - there would be barely enough time for 10 bits to arrive before the 64 byte buffer was emptied.

with 1k of SRAM onboard, I'm sure I can allocate at least 128 bytes to the receive buffer. Purhaps even 256 as the transmit buffer can be kept small and the keyboard will only need 16 or 32, or even 64 at most.

The 6551 ACIA can run over 100kbps with external clock, and some other such ICs can run many times that fast. But that's what the interrupts and RTS and CTS are for-- so you don't lose data.

Especially if you have several ports though (not necessarily all RS-232), it gets to be kind of a waste of overhead to keep checking each one of them 100 times a second if they're idle most of the time that they need to be ready to accept data. It's best to have the serial port just interrupt the processor only when there's activity, which also eliminates the need for such a big buffer. The 10ms ISR (interrupt service routine, or interrupt handler) should be kept as short as possible to avoid unnecessarily effecting the timing of other things that aren't on NMI. (I'm thinking primarily of situations where jitter may be an issue, not so much the matter of taking up a few percent of processor time.)

Outstanding interrupt performance is a key advantage the 6502 has over other processors; and to just use a timer interrupt to poll a bunch of things does not allow it to take advantage of that strength.

It's the doorbell idea again. You can work more efficiently if you don't have to keep checking the door when you're expecting someone. You can forget about it until the doorbell rings.

Garth,

You make many good points. Purhaps the best solution would be to use my RS-232 for general data transfer or terminal use. If someone wants hi performance, they can use an SPI UART with an IRQ connected through a VIA to accomplish their goals. That would be a simple addition in hardware. I don't think the ATM8 is the right tool for hi performance data transfer applications.