Close
0%
0%

STEbus 68008

68008 processor board renovation

Similar projects worth following
Renovation of a tried and tested commercial design. Not my own design!

I have the manual, circuit diagram and working boards.
The PAL chips have been read, analysed and recreated.

I modified the board to accept larger RAM chips, and ported EH-BASIC onto it.

As the 68008 is the best fit for interfacing the STEbus, I have used it as the exemplar for future designs.

Dmitry Janushkevich has used this project as the basis for a new design with bigger memory chips, a real-time clock, and on-board bus arbiter. Check it out on Twitter:

https://twitter.com/InfoSecDJ/status/1346532012535009282

and GitHub: https://github.com/dev-zzo/stebus

STEbus_68008.zip

STEbus 68008 files. Manual, circuit, logic, pictures.

Zip Archive - 1.75 MB - 01/05/2018 at 01:45

Download

  • Circuit description from the designer's book

    Keith5 days ago 0 comments

    The second master we look at is the SC008, see Figure 6.27. This board uses the Motorola 68008 processor, IC16, which is the 8-bit version of the powerful 16-bit 68000. Although its data bus is only 1 byte wide, the 68008 uses the same mnemonics as the 68000 and so is software compatible. The chip has 22 address lines and so can access 4 Mb of memory space. Like the STEbus, the 68008 acts on the data acknowledge principle. When it accesses a location the processor waits for a /DTACK signal which terminates the cycle. While waiting for /DTACK the 68008 goes into a wait state; note that the processor clock continues to operate whilst in this state so that the 68008 will not lose the contents of its registers if a cycle takes a long time, in contrast to the 6809. The /DTACK line is open-collector, and three devices can drive it LO - the UART (IC18), the ROM or RAM from the PAL (IC22) and the STEbus control PAL (IC6). Alternatively a cycle can be terminated by /BERR (bus error), which is linked to the STEbus TRFERR* signal thus if an error occurs on the STEbus then the 68008 is informed of it.


    Figure 6.27a The SC008, a 68008 STEbus CPU board.


    Figure 6.27b The SC008, sheet 2.


    The other PAL on Figure 6.27(a) (IC14) is an interrupt encoder. The STEbus ATNRQ*s come onto the board via IC11 to link area 9, where they are joined by the interrupt line from the UART (/UINT). The ATNRQ*s and /UINT can be jumpered to drive the AT0-6 inputs on the interrupt encoder PAL. The PAL looks at AT0-6 and produces three outputs (IPL0-2) which encode the highest-priority interrupt, in a similar way to the PAL example in Chapter 4. In response to an interrupt the 68008 can generate an interrupt acknowledge cycle to retrieve a vector from the bus. Actually the SC008 does not have interrupt acknowledge capability. Instead, in response to an interrupt acknowledge cycle IC14 generates an /INTA signal which is fed into the VPA input of the 68008. This causes the 68008 to fetch an ‘auto-vector’ from a fixed point in its memory map. The CPU then vectors off to that location to commence the interrupt handler.

    IC18 is the UART (68681), which derives its baud rate from a crystal (X2) and so can work at 9600 baud and beyond (unlike the 6850 on the SC09 which could only manage 4800). ICs 20 and 21 are the RS-232 driver and receiver chips. IC19 is an RS-485 chip; RS-485 is a transmission protocol like RS-232 but the transmitting device can be tri-stated so that the line can be shared by many transmitters.

    IC8 (74S04) provides the 16 MHz STEbus SYSCLK, and is divided down by IC9 to give an 8 MHz processor clock. The second half of IC9 is a bus-timeout circuit. The MR (master reset) input is connected to the output enable pins of the STEbus driver chips. When an STEbus cycle is in progress MR will be LO so the second half of IC9 can count. After about 8 µs 2QC will go HI indicating that the STEbus cycle has taken too long, so something must be wrong (a bus-timeout has occurred): 2QC goes into the STEbus control PAL (IC6) which then asserts /BERR to terminate the cycle, rather than waiting interminably for DATACK*.

    IC6 is the STEbus control PAL. When the processor asserts /AS and /DS and A21 is HI the access is deemed to be for STE. IC6 then drives /ENDR (enable driver) LO, which enables the STEbus drivers (ICs 1, 5, 2 and 4). After a delay given by R1*C5 /ENDEL goes LO and IC6 then asserts ADRSTB* followed by DATSTB*. When a DATACK* or TRFERR* is received IC6 releases the signals in the order DATSTB*, ADRSTB* and /ENDR. The SC008 does not have an STEbus arbiter, so cannot accept BUSRQ*s. When it wants to use the bus IC6 asserts /BRQ which can be linked to either BUSRQ0* or BUSRQ1*. LK2 selects which BUSAK* signal the SC008 should monitor, and by making LK2C the SC008 acts in a ‘permanent’ master mode and always assumes it has control of the bus. This mode can only be used when the SC008 is the sole bus master. Notice that CM1 is simply A20,...

    Read more »

View project log

Enjoy this project?

Share

Discussions

Plays with LEDs wrote 08/28/2019 at 19:49 point

Ideally both, I think STEbus allowed 3 different CPUs as bus masters.

A CMOS 65c02 or 65816 (can address 8M of RAM) would be a nice addition to the project, those are still in production and used by a lot of things.

  Are you sure? yes | no

Keith wrote 08/28/2019 at 20:19 point

Ideally, I'd like to do all popular processors but I have very limited time. Even one will take a lot of scarce time, so I need to focus on one job at a time.
My hand-wired 65C02 prototype demonstrates bus I/O cycles, and is on hold until I can make a better platform (i.e. layout a PCB).
I'm currently focused on the 6809E, because I have a PCB for that.

  Are you sure? yes | no

Plays with LEDs wrote 05/16/2019 at 21:40 point

Like seeing the STEbus experimented with again.

  Are you sure? yes | no

Keith wrote 05/22/2019 at 19:21 point

Where you an STEbus user, and if so what did you use it for?

  Are you sure? yes | no

Plays with LEDs wrote 05/23/2019 at 19:53 point

I was not, the research group next door used 2U VMEbus boards, I have three empty VMEbus backplanes, and an embarassingly large number of connectors. I'm interested in STEbus because it can support multiple CPUs.

  Are you sure? yes | no

Keith wrote 05/23/2019 at 21:29 point

Do you mean multiple CPUs in a system, or multiple different types of CPU can drive the bus? Being CPU-neutral, it looks ideal for the hobbyist community. I want to make examples of every CPU to demonstrate this. So far I have the 68008, Z80, and 80188 running. Not sure what to tackle next. Z180, 6809, or 6502? I have the Z8002 and 32016 in my collection as well...

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates