I finished my first 65816-based SBC in less than an evening. Check out these awesome specifications:

* 65816 running at a break-neck speed of 81.3kHz
* NE555 chip as the clock generator
* 8KiB of static RAM
* 16 bytes of I/O
* Hand-designed, fully custom address decoding chip, available for order as the 74LS00.

Move over Intel, look out AMD. This little computer is a screamer.

(The LS in the 74LS00 stands for Little Screamer. ;D)

Pictures and a website for it will be coming soon.

The computer is my very first 65816-based project. It's the simplest possible 65816 computer implementation. RAM sits from $E000-$FFFF, and I/O space is a single VIA, mirrored throughout $0000-$7FFF. I can get away with this because of the 65816, in native mode, supports relocating the direct page and stacks into higher memory. But I've found there are times when having DP at $0000 is quite handy, as it allows me to use DP-addressing to talk to the VIA chip. This is quite a handy little feature when you have to hand-IPL (initial program load) the bootstrap code into RAM.

It is constructed on only two Radio Shack white breadboards (the long variety), and a whole *mess* of wires. I've seen projects using the 8088 that use these boards too, and they can handle up to 5MHz with good construction techniques. I doubt my construction techniques are all that good, however, as the IRQ line from the VIA to the CPU is, while not strong enough to trigger a spurious interrupt that I can see, VERY noisy. Interestingly enough, all the lines with long wires are *sharp* and solid (these include the address and data lines).

I use a single 74LS00 chip as the address decoder. Two of the four gates are used as inverters. The other two gates are used to generate the RAM's OE and WE signals.

The circuit worked first time, and until I figure out a good communications protocol between the PC and the Kestrel, I'm relatively restricted in the software I can hand-download to it.

Congratulations on your success!!

My first SBC used a 6526 or 6522 also. I designed a serial protocol using the PC parallel port. I wrote a DOS-based terminal program to use on the PC and the necessary code to use on the SBC.

If you are interested, here's a link to the terminal info:

http://www.softcom.net/users/darylr/sof ... cterm.html

The download page has both the terminal program and the SBC Monitor code available.

Good luck with your continuing efforts.

Daryl

Thanks. I'll take a look, but I run Linux, not Windows.

Also, I was thinking of going with a serial loop interface. The idea I had was to bit-bang the output (e.g., use PB[0..1] for the output "serial" port) and the 6522's serial port as the input port. The idea being, since receiving is always more real-time than sending is, I figured it'd be easier to just let the hardware do all the hard work.

Also, if I get a byte while transmitting another, I can safely interrupt the output routine to process the SR's interrupt, without causing corruption in the sent data (it just takes longer to send).

If you are running Linux, than I doubt my code will help. I wrote my terminal program in MS QuickBasic. Your idea sounds like it will work pretty well too. I have never posted the source code for my terminal program, if you decide you want to have a lok at it, let me know. It would not be too hard to convert to C.


Daryl

Well, I tried making a simple, hand-driven "front panel" if you will, using a series of resistors and by manually wiring the address and data buses with the required information. After programming about two bytes, I snapped three wires in the process, and determined that that was not a good route to go for patience's sake.

So I'm going to have to come up with a PC-controlled (via parallel port) IPL mechanism. But I'll do that after. For now, I'm going to stick with what I have, and put up my website.

I'm just glad that it works at all, even if I cannot load any legitimate program into it yet.

I have a website up which more or less describes the Kestrel 8K, and has pictures. Of course, more details will be forthcoming as both people ask me and as time permits.

One thing that is not yet up on the site is the circuit schematic. This will be coming soon. I expect to have a pretty-printed schematic sometime next week.

http://www.falvotech.com/projects/kestrel/8k.php

