here is my newest SBC using a real 65 CPU, but as it is a large prototype board I call it a a Single BigBoard Computer.



It implements the following features

W65C816 CPU currently running at 8MHz Clock (as soon the fast GALs arrive I will try how fast it really goes)
PS/2 Keyboard input (and of course CTRL-ALT-DEL produces a reset)
VGA Video Output with 40x24 or 80x24 Text (no attributes however, just plain B/W and Flashing support for 64 characters)
Low-Res Graphics with 40x48 or 80x48 Blocks with 16 colours
512kbyte SRAM
256kbyte EEPROM
Space for two SCC2691 (only one is currently mounted)
Breadboard compatible expansion for IO (the Databus Buffer and the Address Buffer are currently not populated)

The GALs are programmed (together with some gluelogic) to produce a AppleII (II, IIplus, IIe, jumper selectable) compatible hardware, so I can run some tests without having to write a monitor and other software.
The VGA controller produces a standard VESA signal (480x640@60Hz) and uses a Dual-Port RAM and a ATMega162. Although I have not implemented any type of collision avoidance I never had any artifacts on the screen. The PS/2 interface is built using a ATTiny44 together with a 74HCT595 as interface between the ATTiny and the SBBC databus.

But as always a job isn't done until paperwork is finished. So next is to document the whole thing properly. I soldered and unsoldered so many wires and did so many changes, that the original drawings are no longer valid. This happens if you implement new ideas during building your computer

Peter

That's very impressive! It sounds like you have it running too...

How large is that dual-port RAM you're using?
Can you post a list of the IC's you are using, some of them are difficult to see.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Good job. How about some screen shots?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Thanks,

the system as it is now is working smoothly. What is missing is that the PS/2 interface sends some reset to the Keyboard, sometimes it can happen that the keyboard is not working after power-up, so I need to unplug and plug it. Also the next step is to finish the breadboard interface so I can start adding storage (CF-Card most probably).

Here some more information about the ICs you can't read the type. At the bottom right is the ATMega162. Left to it is the SN74HC573 the address latch required for the external memory interface. The 48-pin IC is the DP-RAM, an IDT7134 (4k DP-RAM without arbitration logic). For more detailed information here is the schematic of the VGA-Controller as it is now. The 74LS02 which is turned by 180° is because it was initially a 74LS00 but I had to reverse the logic of the A0L line, else the Firmware would draw the columns in wrong order. And the 74LS02 has the pin-out 180° turned (just needed to swap GND and VCC)



Above the DP-RAM you have the SRAM (512kbyte AS6C4008-55). Below the EEPROM is the CPU X-tal and then the CPU itself (W65C816), again left to the CPU is the Bank Address Latch (47AC573) and the Clock generator (74AC74 used to divide the 16MHz X-Tal Clock to provide both PHI2 and /PHI2 in sync and the AC can sink and source 24mA, almost a perfect clock source for a SBC). Then the last 14-Pin IC you can't read is the ATTiny44.

Here the screen after boot

and some tests with the colours

not a very good picture though. Next is to finish all schematics in Eagle. Unfortunately I have to build first my custom chips (GAL) and the CPU into the Eagle Library. I already did this once. But that was long ago with Version 3.xx and the current version 6.5 is not able to import them, aaaaahhh. And I did not save them as scripts. My bad.

Peter

Thank you for posting, Peter.

