OK, here it is. My first question is, can we all settle on a simple system, with few bells and whistles, and the OS?

The goal is to give newcomers a quick start-up solution, not to create a do-it-all complete PC.

I am willing to help with the board layout and schematic generation.

We could modify my SBC design to accomodate your suggestions. Alternatively, we could add a daughter board with the IO you suggested to a stock SBC-2.

We could also start over with an entirely new design. I would suggest the use of a PAL16V8 to handle the memory decoding vs. descrete logic, to save space, decrease decoder delay, and allow for future changes. We could make pre-programmed PAL's available to get started with.

As far as OS, I am open to suggestion. I would want to include my X-Modem transfer routines to allow program download from the Host PC.

My monitor included disassembler, memory view, memory modify, memory move, EEPROM self-program, mini-assembler, and X-modem transfer. This could be modified/stripped down/added as needed.

We could add Forth and/or Eh-BASIC along with the routines from the source code repository, as Garth suggested.

Well, let the "discussion" begin......

How about a 65816 design using a bigger PLD (e.g. ATF1504AS) to provide high address byte capture, RAM/ROM/IO decoding, chip level single stepping, etc. in single logic package? Using a microcontroller (PIC 18F) to control the main processor via the PLD, act as a low level debugger and bootstrap the OS into RAM (from its own EEPROM) with an RS232 interface for commands/OS configuration to a PC. A SPI/I2C/... interface for access to a USB2 Host Controller (like this http://www.vinculum.com/prd_vdip1.html) which would give access to memory sticks for file storage.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

I like the idea of an easy development system quite a bit. I'm no expert on any of this, just a guy who spent a few summers of my childhood hacking an old VIC-20, and always wanted to build hardware. Some quick points:

1. OS - Contiki. It's tiny and ported to the 6502, has TCP/IP. We'd be tapping into the open-source work of a lot of developers, which would keep things easier on the software side. I'm guessing, everyone should correct me if I'm wrong.

2. 8BIT seems to be leaning towards simplicity, Bitwise strikes me as in a more modern camp. 8BIT's idea would be low-cost and likely easily assembled; Bitwises' seems far more ornate (Multiple processors with multiple ISA's doesn't seem beginner friendly to me) but both the 65816 & USB aspects are very appealing to me.

3. I use a Mac, so I'm not much able to participate in the fun and games around here - no paralell ports, most software doesn't run - but USB, TCP/IP and other standard, modern interfaces would allow users of just about anything perhaps get up and running.

Whatever is decided, I'm willing to be a guinea pig to see if beginners can actually get started with it.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Does anyone have a good supply source for the 65C51's?

WDC is still only offering samples. If we want to include them in our design, we'll need a source. Also, we need to know the max speed that these can run. We know our 65C02 and 65C22's from WDC will go faster enough, but the 65C51 will slow us down.

Garth, I like your 1 chip memory decode... its simple and it works. I could live with using it vs the three chips I use on the SBC. I could rework that part of the board if we want to go that route. We could also leave it as is (it runs well up to 5MHZ... my 65C51's won't work at 6MHz). We'll need to decide on the RAM/ROM sizes if we use the one chip method.


If we use a single 16V8 to emulate the 74HC138 style of decoding, we can include the equivalent schematic using discrete logic gates to eliminate any fog. This would give us back nearly 16K of RAM or ROM.

As far as a daughter board for human interface, we could go the LCD and keypad route. We would need a good supply source and a low parts count to keep cost down. Are you thinking of a hex keypad with a few special keys of something else? How big of an LCD are you thinking of?

We could also make one with my text video display and pc keyboard decoder. That would use approx 5 IC's - 65C22 for interface, ATMega8 - 74HC74 - 74HC165 for video, and ATTiny26 for keyboard. The ATTiny26 could be upgraded to a ATMega8 and we could get some RS-232 support from it as well (I have not developed that yet...but would be willing to do so) This option lets the SBC be a stand alone terminal. Add storage, and it would be very useful (but we my be getting too big again).

Ross Archer and I did a combo Intel Hex - X modem file transfer routine which could help with the file downloads from the host.

The tiny assembler in my OS does not use labels or complex operands, it does allow you to keystroke all the standard opcodes and hex operands. We may want to exclude it to save space for more useful routines.

I do agree, keep it simple, keep it small. If we start adding too much, we won't ever get it done.

Daryl

I'll try to find out from WDC. If we can't get WDC's soon enough, we may have to design around one that's not 65-family-specific, whether that means connecting directly to the bus or going through a VIA for a serial interface like SPI.


That sounds good. Then the only drawback is if the newbie does something to fry it and can't get another one as easily as a standard 74-family part.


These LCDs are made by many different companies, and although their pinouts vary a little, the software protocol is the same on all of them. Probably the most common one is the 16-character, 1-line LCD like Jameco's cat. no. 644025. (There's one such LCD in the last picture in this post.) 40x2 is nice, but requires more space too. If the "customer" gets far enough to want a graphics LCD, he can do it himself.

