I am at a point where I have decided to stop developement for SBC-3. If there is enough interest, I can put together a board with the SBC-3 core with 2 65c22's and one modified 65SPI. This board will not have an expansion port as bus loading needs to be kept low. I will include space for a 7805 type regulator, power input, and pc keyboard input using the 65SPI.

Any further IO will be left for the user to develope on the 65c22's or 65SPI.

So, please contact me via email if you are interested in having an SBC-3 board as described above. Estimated cost would be about $25 each (blank PCB only). Two custom CPLD's preprogrammed will add another $20.

If there is enough interest (at least 20 boards total), I'll get it layed out and post details.

If there is not enough interest, then at least the schematic details will be made available to those interested in DIY.

I'll leave this request open until August 30, 2008. Feel free to forward this on to others that may be interested as well.

Thanks!

Daryl

Total boards requested, as of 8-31-08 = 15

I'll edit this post once per week, for those interested.

Daryl

I have the v1.1 SBC-3 schematic posted to my website. This will be the final configuration.

http://sbc.rictor.org/sbc31/sch.html

The modified 65SPI decodes the 65c22's and provide IRQ handling, as well as SPI functions. SS7 can be used as the External SCLK input by toggling the ECE bit high (default value). When ECE is low, SS7 functions as an output and clocking is from PHI2 clock.

I have added an ATMega8 to provide a PC keyboard and RS-232 via SS6 on the 65SPI. It will use an 8MHz internal clock so its SPI interface will max out at 2MHz.

That leaves SS0-SS5 for user devices.

I will have a simple Monitor available that will support keyboard input, text and graphics output, and rs-232 xmodem transfer for PC-based storage.

I'll be updating the SBC-3 pages with full details over the next week.

Daryl

I have a total of 14 boards requested and have estimated the cost per bare board to be $25.

I will move forward with completing the layout and finalizing the firmware for the programmable parts.

I will most likely provide the board, all the programmable parts, and the SRAM. Final cost is still to be determined.

If anyone is interested, I will continue to collect names until its time to place the orders, estimated to be the end of September.

Daryl

I have uploaded a picture of the SBC-3.1 board layout to my website.

I will be verifying the netlists and traces then will work on the ATM8 code.

Daryl

Small question about the keyboard interface aboard the ATM8: since the ATM8 is going to be connected via a bidirectional SPI connection to the rest of the system, are you going to make the keyboard a read-only device, or are you going to allow commands to be sent too? I'm thinking of four commands in particular: an "are you there" check to see if the keyboard's unplugged, a keyboard reset command, key repeat control and setting the LEDs - basically PS/2 commands $ee, $ff, $f3 and $ed.

I haven't started the code for the ATM8 yet so I cannot answer for sure.

This has been my thinking though:

Keep the keyboard a read-only device and let the ATM8 control it. Kind of like the dumb keyboard on the Apple 2, all you had was data register and strobe (ack) register.

The ATM8 will present ASCII characters to the CPU from a buffer. All the scancodes and control will be decoded by the ATM8. There will be some sort of status reporting between the ATM8 and CPU, such as buffer empty and keyboard missing/error. I was thinking of adding a keyboard re-init command also. I could incorporate more control, but I'm not sure what the gains would be? Does the CPU really care if the Caps or Numlock is on? I have NEVER used the scroll lock key or LED in ANY application, so was not planning on having it's function used. Again, give me a good reason and I'll consider adding it. As far as key repeat, the default setting has always worked fine for me, and will work with the ATM8. Is it really needed?

Bottom line is these would not be hard to add if there functions were needed.

The RS-232 port will also work from buffers. However, I was going to add commands to set the baud rate, stop bits, and parity, and word length. There will be a fixed set of baud rates - 2400, 4800, 9600, 19200, and 38400. 7 or 8 data bits. Odd, even, or no partiy. 1 or 2 stop bits.

Since I still need to write this code, I'm open to suggestions and requests.

thanks!

Daryl

