Re: 6809 SBC in development



On Mar 1, 2:44 pm, lynchaj <lync...@xxxxxxxxx> wrote:
On Mar 1, 7:51 am, Dave.Dunfi...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

(Dave Dunfield) wrote:
Hi All!  I am building a 6809 SBC for the N8VEM system.  It will be on
an ECB board in an ECB backplane.  It will use the N8VEM system as its
IO processor.  All the information for hardware, software, and other
design material will be free and publicly posted as part of the N8VEM
home brew computing project.

Hey Andrew,

Glad to see you are still producing projects - the 6809 is probably my
favorite 8-bit architecture, so it's always good to see it being kept
alive.

Hi Dave!  Thanks!  I have always liked the 6809 too.  Its a really
neat CPU and probably the best of the line of the Motorola 8 bit
processors.

I've for a ton of 6809 code which might be useful to you, including a couple
of pretty decent monitors (simple hardware-debug monitor which uses NO
RAM - no even for a stack, and a fairly nice software debug monitor with
lots of goodies).

Thanks!  That's great!  I'll bet those will be useful!

This board sounds like it would be a good candidate for my CUBIX OS.
I've added a "Information on CUBIX" link to my 6809 homebuilt page at:

   www.classiccmp.org/dunfield/d6809/index.htm

Yes!  That's great!  I've seen your CUBIX system and it is really
nice.  The 6809 SBC I'm making is really a dual processor.  I am
calling it a "host processor" as I am not sure of its actual name.  In
short though the 6809 communicates through a 6821 via 8255 to a Z80
system doing almost all of the system IO.  From the 6809 perspective,
it should be rather easy to implement IO since it is all based on the
6821.  The rest of the detailed IO (serial, parallel, RTC, FDC, IDE,
etc) will have to be handled by the Z80 IO processor.

Please check it out and see what you think.

Will do!  Thanks!  I think a CUBIX port would be great!  My prototype
build is going well but it hit a snag today.  I had two 28C16 EEPROMs
set aside for this project but when I went to test them they are both
bad.  :-(  I've had them for quite a while but hadn't used these
particular chips before.  I tested them in two different EPROM/EEPROM
programmers and they each fail differently.  I'll probably substitute
plain 2716's until I can get some replacement 28C16s and those should
work, I hope.

"Ira Baxter" said:

The instruction sets on these guys is so simple that you should be able to
code a C simulator in a few thousand lines at most, that likely outperforms
the  original chip.

I've posted a PC based simulator for my 6809 homebult at the page
mentioned above, and yes it's much faster than the original machine.
Not the same however ... nothing beats the satisfaction you'll get from
building a working physical/tangible computer system with your own
hands.

Dave

Well said!  Nothing beats real hardware.  Thanks and have a nice day!

Andrew Lynch



--
dave09@     Low-cost firmware development tools:  www.dunfield.com
dunfield.   Classic computer collection:  www.classiccmp.org/dunfield
com        - Hide quoted text -

- Show quoted text -

Hi! Good news! I was able to finish building the 6809 prototype this
evening and do the wring out against the schematic. It works!
Yahoo! If you would like to see some fuzzy pictures of the prototype
I uploaded them in the N8VEM wiki in the m6809 folder.

I am using a two 2716 EPROMs instead of the 28C16 EEPROMs I meant to
use since both of my 28C16s were bad. The 2716s work but require the
Data IO 29B to program them. Apparently they are so "old school" that
any of the recent EPROM programmers can't handle the required
programming voltages. I think I dig around and see if I can't find
some 27C16s which might work.

The two programs I am running are extremely simple and its not even
all that apparent they are running right away. With the oscilloscope
I can tell they are working or at least they are doing what I'd expect
them to be doing.

The first one is just the basic jump loop to see if the CPU is
responding to a reset. The reset vector sends the CPU into a single
instruction program that jumps to back on itself endlessly. It
doesn't do much but it tells you a lot in what it doesn't do. It
helps check out the chip selects, data, and address lines to make sure
they are responding normally and no funny stuff where it shouldn't be.

The second program is a little more exciting as it is sends an
increasing sequence of bytes to the PIA output port A. You can tell
its working because the chip selects on the ROM and PIA are
oscillating back and forth. Also the PIA outputs have a decreasing
sequence of square waves. PA0 is a square wave, PA1 is 50% PA0's
frequency, PA2 is 25%, etc.

So its been a good day. The 6809 SBC is up and running. What's next
is to attach the 8255 to the 6821 and start the communication between
the parallel IO chips. The first part is easy which is to just hook
up the parallel data lines. That should be OK. Then the hard part is
to get the control lines connected and the programming on the 6809 and
Z80 to set up some handshaking.

Thanks and have a nice day!

Andrew Lynch
.



Relevant Pages

  • Re: 6809 SBC in development
    ... design material will be free and publicly posted as part of the N8VEM ... helps check out the chip selects, data, and address lines to make sure ... Z80 to set up some handshaking. ... attached to the port B of the 8255. ...
    (comp.sys.m6809)
  • Re: How to develop a random number generation device
    ... Windows, or more accurately M$, *is* the problem. ... Yes, the OS is part of the problem/solution, but it needs hardware help. ... chip, and something new will be required to manage them. ... and hardware summaries. ...
    (sci.electronics.design)
  • Re: Can i8042prt.sys crashes be avoided?
    ... it sounds like malfunctioning hardware to me. ... most laptops have an Fn+key ... If the i8042 chip did not overheat then I have ... > Is there really no way for the driver to command the chip to reset itself? ...
    (microsoft.public.development.device.drivers)
  • Re: How to develop a random number generation device
    ... Windows, or more accurately M$, *is* the problem. ... Yes, the OS is part of the problem/solution, but it needs hardware help. ... chip, and something new will be required to manage them. ... The whole list at livermore, ...
    (sci.electronics.design)
  • Re: Protecting Encryption Algorithms
    ... The NGSCB includes specialized hardware that makes doing this ... >> erase everything on it (including the algorithm). ... I can describe the TCPA chip more specifically because that is what I ... It comes built in with one private key that never leaves ...
    (sci.crypt)

Loading