It looks very nice and I love your choice of architecture (my first computer was Apple ][). Are you decoding I/O address space ($C000..$CFFF) like the Apple ][?

I look forward to following your progress, Sir.

Cheerful regards, Mike

Hi Mike,

the Memory Map looks as following

Unused means that nothing is selected and the corresponding /SEL signal is not decoded/implemented. Reserved means that there is a /SEL signal that is asserted for this range and it is available on the IO Expansion (Breadboard interface).
The language card is fully operational and 100% compatible to the original Apple II Language Card. In Apple IIe emulation mode A16 of the SRAM is used to switch between Main/Aux RAM when addressing Bank0. So you have an Apple IIe with 128k RAM.
The first 64kbyte of the EEPROM are divided into 4 x 16kbytes sections. Apple II selects section 0, Apple IIplus selects section 1 and AppleIIe uses section 2 and 3. Which is selected depends on the C3ROM and CXROM softswitches. In case you want to have a IOSLOT ROM for the "Slots" you can put the code into the appropriate location in the EEPROM and it is switched in when CXROM is cleared or in case of $C3xx when C3ROM is set. $C800...$CFFF does not implement the C8-ROM Protocol. So you cannot have "Slots" with C8-ROM code. This range always shows what is in the C8-ROM Range of the Apple IIe Firmware. But I think this is not a limitation. You can always switch to true 816 mode in your IOSLOT ROM and execute code you have put into the second to firth 64kbyte of the EEPROM. I also could have implemented C8-ROM Protocol, but I run out of real estate on the board and I definitively wanted to have 2 ACIA on board. So it was either or.

The self-test completes successfully, so the Firmware does not complain that it is not running on a real AppleIIe. For this to work I have decoded the Windows and the Menu Key to assert Pin 0 and Pin 1 on Port A of the ATTiny which connect to the 74HCT251 inputs 1 and 2 (addresses $C061 and $C062). So with CTRL-ALT-DEL and Windows Key you do a cold start and with CTRL-ALT-DEL and Menu Key you do a System Test.

In 816 mode Bank1 to Bank 27 select the RAM and Bank 28 to Bank 31 select the EEPROM. A21, A22, A23 are not decoded. So you can have a maximum of 2Mbyte RAM (minus 256kbyte EEPROM).

The following signals go to the IO expansion

D0..7 (Buffered with a 245)
A0..A6 (Buffered with a 541)
RW (Buffered using the 8th Buffer of the 541)
PHI2
/OE (Read gated with PHI2)
/WE (Write gated with PHI2)
4 /IODEV signals for the ranges $C0Bx, $C0Cx, $C0Dx and $C0Fx
/IRQ
/RES

The CF-Card interface is going to be the top priority, but if possible I want to use the Common Memory Mode to keep it simple.

Peter

That's a powerful, attractive and well-thought-out design. Congratulations!

Mike

That's the arrangement that I used in POC V1. Although I don't use a Ø1 clock as you do, I did compare both clock signals on the 'scope and saw that they were symmetric within a few nanoseconds (the signaling rate reached the limits of my H-P 275 MHz 'scope and probes).

Technical note: as I ramped up the Ø2 clock toward 15 MHz (30 MHz oscillator), this being the highest speed at which the system showed signs of life, the rise and fall times of the 74AC74 flop's Q and /Q outputs became significant relative to the half-cycle time of 33ns. Anecdotal evidence suggests that the 65C816 (and the 'C02) gets fussy if the Ø2 transition time exceeds about 5ns when operating at or above 14 MHz, as that period is a sizable fraction of the device's timing requirements. When you get to where you want to run the 65C816 at full throttle you should consider using a 74ABT74, whose output transition rate is better than that of the 74AC part. I've tested the 'ABT74 in POC V1.1 (using a PDIP part) and noted a sharper clock pulse shape as compared to the 'AC74. POC V2 will use the SOIC version of the 'ABT74.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Peter,