The Kestrel 8K website ( http://www.falvotech.com/projects/kestrel/8k.php ) now has schematics in PDF format for download or viewing. Additionally, the raw gEDA sources are also available. In the gEDA sources, you'll find the 65C816 and 65C22 schematic symbols that I custom-made to facilitate drawing the schematic.

Please let me know what you think.

NOTE: This is "revision 2", which although the name suggests it's an 8K machine, it now addresses 32K of RAM. Revision 1 was only 8K because, well, that's all I have at the moment.

I like the design and especially the IPL solution! Great for testing via crossdevelopment.
Do you have some source examples how to control the IPL process?

Thanks for the vote of support. I know many people on this board have discussed this solution in the past, but nothing practical as come from it yet. I do easily see that using a ROM chip is "easier" from a hardware perspective (and why not if you already have an (E)EPROM programmer?). Unfortunately, spending the $3 for the TTL-HC chips plus the cost of a straight-thru male/female 25-pin cable is still less than half the cost of even the cheapest EEPROM programmers that I've seen on the web, including many home-made units. For me, it is not a matter of convenience -- it is a matter of minimizing cost. It does complicate printed circuit board routing though.



Not just yet. I only recently received the parts, and haven't build the hardware yet. I should hopefully make a start on the IPL hardware/software combination this coming week. I'm eagerly looking forward to playing with it.

Note that the software I'll be writing is for Linux, and will be written in C, because no Forth implementations for Linux are able to talk to the hardware directly. The C sources, however, should be relatively easily ported to the Windows environment, as all hardware-related functions will be abstracted into its own source file.

The theory of operation is pretty simple though. When IPLing the system, the first thing the IPLer does is use the SERDATA and SERCLK lines to fill the shift registers with all 1s. It then strobes the PUBLISH line (hooked up to STCLK inputs on the '595s) to actually make them visible outside the shift registers. Note that _OE is still negated at this point, so the 595 outputs are still in high-impedance state. This guarantees that the "state of the bus" is in a well-known state, when _OE is enabled later on.

Next, the fun begins: it needs to assert the _RES line. This obviously places the CPU into the reset state. Next, it negates the BE signal (aka asserting _PGM). This removes the 65816 from the bus completely. This is required because the 65816 will still drive the bus even while _RES is asserted. In my circuit, though, I found a rather rude surprise -- the 65816 apparently still drives the bus when BE is negated during Phi2 low. Not sure why this is -- I've verified that BE is held low on the breadboard, and I'm not seeing any noticable ripple on it.

Next, _OE is asserted, which places the 74HC595s onto the bus. Two '595s are used to drive the address bus. One drives the data bus, but does so through buffer resistors, because from what I've observed in the oscilloscope traces, the 65816 somehow still manages to drive the databus even when BE is negated. The last 595 chip only has one output -- R_W -- which because of the initialization step above, is now held in the non-destructive, 'read' state.

NOTE: For those 65816 systems that permit addressing more than 64K of memory, the unused pins on the last '595 permit addressing up to 8MB of address space.

Now that _OE is asserted, the steps to write a byte to memory are as follows:

1. Shift in the R/W byte ($00 for write).
2. Shift in the data byte.
3. Shift in A15-A8.
4. Shift in A7-A0.
5. Pulse the PUBLISH pin high briefly. That will cause all outputs to update concurrently, thus forming a new bus transaction.
6. Shift in the R/W byte ($80 for read). We need to do this to "cleanly" terminate the bus transaction, since we could be updating R/W during phi2 high!
7. Shift in the *same* data byte.
8. Shift in the *same* A15-A8.
9. Shift in the *same* A7-A0.
10. Pulse PUBLISH again.

Since Phi2 is running independently of the IPL mechanism, you'll need to make sure that the address, data, and R/W state remain valid for at least one complete Phi2 cycle. It's obviously safe to continuously write to the same RAM address. And provided the address and data lines are consistent, it *should* be OK to change the state of _OE/_WE on a RAM chip, since they are all passive logic anyway.

When you're done downloading the program to the RAM, the following steps are performed:

1. Strobe all '1's back into the shift registers, and publish it, to set it back to a known safe state (well, really, all we care about is that R/W goes back high)
2. Negate _PGM (aka assert BE).
3. Negate _RES (which should now let the microprocessor run its course while booting).

I soon hope to have timing diagrams and documentation detailing the above discussion, and maybe with a little more detail in the description given above. If you have any questions with what I've given above, though, I'd love to hear them, so I can take those into consideration when I publish the *cough* Hardware Reference Manual *cough* for the Kestrel 8K.

Thanks for the vote of support. I know many people on this board have discussed this solution in the past, but nothing practical as come from it yet. I do easily see that using a ROM chip is "easier" from a hardware perspective (and why not if you already have an (E)EPROM programmer?). Unfortunately, spending the $3 for the TTL-HC chips plus the cost of a straight-thru male/female 25-pin cable is still less than half the cost of even the cheapest EEPROM programmers that I've seen on the web, including many home-made units. For me, it is not a matter of convenience -- it is a matter of minimizing cost. It does complicate printed circuit board routing though.



Not just yet. I only recently received the parts, and haven't build the hardware yet. I should hopefully make a start on the IPL hardware/software combination this coming week. I'm eagerly looking forward to playing with it.

Note that the software I'll be writing is for Linux, and will be written in C, because no Forth implementations for Linux are able to talk to the hardware directly. The C sources, however, should be relatively easily ported to the Windows environment, as all hardware-related functions will be abstracted into its own source file.

The theory of operation is pretty simple though. When IPLing the system, the first thing the IPLer does is use the SERDATA and SERCLK lines to fill the shift registers with all 1s. It then strobes the PUBLISH line (hooked up to STCLK inputs on the '595s) to actually make them visible outside the shift registers. Note that _OE is still negated at this point, so the 595 outputs are still in high-impedance state. This guarantees that the "state of the bus" is in a well-known state, when _OE is enabled later on.

Next, the fun begins: it needs to assert the _RES line. This obviously places the CPU into the reset state. Next, it negates the BE signal (aka asserting _PGM). This removes the 65816 from the bus completely. This is required because the 65816 will still drive the bus even while _RES is asserted. In my circuit, though, I found a rather rude surprise -- the 65816 apparently still drives the bus when BE is negated during Phi2 low. Not sure why this is -- I've verified that BE is held low on the breadboard, and I'm not seeing any noticable ripple on it.

Next, _OE is asserted, which places the 74HC595s onto the bus. Two '595s are used to drive the address bus. One drives the data bus, but does so through buffer resistors, because from what I've observed in the oscilloscope traces, the 65816 somehow still manages to drive the databus even when BE is negated. The last 595 chip only has one output -- R_W -- which because of the initialization step above, is now held in the non-destructive, 'read' state.

NOTE: For those 65816 systems that permit addressing more than 64K of memory, the unused pins on the last '595 permit addressing up to 8MB of address space.

Now that _OE is asserted, the steps to write a byte to memory are as follows:

1. Shift in the R/W byte ($00 for write).
2. Shift in the data byte.
3. Shift in A15-A8.
4. Shift in A7-A0.
5. Pulse the PUBLISH pin high briefly. That will cause all outputs to update concurrently, thus forming a new bus transaction.
6. Shift in the R/W byte ($80 for read). We need to do this to "cleanly" terminate the bus transaction, since we could be updating R/W during phi2 high!
7. Shift in the *same* data byte.
8. Shift in the *same* A15-A8.
9. Shift in the *same* A7-A0.
10. Pulse PUBLISH again.

Since Phi2 is running independently of the IPL mechanism, you'll need to make sure that the address, data, and R/W state remain valid for at least one complete Phi2 cycle. It's obviously safe to continuously write to the same RAM address. And provided the address and data lines are consistent, it *should* be OK to change the state of _OE/_WE on a RAM chip, since they are all passive logic anyway.

When you're done downloading the program to the RAM, the following steps are performed:

1. Strobe all '1's back into the shift registers, and publish it, to set it back to a known safe state (well, really, all we care about is that R/W goes back high)
2. Negate _PGM (aka assert BE).
3. Negate _RES (which should now let the microprocessor run its course while booting).

I soon hope to have timing diagrams and documentation detailing the above discussion, and maybe with a little more detail in the description given above. If you have any questions with what I've given above, though, I'd love to hear them, so I can take those into consideration when I publish the *cough* Hardware Reference Manual *cough* for the Kestrel 8K.

Sorry for the duplicate post -- my web browser timed out while submitting the update, so I tried to submit again, and it posted nearly instantaneously. Oops.

OK, well, in my explorations with this, I've had quite a bit of trouble getting software loaded into the Kestrel's RAM. First, I found that, in the interest of increased reliability, I just had to feed the clock back to the computer so that it can synchronize the bus cycles against ph2. I was hoping that I could get away without having to do that, but alas, such is not the case.

Since the PC parallel port isn't fast enough to respond to a 4MHz clock, this means that you'll need two clock sources to program the Kestrel -- one for programming (10kHz is fine) and one for running.

However, the clock was a source of some pretty spectacular and infuriating problems. I found that the 555 chip I was using apparently cannot drive the CPU, the VIA, and the parallel port all at the same time. Therefore, in order to get software running on the Kestrel, I must amend the above steps to include connecting the clock to the parallel port's BUSY input prior to programming, and then disconnecting it after programming is complete. Then, and only then, does the CPU seem to get kickstarted into running code.

*sigh* Sounds like I'm going to have to rework the schematics so that Kestrel Rev 3 takes this into account.

It ran several programs today, mostly just small, diagnostic programs. Still, though, I'm really pleased to finally see it doing something!! Here's the latest piece of diagnostic code that it ran:



The above syntax is ACME syntax, one of the few 65816 assemblers for Linux that is actually reliable (it was originally written to support SNES coding).

The next step is to write code that "broadcasts" CQ on PA0 of the VIA.

OK, I tried getting it to execute some more sophisticated code. The problem is, it's not working very well at all. The software gets to a certain point, and then it appears to halt the processor all-together.

I do not know what can cause this. A couple of times, I found the RDY signal go low -- indicating that it was waiting for an interrupt (WAI). I absolutely didn't use WAI in my code.

Usually, though, RDY remains high, and the processor nonetheless *still* grinds to an absolute halt. What could be causing this? It's like the CPU just *freezes*.

Sometimes, I can kick the CPU into working again by disconnecting the

I did some Googling on CMOS latch-up, but nothing has helped mitigate this problem. It's still very unreliable.

New Kestrel Schematics Uploaded

The schematics online at my website now accurately reflect the current state of the now-running hardware. Changes include the clock circuitry (replaced the 555 with the clock oscillator module), and modifications to the IPL circuitry.

It's reliable too -- I've hammered the RAM and VIAs with the most tortuous write-testing I've been able to come up, and it has run for hours without failure.

http://www.falvotech.com/projects/kestrel/8k.php

Now, for my next question, and this is really for Mike. What are the current prices for a W65C816S8P-14 and W65C22SP-10 or their relative replacements? I'm asking because I'd like to put a small bill of materials on the website. I've got prices and sources for everything else; but if I can help the site by directing potential business Mike's way for the CPU and VIA sales, I will.

Is there any particular reason you didn't go with AHC (Advanced High-Speed CMOS) logic in the new Kestrel?