Yet another SBC build.

[janik]

Hello folks,

Couple of friends (ccureau, Bor_ed) and I threw some ideas around some months back about building our own singleboard computer which would be based, ofcourse, on 6502 or 65816. Having said that, what followed was some tight discussions upon features over complexivity of the design which I think I rather won .. so this is rather more how I envisioned it.

The system specifications:

Using a 65816 CPU on a separate CPU-board that only has the de-multiplexing logic on it along with oscillator and couple of other components. The reason for going this route (having a separate CPU-board and "mainboard") is two fold. Firstly, to reduce the size of the actual "mainboard" to be able to hopefully to fit it inside the limits of cheap PCB manufacturers and secondly, this approach allows the usage of 6502 or 65816 CPU on this system. The system is designed so that only lowest 64kByte can be used with 6502 and still have a fully functional design while using a 65816 with additional 8 bits worth of decoded address-bus will allow the usage of the additional memory sitting above 64kByte barrier.

The CPU-module connects to the actual "mainboard" which has address-decoding logic for low-RAM (0k to ~56k), 8 16byte sized I/O blocks above that and finally ROM area where we have a 8kByte EEPROM sitting at. This constitutes as the low 64kB area of the memory map. Above that from 64kByte upwards to 16MByte memory top is where a single 30pin 8bit SIMM-socket sits at together with a CBR-refreshing logic circuitry. a 6502 has no access to this area of the memory while 65816 can use this for add-on RAM.

What else sits on the "mainboard" is a Dallas RTC chip to keep time as well as to handle power-on reset and store some default settings in it's internal NVRAM. This serves mostly the purpose of the operating system that will get written for the system.

Then there's the two VIA 6522 chips that serve a variety of purposes. Hanging off from these there is a full 16bit 2,5" IDE interface and a Centronics port along with ps/2 interface for keyboard and some system control lines for LEDs and EEPROM control. Yes, the system is designed to be able to re-write the EEPROM chip in-place.

In addition to the above, we have an 16550 + MAX233 driven rs232 interface along with two Atari style joystick ports. Envisioning to get a mouse and joystick there

Oh, and the compulsory GeekPort(tm) is routed to a connector with remaining I/O block select lines to connect any additional hardware into the system. The system has NMI connected from one VIA to serve as a timer for task-switching for the operating system and IRQ line is routed via a second VIA so that we can easily check which source caused the IRQ.

The status as of writing this is that the schematics are done and preliminary prototype has been build on a breadboard. I will be starting to get some test-code into the thing and test-run it to check that everything works as designed hopefully this weekend.

Questions and comments very welcomed.

[8BIT]

Your system sound very capable and well thought out. You might consider an ethernet port in addition to the others.

Also, there is an IDE to Compact Flash adapter for sale on Ebay for ~$12 that could be used with your IDE port to allow solid-state permanent storage vs. an actual mechanical hard disk. An actual CF socket runs ~$8 from digikey, so the adapter cost was very reasonable.

Do you plan on supporting the FAT16 file format or will you use another format? (FAT16 would be great for CF as they could be swapped from SBC to PC for development of software and data transfer)

I like your SIMM schem as well for filling the 16MB memory map.

I hope you will post your schematics at some point, in addition to your firmware, once its completed.

Good luck and if I can help with anything, please don't hesitate to ask.

Daryl

[janik]

8BIT wrote:

Do you plan on supporting the FAT16 file format or will you use another format? (FAT16 would be great for CF as they could be swapped from SBC to PC for development of software and data transfer)

We haven't thought to that extend as of yet, but the idea certainly is a very good one.

8BIT wrote:

I hope you will post your schematics at some point, in addition to your firmware, once its completed.

Certainly, the schematics will be published as soon as I'm sure they perform as designed without any serious "side-effects". We will be putting up a website to display this design as well as the friends own designs along with software for them soon'ish I hope..

[asm_2750]

You know I always liked Lee Davidsons' IDE setup, my only problem is that I couldent find the GAL chip that was in the schematic, that could be one way to interface with an IDE device. The rest of the setup is mostly TTL chips and and IDE connector and a connector to the 6502.

[janik]

Update:

The system ran it's first piece of test-code yesterday evening resulting an glorious "foo" being outputted to the terminal window of an another machine. Took only two tries no less due to not thinking straight with the character codes the first time around

To come: Another, more complete, piece of test-code is being written to test as much as possible of the functions on-board. Once satisfied, an actual firmware writing will start.

I'll try to take some pictures of the wire-mess of the SBC, the CPU module as well as my "manual" EEPROMmer I used to program the test-code into the EEPROM chip.

[leeeeee]

Quote:

my only problem is that I couldent find the GAL chip that was in the schematic

It can easily be replaced by an equivalent device, basically any 16x8 or bigger device, or by discrete logic, the equations file for the GAL gives all the logic involved.

A couple of 74LS138s could do most of the work.

Lee.

[RichCini]

leeeeee wrote:

Quote:

my only problem is that I couldent find the GAL chip that was in the schematic

It can easily be replaced by an equivalent device, basically any 16x8 or bigger device, or by discrete logic, the equations file for the GAL gives all the logic involved.

A couple of 74LS138s could do most of the work.

Lee.

Actually, I want to use this setup in a board of my own. Both Atmel and Lattice make 16V8 (and bigger) devices, but you have to look a bit on their Web site for them as they are not the "newest" products carried by these manufacturers.

[bogax]

leeeeee wrote:

Quote:

my only problem is that I couldent find the GAL chip that was in the schematic

It can easily be replaced by an equivalent device, basically any 16x8 or bigger device, or by discrete logic, the equations file for the GAL gives all the logic involved.

A couple of 74LS138s could do most of the work.

Lee.

I've been thinking about this just recently. Here's what I
came up with. Maybe some one would like to check me.

Here's the picture:

Code: Select all

         ____       ___       ___       ___       ___       ___
     CLK     \_____/   \_____/   \_____/   \_____/   \_____/   \
          _ ______________________
     R/W                          \____________________________
          _ __           _________           _________         
     A0       \_________/         \_________/         \________
         _____       _ ________________________________________
     RLE      \_____/_/
         _____       __________________________________________
 IOR,RHC      \_____/   
         _______________       _ ______________________________
     RHE                \_____/_/
         _________________________       ______________________
     WLC                          \_____/
         ___________________________________       _ __________
     WLE                                    \_____/_/
         ___________________________________       _ __________
     WHE                                    \_____/_/
         ___________________________________       ____________
     IOW                                    \_____/

                 _____
    R/W ---+----|A  Y0|
     A0 ---)-+--|B  Y1|
           | |  |C  Y2|
           | |  |   Y3|
           | |  |   Y4|--WLC
     IO -+-)-)--|/G Y5|--IOR,RHC
    CLK -)-)-)--|/G Y6|--IOW
         | | |  |G  Y7|
         | | |  |_____|
         | | |
         | | |   _____
         | +-)--|A  Y0|
         |   +--|B  Y1|--RLE
         |      |   Y2|--WLE,WHE
         +------|G  Y3|--RHE
         |      |_____|
         |
         |       _____
     A4 -)------|A  Y0|
         |      |B  Y1|
         |      |   Y2|--CS0
         +------|G  Y3|--CS1
                |_____|

Here's the thousand words

The idea is to multiplex 8 data lines to 16 data lines with
the 16 word aligned on the 8 bit side, that is when address
line 0, ie A0, is 0 we'll read/write the lower 8 of 16 and
when A0 is 1 we'll be reading/writing the high 8 of 16

We'll write the low byte to a register and then write the
high byte directly to the high 8 data lines of the 16
through a tristate buffer while the register drives the
lower 8 data lines of the 16.

For reading we'll read the lower 8 of 16 data lines directly
through a tristate buffer while simultaneously clocking
the high 8 data lines into a register and then we'll read
the high 8 from the register.

So when we read a byte from an address with A0=0 we'll do
a read of the 16 data lines but not when we read with A0=1

When we write to an address with A0=1 we'll do a write of
the 16 data lines but not when we write with A0=0

So we can read/write the 16 bit words a byte at a time in
ascending sequence, little endian style

The basic synchronous bus philosophy is to strobe stuff
on to the bus then provide a clock edge in the midst of the
strobe to clock it in to where ever it's going.

It might be possible to make clocks double as stobes or strobes
double as clocks, but I think that's sloppy, so we need two
decoders, one for strobes and one for clocks.

Four possibilities: write lo, write hi, read lo, read hi

For writing lo, with R/W=0 and A0=0, we need a clock for the
write register, WLC

For writing hi, with R/W=0 and A0=1, we need an enable for the
buffer to strobe the hi byte onto the hi 8 of 16, call it WHE
We also need to enable the previously written write register,
ie strobe the lo byte on to the lo 8 of 16, call it WLE and
since WHE and WLE are always simultaneousm, ie they both occur
iff R/W=0 and A0=1 they can be the same signal.

For reading lo, with R/W=1 and A0=0, we need a strobe to strobe
the lo 8 of 16 on to the 8 bit side, call that RLE and a clock
to clock the hi 8 of 16 in to the read register. Call that RHC

For reading hi, with R/W=1 and A0=1, we need to strobe the
read register on to the 8 bit bus, call that RHE

We also need strobes and clock(s) for the 16 bit reads and
writes.
IDE has two strobes CS0 and CS1 depending on the state of A4
and seperate clocks for reading, IOR, and writing, IOW,
IOR occurs simultaneous with RHC so they can be the same signal.

So we need five strobes
three for the eight bit stuff: WHE-WLE, RLE, RHE
and two for the 16 bit stuff: CS1, CS0

And we need three clocks: WLC, RHC-IOR, IOW

We'll assume an over all strobe/enable/select (whatever you like)
for the multiplexer which I'll call IO and a (the) clock
for timing.

For the 8 bit strobes we need to know if were reading or writing
and are we reading or writing an odd or an even location
and we'll enable them only while IO is active so we need to
decode R/W, A0, and IO, and IO is a gate/enable
2 inputs to decode and a gate for the decoder, so half of a
74139 will work

Same for the 8 bit clocks so we'll decoded from R/W, A0 and gate
with IO but we'll also gate them with the clock
2 inputs and two gates/enables so a 74138 for that

CS1 and CS2 just split the IDE address according to A4 so we just
need A4 and IO for them
2 inputs so there's the other half of the 74139

For the IDE clocks, IOW occurs iff we're writing a hi byte and
IOR iff we're reading a lo byte
so the same 4 inputs as the 8 bit clocks, so we can take them
from the same 74138

And I'd tie the unused inputs high on the (possibly spurious)
theory that it's better to source 40uA than sink 1.6mA


I don't know IDE. The thing I particularly wonder about is:
is there any harm in, or reason not to select CS0 or CS1 when
you're not either reading or writing to the IDE?

If there is, I guess I'll use the other half of 74139 for
something else and decode CS0 and CS1 from RLE, WHE and A4

like so:

Code: Select all

          ___
  RLE----|   \          ___
         |    |O-+-----|   \
  WHE----|___/   |     |    |O--CS1
                 |  +--|___/
                 |  |
  A4 --+---------)--+
       |         |      ___
       |   ___   +-----|   \
       +--|   \        |    |O--CS0
       |  |    |O------|___/
       +--|___/  

[janik]

Just an update:

It has been a while and not much has been happening during that time due to various school and work-related delays. However, I managed to run some test-code in the system and stumbled upon couple of things that need fixing. One problem with the SIMM memory and one with I/O timing signals.

The SIMM problem was easy enough to fix, but the timing problem seems much harder. I'm looking at two GAL chips to replace the whole bunch of TTL logic that makes up the whole address-decode and memory control circuitry respectively. This will hopefully remedy the problem with apparently conditional garbage on buses that causes rather.. hmm.. 'intresting' results Needing to build a GAL programmer for this and re-build part of the board. Once it is done, I will let you guys know how it turns out.

More updates to come as they happen.

[janik]

Update:

GALBlast built and couple of GAL16V8's aquired along with most of the SBCs discrete TTL logic area re-designed to accommodate the said chips. Trying to bend my brain around the programming language for GAL chips so I hopefully get to do tests soon.

[Tancor]

Hi,

How are you handling the refresh on the simm?

Also at this point, what frequencies are you running it at? What's the max where it has still worked repeatedly?

Are you doing all source development in assembly? what assembler (or compiler and assembler if not just using assembly) are you using?

[8BIT]

RichCini wrote:

Actually, I want to use this setup in a board of my own. Both Atmel and Lattice make 16V8 (and bigger) devices, but you have to look a bit on their Web site for them as they are not the "newest" products carried by these manufacturers.

Be careful of the Atmel ATF16V8C devices. My programmer won't program them. I just bought a Lattice GAL16V8D-15 and it programs just fine. I recall reading in the Galblast documents that it won't program the Atmel ATF devices either.

Daryl

[janik]

Tancor wrote:

How are you handling the refresh on the simm?