That sounds awesome. It looks like you have Apple ][ 40-column text + Lo-Res graphic buffers handled at $400..$7FF and perhaps $800..$BFF (?) via dual-port RAM to your GPU. Are you planning a similar arrangement for the Hi-Res graphic buffers at $2000..$3FFF and $4000..$5FFF for game programs?

Sorry to ask so many questions...

Mike

Hi BDD,

have you considered to use a clock distribution IC? Like the CY2309 (helas only 3V6). That could cure the issues with PHI2. In my case I will stay with the AC74, I do not intend to go much faster anyhow. Already 8Mhz is faster than I expected and when going faster I fear that I will have to replace the 74HCT251 with 74AC251 (which I don't have at the moment) and the 74HCT595 will be a problem, as there is no AC version made.

Mike,

yep, I have 40-column (and 80-column) Text and Lo-Res. Currently the firmware of the CRTC (the ATMega162) does not honor the PAGE2 input signal. However the DP-RAM is already mapped to $400 to $BFF (2k) and the other 2k are mapped to AUX of the Apple IIe at the same addresses, so as soon as I add support for PAGE2 into the CRTC Firmware PAGE2 can be displayed. Another detail I omitted in the memory layout info, the DP-RAM is in fact write-only and is updated in parallel to the SRAM.
As for Hi-Res, I'm already working on the design, but this will go into another computer (and not necessarily a single-board one). It will feature a IDT7007 32kbyte DP-RAM. In addition to the current design it will support Hi-Res graphics, the colours will be the challenge here, and a new 640x400 bit-mapped mode (Black and White) mapped to a bank outside bank0. but the IDT7007 has arbitration logic, so I will need to add some memory access lock logic.

No. Devices like that are primarily intended for use in circuits where many other devices need to be driven by the same clock source. A typical example would be providing clocks to SDRAMs on a PC motherboard. In my POC V1 unit, the MPU is the only device that requires the Ø2 clock. In POC V2, the CPLD will get both Ø1 and Ø2, which clocks I will derive off the 74ABT74 flop. The skew of Ø1 relative to Ø2 is negligible.

The other clocked device is the 28C94 QUART, which requires a 3.6864 MHz clock signal. That comes from a separate oscillator. The controller on the SCSI host adapter also requires a clock (25 MHz), which is derived from an oscillator mounted on the host adapter daughterboard.


I was a bit surprised by that, as the 74HCT595 is a relatively slow device. You are probably on the ragged edge, timing-wise.


74AC logic is as fast as the '251 comes, and you'd have to synthesize the 'HCT595's function in a 10ns GAL to get commensurate performance. If you're going to do that you might as well encapsulate all glue logic in a CPLD.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Nice! Do you have a view of the bottom of the board. I like seeing the wires (I appreciate the work that goes into it)

Simon

_________________
My 6502 related blog: http://www.asciimation.co.nz/bb/category/6502-computer

Yes if you consider worst-case timing (GAL->74HCT595->65C816 for PHI2=High) then I'm way beyond the required 62.5ns (GAL=25ns, HCT595=44ns, CPU=10ns Total= 79ns), if you consider typical timing at 25°C ambient temperature (HCT595=21ns, Total=56ns) then it's ok. Also GAL propagation delay from Input (PHI2) to Output (OE) is probably much less than 25ns. The datasheet only gives minimal (3ns) and maximum (25ns) values.

Here a picture from the wiring side

Because of design changes during the setup some solder points really look bad as I removed wires and placed new wires to the same point. Especially when the comb is placed close to the pins, placing the wire so it stays in place during soldering requires some patience.

Which GAL are you looking at? GALs faster than 25ns are readily available. I have several Lattice 16V8D pieces with a 7.5ns rating, pin-to-pin.

That said, your timing may benefit from a fresh look at how you are handling decoding and generating chip selects. Are you using Ø2 to qualify chip selects?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Currently the SBBC uses GAL22V10D-25LP from Lattice and GAL20V8QS-10LNC from NS. In my stock I have a bunch of old GALs of various speed (10 to 25ns) but my programmer does not support them. I also got some GAL16V8D-7 last week (probably the same you have) and today the GAL22V10D-7 arrived. My programmer seems to support all -D versions of Lattice and most of the NS which are not from the first generations of GALs.

By the way which programmer do you use?

Some chip selects use Ø2 to qualify, e.g. the enable signal of the 74HCT259 must be qualified with Ø2, but this chip is not time critical at all and the HCT version is fast enough, according to the datasheet it should even work in this scheme at a CPU clock of 25MHz. Also the /OE of the 74HCT251 and 74HCT595 use Ø2 to qualify, else they interfere with the output of the 65C816 when he presents the next bank address (I tried that, it want work for clock rates higher than 4MHz) because output disable time is very high.
Other Chip selects (RAM, Video-RAM, EEPROM, ACIA) do not use Ø2 to qualify. Instead I have a set of global /WE and /OE that qualify with Ø2 that connect to the corresponding /WE, /OE, /RD and /WR pins. Also the select pins on the IO Expansion are not qualified with Ø2. I have chosen this way to avoid conflicts on the bus and because the ACIA and VIA require the enable pins to be ready before the rising edge of Ø2, respectively the falling edge of /WR or /RD. As for the memory, the access time referes to the time from CS to Output and the enable time from OE to data is much lower (in my case the first is 55ns the second is 30ns). So I think this is pretty much the optimum.

I'm considering to add a dual clock-rate circuit for IO which doubles the time of the low and high phase of Ø2 for IO addresses and probably also for the EEPROM.