I'd like to present MARC-2.

MARC-2 is a ROM-less SBC largely based on a combination of Daryl Rictor's SBC-3, SBC-4 and some own ideas. I chose a larger CPLD to make MARC-2 as flexible as possible. By attaching headers to all pins of the CPLD, MARC-2 is also easily expandable. A daughter board can be created by female connectors at the bottom and male headers at the top of a PCB. This way the signal lines are as short as possible. Talking about PCB and soldering, I have made this PCB at home but have to say that it’s my limit I'm willing to do at home. There are 720 pads and 168 vias so 888 holes to drill! The vias are hand soldered on the top and the back of the PCB with a very thin wire. Soldering all pads, vias and the expansion headers, I counted 1344 soldering joints. When everything works the way it was intended and all errors are removed, I likely will use a PCB house and considering a four layer board.


I've used the following IC's:

• CPU WDC65C816S
• SRAM AS6C4008 512Kb
• 'ROM' ATMega1284P (AVR)
• VIA0 WDC65C22S
• VIA1 WDC65C22S
• DUART SC26C92
• RTC RV-3049-C2
• CPLD XC95288XL TQ144
• RS232 MAX232

Operation:

The AVR runs at 14.7456MHz and provides that frequency to the CPLD at all times. The AVR senses the reset button and provides the overall reset signal to the CPLD. During RESET, the AVR copies the 16kB ROM image from its flash memory to the SRAM, which takes 79ms. After RESET the AVR is tri-stated. This way there is no (E)EPROM needed. The SRAM can be easily expanded to 1MB by piggy backing an extra SRAM on top of it, the CS signal is already provided on a solder pad nearby.

The CLOCK is divided by 2 so that PHI2 is 7.3728MHz. I'd hoped for this speed although I know it could probably be doubled. The 14.7456MHz also serves as pixel clock for the VGA interface that will be implemented later. The 3.6864MHz for the DUART I also wanted to get from the CPLD, but instead of that, a quartz with two 22pF caps to ground takes care of it.

The CPU and SRAM are connected separately to the CPLD. This alone costs 51 I/O lines and some extra logic programming but gives the advantage of having VGA and DMA later on.

The memory map looks like this:


I.e. there is RAM from $000000-$07FFFF except for the I/O page $00BF00-$00BFFF

Both VIA's are functional and free for use, however, nothing is connected to it right now.
The DUART is connected on channel A to a traditional RS232 port and channel B to a USB to TTL serial bridge. It's running by polling or interrupt based with 115200 baud without problems. I use TeraTerm to communicate with MARC-2.


Here is a simple block diagram:


The CPLD is configured with "Slow Output Slew Rate" and "Low Macrocell Power Setting". These settings reduce power consumption and noise. MARC-2 draws only 92mA from the USB port and there is almost no heat generated from the IC's. The MAX232 and the AVR get warm the most.

I have full control over MARC-2 by means of 3 USB devices:

• AVR DRAGON to update MARC-2's ROM image
• Xilinx USB cable to update the behavior of MARC-2
• USB to TTL serial to communicate with MARC-2 itself and
to provide 5V power

The development chain is extremely short and I use the following programs to update MARC-2's bios:

• TextPad with syntax highlighting (free text editor)
• ACME 65xxx cross assembler (free assembler for creating a 16kB rom.bin)
• bin2db.exe (C program which converts rom.bin to rom.inc)
• avrasm2.exe (ATMEL's assembler which assembles and includes rom.inc to the AVR firmware)
• atprogram.exe (ATMEL's programmer which flashes the AVR)

This whole cycle takes two mouse clicks and a few seconds to complete. It's also very convenient that the SBC will be reset after programming the AVR. Until I have a decent BIOS with file transfer and an external storage device, I'll continue using this method.

To program the CPLD I use ISE 10.1 SP3 which is freely available as a full version and is the last one which supports ABEL (and parallel programmer if preferred).


Pitfalls:

First, soldering a 144 pin 0.5mm pitch CPLD to the adapter board was a challenge I had to dare taking. Those adapter boards are fairly cheap and I first tried it with some cheaper CPLD's before I tried the XC95288XL. Second, the XC95288XL brings the problem with 3.3V vs 5V with it. While supplied with 3.3V, the CPLD accepts 5V to its I/O lines. Third, programming the CPLD I found and still find a real challenge. Because everything is connected to the CPLD, everything has to be taken care of while programming the logic. Although it seems to work correctly, I'm not 100% sure it really is.


To-do:

IRQ register. I've connected the IRQ lines of VIA0, VIA1, DUART, RTC and later internally 65SPI and VGA to the CPLD. It's my intention to create a register to determine which IRQ has occurred.

65SPI: This will take about 21% of the CPLD's resources and provide 8 SPI interfaces of which one is connected to the RTC on the board itself.

VGA: I've connected HSYNC, VSYNC and 8 CPLD pins to a resistor DAC which is connected to RGB of the VGA connector. This should provide 256 colors. The timing to connect the right byte of SRAM to the VGA DAC at the right time is the task to be solved. I estimate it will take at least 20% of the CPLD's resources.

DMA: The CPLD controls the CPU and RAM buses separately. Although having the ability to do something with DMA, I'm not sure what will be useful to do with it. Perhaps someone has some input?

Wait-states: In time I'd like to make one or two daughter boards with two SID's, MIDI, IDE, PS/2 keyboard interface, an AY-3-8912 GI sound chip and an SP0256A-AL2 speech chip. For some of those devices I have to make use of wait-states, which will be provided by the CPLD. At the moment there are 16 I/O lines for use, so plenty to expand.

Software:

Luckily the '816 accepts 6502 code and acts like a one. So I began to test the address lines and I/O devices.

So far I programmed:
Reset routine
Test some toggling address lines
Test some toggling VIA pins
Test a toggling DUART I/O pin
Polled DUART routines
My own attempt of a ML monitor


Furthermore I've adapted:

BDD's interrupt based DUART routines with hardware handshaking
BDD's Supermon816
Daryl's Apple II based ML monitor (a few different versions)
Lee's EhBASIC
WozMon (Apple I monitor)

I've learned a LOT during the last year on this forum and I'd like to thank everyone who has helped me to make this happen. But I'm not there yet, the fun has just started. Now I have the base to start experimenting with all those IC's.

For instance, I compared a basic program to generate the prime numbers up to 997. The C64 took 123 seconds to complete, MARC-2 needed only 7 seconds!

Edit: corrected some minor errors.

_________________
Marco

It's alive!!! Great job.

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

How did you spaghettify nine lines of BASIC so profoundly? That takes a special effort!

Seriously, though, I am very impressed with your hardware ... that's an attractive and powerful little creation, and you should be proud!

Mike

Marvellous!

Great achievement! Looks very good!

Hans

Neat project.

I have developed a new version of the interrupt-driven DUART routines that will work with any 26xxx or 28xxx Philips/NXP multichannel UART that has transmit FIFOs, up to and including the 28L198 octal UART. This "universal" driver is current running on POC V1.1 at 115.2 Kbps on both channels.


The version of Supermon 816 that Marco is running has the Wyse 60 style display driver. However, the terminal emulator he is using is a VT100/ANSI/ECMA-48 type, which explains some of the display artifacts. I do have a VT-100 style driver table put together and will make it available so SM 816 will work correctly with that type of terminal.

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

Thanks for the compliments guys!

LOL I had to take a look to verify what you meant, obviously and luckily I didn't write it myself, and I had to laugh when I saw it!

@BDD
Looking forward to it.

_________________
Marco

I started out with a large # pin socket similar to your CPLD in the pic, but it was a wire-wrap project. It's somewhere here in the forums, where I was driving a 800x480 TFT 7" display with a WDC65C02 based simple SBC...

I also used Xilinx CPLDs when first starting and now currently use Xilinx FPGAs, although I like working strictly at the 3.3V level to avoid problems.

Anyway, you deserve credit for etching your own boards and progressing along using your method of building. Your progress is seems very methodical and you obviously pay great attention to detail.

Great work!

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

Video seems to be the obvious application for DMA -- or did you mean something besides that? FWIW, a free-running timer in the VIA can output a timebase (30 kHz?) for the horizontal scan lines, to invoke the series of DMA sequences I mean. Of course you could build a free-running timer instead, as part of the CPLD, but that consumes resources and maybe toughens your learning curve. Initially at least it may be easier to use the VIA counter, until everything else in the CPLD is ironed out.

Cool. One approach would be to have a register similar to what's in each peripheral chip -- an interrupt flag register that you query with instructions you've included as part of your ISR. But a vectored approach is faster. Instead of being explicitly read by the ISR, your new pseudo-register is read automatically by the CPU as it fetches the interrupt vector from "memory." The '816 conveniently features a pin that signals when that's happening: VPB.

Again, lovely job, Marco! Even just the PCB alone is a thing o' beauty. Hard to believe you baked it yourself!

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Or driving mass storage.


Another source for a free-running timebase in Marco's system is the counter/timer (C/T) in the 26C92. In timer mode, it can be run at speeds up to X1 ÷ 2, where X1 is the 26C92's clock frequency (nominally 3.6864 MHz), resulting in a minimum period between pulses of 0.543 µsec. The C/T can also produce an output on one of the programmable output pins, plus when in timer mode, generate an IRQ on each underflow. A simple read of a specific register clears the interrupt, minimizing the time required to service the device.

I've tested the use of the C/T as an alternate jiffy IRQ source in POC (in one case, using a 250 Hz IRQ rate), and have also used the C/T as a counter to measure the performance of the SCSI subsystem. Way back in the day (c. 1992) when I was doing development on a single-board computer with a 65C02, one of the four C/T's in the SBC's 2698B octal UART was the jiffy IRQ generator. Another one of the C/T's acted as a "high precision" interval timer, set to interrupt at a 1000 Hz rate.

The handy thing about using the C/T as the timekeeper instead of a VIA timer in Marco's system is that the interrupt rate is independent of the Ø2 frequency, since the 26C92 is clocked at a fixed rate.


Basically, what Jeff is describing is a priority interrupt encoder, with the added twist of being able to revector the MPU according to what is interrupting. If properly configured, it would produce the most rapid possible service for any specific interrupt source, plus could be used to temporarily mask lower priority sources during periods of critical processing.


It is a nice looking board. When I first saw it I thought it had been done by a board house.

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

Thanks for the stimulating comments!

Except for the '816 data bus, I could stay at 5V. In retrospect I could have used a 74AC245 to convert the 3.3V to a 5V level. That would definitely be a solution for MARC-2 rev.2.

I intended to do the VGA all with the CPLD, but using the DUART's timer is a good idea to save resources.

My first goal is to have a register working within the CPLD and I having read and write working properly. Then I hope 65SPI to get working, if it were just a separate CPLD, it would be no problem, but now I have to integrate it with the rest of the code in the same CPLD.

That sounds different than I had in mind, I'll surely come back to that subject!

I understand, but I can't imagine a practical implementation of it at this point. Like I said, I'll surely come back to that subject.

I've attached a picture of the top and bottom side of the PCB right after drilling all holes.

_________________
Marco

A special VT-100 version of Supermon816 is also working. Thanks BDD!

_________________
Marco