I'm utilizing the built-in CBR (CAS-Before-RAS) refresh capability on the DRAMs on the SIMM module. I'm using inverted CPU clock along with NAND gates to invert the normal RAS->CAS cycle to init the refresh. The refresh occurs therefore at every clockcycle which ought to be fast enough although I'm slightly worried about whether the same access time restrictions that apply for normal read/write cycles apply also to the refreshing causing corrupted data?

Tancor wrote:

Also at this point, what frequencies are you running it at? What's the max where it has still worked repeatedly?

All initial tests were done by running the SBC at the 1.8432Mhz clock normally used by the 16550 chip for rs232. After those tests showed, that there's nothing major wrong with the design and that it appeared to be working (ie. I managed to get it to output me stuff via rs232 and access various i/o chips) I upped the clock to 10Mhz sharp. In theory, using a 70ns SIMM module would allow me to push the design to full 14Mhz as rated by the WDC chips used. How ever, at 10Mhz speeds, I noticed the conditional garbage on buses which might have been present at lower speeds also because I didn't really do anything extensive enough for it to be appared, but I doubt it.

Tancor wrote:

Are you doing all source development in assembly? what assembler (or compiler and assembler if not just using assembly) are you using?

Currently only some pieces of test-code upto couple of dozen opcodes has been written to test the hardware. All this has been done by assembling by hand and programming the EEPROM by hand manually. When we're starting the Firmware and Operating System writing, we're going to be moving into mostly C for this purpose. Ccureau has been looking into various options for decent C-compiler and Assembler that have 65816 support.

8BIT wrote:

Be careful of the Atmel ATF16V8C devices. My programmer won't program them. I just bought a Lattice GAL16V8D-15 and it programs just fine. I recall reading in the Galblast documents that it won't program the Atmel ATF devices either.

All of my 16V8's and 20V8's are Lattice parts so I ought to be okay with GALBlast yes?

[Tancor]

janik wrote:

I'm utilizing the built-in CBR (CAS-Before-RAS) refresh capability on the DRAMs on the SIMM module. I'm using inverted CPU clock along with NAND gates to invert the normal RAS->CAS cycle to init the refresh. The refresh occurs therefore at every clockcycle which ought to be fast enough although I'm slightly worried about whether the same access time restrictions that apply for normal read/write cycles apply also to the refreshing causing corrupted data?

Hmm, I had never thought of using simm modules before, only dram chips which kept me away overall 'cause I didn't want to deal with refresh - I didn't realize that simm modules had built in cbr's. I will have consider that for my next version as it would be a lot easier to get a single simm rather then piece together a ton of sram chips.

In terms of access time restrictions and such, I don't know to be honest, but you do bring up a good question with regard to it. If you have a data sheet on the simm, I'd imagine that it would have to tell you what the timing is on triggering refreshes and how long the refresh cycle is?

janik wrote:

All initial tests were done by running the SBC at the 1.8432Mhz clock normally used by the 16550 chip for rs232. After those tests showed, that there's nothing major wrong with the design and that it appeared to be working (ie. I managed to get it to output me stuff via rs232 and access various i/o chips) I upped the clock to 10Mhz sharp. In theory, using a 70ns SIMM module would allow me to push the design to full 14Mhz as rated by the WDC chips used. How ever, at 10Mhz speeds, I noticed the conditional garbage on buses which might have been present at lower speeds also because I didn't really do anything extensive enough for it to be appared, but I doubt it.

I don't know - I don't think I would push it to 14mhz with a 70ns simm 14mhz is a 71.xxx ns cycle, with delays in various IC's, you might get left with too little time to properly extract data from the simm. (if you think about it - if your logic overall takes 10ns from out of your cpu to trigger the ram, that will only leave 60ns at most, 10ns short of the manufacturer stated min access time...

janik wrote:

Currently only some pieces of test-code upto couple of dozen opcodes has been written to test the hardware. All this has been done by assembling by hand and programming the EEPROM by hand manually. When we're starting the Firmware and Operating System writing, we're going to be moving into mostly C for this purpose. Ccureau has been looking into various options for decent C-compiler and Assembler that have 65816 support.

I'd be interested to hear what compiler you end up with - right now I'm working on trying to convert lcc output to use my cross-32 assembler. If I had the money, I would probabyl buy avocets 65816 compiler, but they and WDC are the only ones I could find that had a 65816 cross compiler

-Tony

[janik]

Tancor wrote:

I didn't realize that simm modules had built in cbr's.

It is not a feature of SIMMs, but rather, the DRAM chips themselves.