Don't underestimate the usefulness of keyboard LEDs as a low level diagnostics/debugging aid, especially when there's no native text mode or built-in beeper (and even with a soft text mode, you may not want to stomp all over the display). It can be very useful to know that five blinks on the caps lock light means that the RAM test failed, and that's why the box is not coming on. Not everyone has access to a serial terminal (especially now that USB's taking over), but 99.9% of people will have a keyboard plugged in, and 99.9% of those have LEDs.

I have to agree with you about scroll lock though... I don't think I've ever used it either

Good argument. Like I said, it won't be hard to add some control and status for the LED's.

thanks!

Daryl

Don't add TOO much intelligence though. There are times when you really do want to know when a key is pressed and when a key is released. Having access to raw scancodes seems to add an insignificant amount of code to the protocol. And if you let the host cook the raw codes into ASCII or UTF-8 itself, your protocol becomes substantially simpler.

One need look no further than the terminal HELL that is Posix for proof of this. Do you want your console to support 7-bit or 8-bit cooked ASCII? How about UTF-8? Do you want it in fully-cooked, semi-cooked, or raw mode? If in raw mode, do you or do you not want to support console switching in the kernel? Do you want to control the queueing of characters yourself, or do you want the kernel to do it? What escape codes do you want to use for cursor movement or function keys?

And on.

And on.

And on.

So, please don't ignore computer history. There is a reason why AmigaOS chose to cook raw scancodes into ASCII on the CPU-side, and not on the keyboard side. Let the application decide how *it* wants to deal with keyboard codes (and, for that matter, everything else), since *it* knows best.

KISS.

Again, good points.

How about this? (all those who plan to buy one please chime in here)

I will make the first release provide simple ASCII codes with little control (as originally planned). Later, if others want it, I can provide ATM8 code that sends scan codes to the CPU. That way, the current monitor can interface with the ASCII input. A revised monitor or other BIOS can be written to handle the scancode conversion later. This will provide choices to the users.

The hardware does not have to change, only the firmware in the ATM8 and EEPROM. Although, I may have to reroute one of the VIA IRQ's to the ATM8 so the CPU will know when the ATM8 has data to read??? Darn, seems like I always need just one more pin...

Daryl

Well, I was thinking of sending one command code with a simple boolean value: if TRUE, put the ATM8 into "ASCII mode", and if FALSE, bleed raw scancodes, bypassing completely any internal cooking logic.

In other words, do NOT go the route of putting an entire keyboard driver plus terminal emulator into the chip -- that is, do NOT replicate POSIX's ioctl() interface for terminal devices. I think it's good that a simple ASCII cooker be included for the minimal applications. But, just make it easy to get access to raw scancodes too.

Well, yes, that would work too.

Do you think its necessary to provide an IRQ from the ATM8 to the CPU for scancode use? Having not programmed on the AMIGA or in the POSIX language, I'm not sure if having the CPU scan for changes is sufficient.

If IRQ's are necessary, then I'll need to provide IRQ options in the board.

Daryl

I agree with kc5tja, having a raw mode that assigns a number to each key and returns whether it was pressed or released (without even doing special handling for caps lock, etc) would be good. I would even go as far as saying that this is all you really need - hide the horrendous mess that are $e0 and $e1 extended scancodes in the ATM8, and let the CPU use a translation table and a couple of flags to handle the rest.

I didn't want to bring up interrupts because your hardware design is "done", but for RS232 you really need to have them, else you won't have a choice but to constantly poll or risk losing characters. If you're going to have interrupts for serial receive, you might as well have them for the keyboard too...

If you're going to provide multiple interrupts, I would like to suggest hooking them to one of the two VIAs CA1/CA2/CB1/CB2. That gives you a really nice, standardized way of handling interrupts. You could have one dedicated to the vblank interrupt on the video controller, another to the keyboard, a third for RS232 and the fourth for SPI.

IRQs are always nice to have. However, they're not strictly necessary, since a timer interrupt can be used to initiate a keyboard poll as part of its handler logic.