Jameco has a couple of nice 16-key keypads, including

with up and down cursor keys, ENTER, HELP, CLEAR, and 2nd, but they don't have the A-F hex digits. The one shown here is $15, and the 2x8 layout is $17. I like the Grayhill 87 series because they're more compact (1/2" square per key) and you can put your own labels under the clear keycaps, which is what I did in this automated test-equipment setup:

These keys are also about a dollar each. The Grayhill modular keypads .pdf is at http://lgrws01.grayhill.com/web/images/ ... eypads.pdf

Something else that you could use for the display, if you want to have something a bit fancier than a text LCD, is the Multilabs ezVGA. It's a PLCC84 chip that, coupled with a 128KB SRAM, a crystal and some passives, gives one 320x240, 64 color VGA. It only takes up two bytes of address space and seems 65xx/68xx friendly.

http://www.multilabs.net/ezVGA.html

(I don't work for these guys, I just ran across their website when looking for a similarly-named part...)

What is the target audience we want to have for this little machine? If we're going for the beginner, we should make it easy and simple - and understandable. It should, however, be extendable to the point that it can be actually used and not just be a toy (like e.g. multiple inputs/outputs to control robots digital and analog and/or interface with SD-cards for memory - for example the "RoboKing" competition allows 8-bit CPUs only to control a robot for a specific task, as was shown on CeBIT)

If we want to make a full featured system with what's possible today, we could as well go for the '816 and GALs etc. I wonder what would we actually gain from this approach that is not already possible by the smaller approach? More memory I guess.

Personally I would stay on the simple side. Have a small system with RAM, ROM, basic I/O (RS232) and a 6522 for a small keypad, LCD and maybe SD-Card to quickly transfer files from the PC to the system. Although this is already getting hard to fit into a Euro-board space, I tried something like this with my Gecko boards, but then I needed place for my addressing logic which could be made simpler.

Add daughterboards for more functionality. So we need a bus spec. Using the CPU bus restricts CPU speed, other busses are less flexible. CPU bus is probably needed for stuff like USB or disk drives, but A/D or D/A or I/O ports could probably be done via SPI or I2C.

So maybe there should be a CPU bus available, but the I/O daughterboards should mainly use the serial busses.

One thing I would like to have is something like a "simulate ROM" feature - the user should be able to test new operating systems (SoC) programs, completely replacing the builtin ROM. I'd probably go for 16k ROM, 32k RAM, of which 16k could be used to replace the ROM - but maybe that's too complicated.

The "OS" should be a very small monitor program, that handles keypad, LCD with a hex monitor, and allows to load programs into RAM, as well as reprogram the ROM code from RS232. This "raw" mode will be the one to start with, but when the ROM is programmed the monitor would go out of the way after boot to start the ROM (except when some debug keys are pressed). Kind of hypervisisor I guess ;-) The monitor should protect itself from overwriting



+1

Just my uncoordinated thoughts...

André

Speaking as a newbie who's currently elbow deep in heavily annotated printouts of timing diagrams (I have a *lot* more respect for you hardware guys now...), I would agree that I'd prefer to have something more complex than a KIM-1 as my first selfbuilt computer. Not a lot more complex, but I agree with Andre that if all it has is a 6502, ROM and some blinkenlights it hardly seems worth the hassle and expense - I grew up with a C64 darn it, I have high standards!

One thing I would ask for, which should keep the design newbie-friendly, is to use a 65C816 with less than 64KB of memory. That way the hardware is kept simple (as far as I can tell, the timings should be the same as a 65C02 if you don't use banks) and you get to use the very nice software features of the '816.


Isn't that what we used to call a BIOS back in the day?

http://www.falvotech.com/content/kestrel/1p3

Description

Total cost in parts: under $25 as memory serves me correctly. The PCB for it would easily dominate price.

My Kestrel-1 is a ROM-less design; it used 5 74ACT595 shift registers to allow my desktop PC to download "ROM" images into RAM (note that 32K of RAM exists from $8000-$FFFF. Thankfully, the 65816 lets me re-route direct page to $8000 and stack to $81FF effortlessly on boot-up).

The Kestrel-1 supports 32K of RAM and 16 bytes of I/O, as documented on my website. The only reason it's that small is because I went super cheap (the goal was to be the cheapest possible 65xx computer one can build -- and it is). Quite literally, the entirety of the computer's address decoder is a sole 74AC00. With additional 7400s or maybe a 74138, you could address more I/O devices. As long as RAM sits at $8000-$FFFF, it won't care.

Maximum clock speed is approximately 5MHz with the parts I've selected. I only tested it up to 4MHz though.

Programming

As documented on my website, the Kestrel-1 is designed to operate from a parallel port. This allows the host PC to download software into the RAM. Note that there is no ROM in the design. I use 74ACT595 serial in to parallel out shift registers to control the bus of the computer. (Consequently, the computer cannot, as documented on the web, support DMA, since it would interfere with the IPL circuitry).

Modernizing the design to support USB would be an excellent project, I think. Getting software into the computer via USB will be more complex, but I don't think it'd be substantially so. It'd involve a microcontroller and an FT245M module to interface USB to the microcontroller (unless the microcontroller has native support for USB built-in, like some of the 8051-class devices). The reason I prefer the FT245M is because it comes with USB port already soldered on, with electronics and all that jazz needed. It's costly at $25 a pop, but you get a lot of bang for the buck.

The FT245M looks like an RS-232 device to the host PC. Drivers for it are included with every Linux kernel (you may need to recompile the kernel to get ahold of the kernel module though; but if you're using Linux, you probably already know how to do this). Drivers for Windows are freely downloadable. I believe Mac sees it correctly out of the box.

You'll need to invent a download protocol for use over the USB port. This could be something as simple as X-Modem, but it would be nice if it were more generic, and capable of bidirectional flow of data. This would allow the USB chip to be used for implementing a VNC server, for example, allowing for remote instrumentation and visualization or, if you've the bandwidth, even simple games.

I/O

The sole VIA chip it has is plenty sufficient to implement the serial interface bus that Garth and I designed recently on this forum. This serial interface bus is substantially faster than Commodore's serial bus, even when bit-banging. This is because it's a fully synchronous protocol, always transfers two bits at a time (one to, and one from, the addressed peripheral), and has explicit packet framing via select pins (versus "soft-addressing" via IEEE's approach).

Therefore, it is easy to expand the Kestrel-1 with other peripherals, provided you have a suitable BIOS or OS to interface the bus with. NOTE -- because I'm spending more of my time designing the Kestrel-2 firmware, I haven't had the opportunity to research the software protocols for this interface. However, it's designed to be operable without this; because the bus is a superset of the SPI bus, any valid SPI peripheral is usable via the bus interface. Therefore, the protocol you'd use is that of the SPI peripheral you're addressing.

For the purposes of developing the OS for it, I can create a Kestrel-1 emulator if desired, at least for Linux, using my lib65816 package.

Newbie Friendly

I do not believe that the 6502 is any more newbie friendly than the 65816. In fact, in some respects, I think it's more user hostile, because of the need to explicitly handle multi-byte quantities manually. The 65816 at least is able to handle 16-bit quantities natively.

Using the 65816's more advanced features is of course optional while teaching someone how to use the system. In fact, since the Kestrel-1 disregards the bank address byte all-together, it is not possible to profitably use the extended addressing modes, since it is confined to a 64K address space, just like the 6502.

Isn't that what we used to call a BIOS back in the day? [/quote]

No.

A BIOS is a library for handling I/O -- think of it as something like the C standard library, where it provides raw (and hardware independent) I/O functions. It is not an OS unto itself.

A monitor will sit on top of a BIOS (even if no BIOS is explicitly exposed to the programmer). A monitor is a software emulation of a real, hardware monitor -- something that is approximately the level of capability as Supermon64 or DOS DEBUG.COM. It lets you load programs into memory, if you're willing to type in hex byte listings (remember those BASIC programs in Commodore Magazine or COMPUTE!? Stuff like that, only even more primitive). It lets you execute programs by invoking these hex listings as subroutines (via the G command, usually). Etc.

An OS is a full-blown system that lets the user administer his computer. It not only includes a "kernel," but also all the commands that ships with it, all dynamically or statically linkable libraries, etc.

Strictly speaking, the term "OS", as used above, is more likely closer to "API" (Application Programmer Interface). Calling it "the OS" is technically incorrect.

Well, maybe today. But "back in the day" the BIOS was actually used by DOS, so it did not get completely out of the way :-)

André

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I have no preference between 65C02 and 65C816. We will most likely have only 64k of address space.

My thoughts:

If we are talking about keeping the clock at 4-5MHz, it would seem simpler to use (E)EPROM vs. the IPL. We could use three 32kx8 memory chips, use 1 or 2 RAM and 1 ROM. The second RAM could shadow the ROM and the ROM could be switched out (via switch for simplicity, or via logic if desired). This would keep the chip count down and provide a method for placing user programs into the upper address space. The second RAM would be optional, to save cost for those who don't want the feature.

Since the 65C51 is questionable, I suggest our main SBC have the CPU, RAM, ROM, and 2 or 3 65C22's, decoder and support logic.

If we agree to use a 65C22 as the interface to the User IO daughter board, then I think we could skip the bus interface design specifications.... we could just write board specific IO routines for each type of daughter board created.

IO is passed through one 65C22 to a daughter board connector. You could daisy-chain multiple daugher boards through this one connector if needed. We could have RS-232 terminal access, keyboard/video, or USB options for the daugher boards.

The other 1 or 2 65C22's can be used for experimentation.

Would we would want to provide an expansion bus with the CPU's address & data bus, R/W, Clk2, RES, etc.; or keep is simple with this format? We are already looking at 7 devices on the address bus and 6 on the data bus.

Daryl

Of course ROM is preferable to an IPL circuit -- it certainly is more reliable. However, I do not have an (E)EPROM programmer, nor did I want to build one for a circuit so simple and cheap. I mean, it literally cost me about $20 total for all the parts. An EEPROM programmer would have doubled that figure easily. Then you have to find a programmer driver for it, or write your own (in which case you'd have to find the algorithm used to program it with, which isn't always documented clearly, and can be quite complex).

How are you planning on using the 6522 to talk to the I/O devices? PA0-PA7 for a data bus, with some pins from PB to serve as R/W, PH3 (I can't think of a better name ), and A0-A3? Or will it be more like an IEEE-488 bus?