6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 10, 2024 9:40 pm

All times are UTC




Post new topic Reply to topic  [ 13 posts ] 
Author Message
 Post subject: MARC-2 ready
PostPosted: Thu Jun 05, 2014 9:47 pm 
Offline

Joined: Wed Sep 11, 2013 8:43 pm
Posts: 207
Location: The Netherlands
I'd like to present MARC-2.
Attachment:
CRW_0048.jpg
CRW_0048.jpg [ 520.63 KiB | Viewed 8978 times ]

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.
Attachment:
CRW_0035.jpg
CRW_0035.jpg [ 1.12 MiB | Viewed 8978 times ]


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:

Code:
RAM:       $000000-$00BEFF
DUART:     $00BF00-$00BF0F
VIA0:      $00BF10-$00BF1F
VIA1:      $00BF20-$00BF2F
IRQREG:    $00BFFF-$00BFFF (testing this at the moment)
RAM:       $00C000-$07FFFF

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:
Attachment:
BLOCK01.png
BLOCK01.png [ 24.07 KiB | Viewed 8978 times ]


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)
Attachment:
Supermon816.png
Supermon816.png [ 27.65 KiB | Viewed 8978 times ]

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!
Attachment:
EhBASIC.png
EhBASIC.png [ 42.04 KiB | Viewed 8978 times ]

Edit: corrected some minor errors.

_________________
Marco


Last edited by lordbubsy on Sat Jun 07, 2014 7:43 am, edited 1 time in total.

Top
 Profile  
Reply with quote  
 Post subject: Re: MARC-2 ready
PostPosted: Fri Jun 06, 2014 1:13 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8481
Location: Midwestern USA
lordbubsy wrote:
I'd like to present MARC-2.

It's alive!!! :lol: Great job.

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


Top
 Profile  
Reply with quote  
 Post subject: Re: MARC-2 ready
PostPosted: Fri Jun 06, 2014 5:04 am 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1949
Location: Sacramento, CA, USA
How did you spaghettify nine lines of BASIC so profoundly? That takes a special effort! :wink:

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

Mike


Top
 Profile  
Reply with quote  
 Post subject: Re: MARC-2 ready
PostPosted: Fri Jun 06, 2014 5:48 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10977
Location: England
Marvellous!


Top
 Profile  
Reply with quote  
 Post subject: Re: MARC-2 ready
PostPosted: Fri Jun 06, 2014 6:07 am 
Offline
User avatar

Joined: Fri Oct 31, 2003 10:00 pm
Posts: 200
Great achievement! Looks very good!

Hans


Top
 Profile  
Reply with quote  
 Post subject: Re: MARC-2 ready
PostPosted: Fri Jun 06, 2014 1:47 pm 
Offline

Joined: Wed Jan 08, 2014 3:31 pm
Posts: 578
Neat project.


Top
 Profile  
Reply with quote  
 Post subject: Re: MARC-2 ready
PostPosted: Fri Jun 06, 2014 4:17 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8481
Location: Midwestern USA
lordbubsy wrote:
BDD's interrupt based DUART routines with hardware handshaking

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.

Quote:
BDD's Supermon816

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.


Attachments:
File comment: Philips/NXP 28L198 octal UART data sheet.
uart_octal_28L198.pdf [375.93 KiB]
Downloaded 254 times

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
 Post subject: Re: MARC-2 ready
PostPosted: Fri Jun 06, 2014 4:25 pm 
Offline

Joined: Wed Sep 11, 2013 8:43 pm
Posts: 207
Location: The Netherlands
Thanks for the compliments guys!

Quote:
How did you spaghettify nine lines of BASIC so profoundly? That takes a special effort! :wink:
LOL :D 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


Top
 Profile  
Reply with quote  
 Post subject: Re: MARC-2 ready
PostPosted: Sat Jun 07, 2014 12:00 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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


Top
 Profile  
Reply with quote  
 Post subject: Re: MARC-2 ready
PostPosted: Sat Jun 07, 2014 2:18 am 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
lordbubsy wrote:
DMA: The CPLD controls the CPU and RAM busses 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?
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.

lordbubsy wrote:
It's my intention to create a register to determine which IRQ has occurred.
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


Top
 Profile  
Reply with quote  
 Post subject: Re: MARC-2 ready
PostPosted: Sat Jun 07, 2014 4:01 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8481
Location: Midwestern USA
Dr Jefyll wrote:
Video seems to be the obvious application for DMA -- or did you mean something besides that?

Or driving mass storage. :)

Quote:
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.

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.

Quote:
lordbubsy wrote:
It's my intention to create a register to determine which IRQ has occurred.

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.

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.

Quote:
Even just the PCB alone is a thing o' beauty. Hard to believe you baked it yourself!

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!


Top
 Profile  
Reply with quote  
 Post subject: Re: MARC-2 ready
PostPosted: Sat Jun 07, 2014 11:48 am 
Offline

Joined: Wed Sep 11, 2013 8:43 pm
Posts: 207
Location: The Netherlands
Thanks for the stimulating comments!

ElEctric_EyE wrote:
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.
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.

Dr Jefyll wrote:
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."
That sounds different than I had in mind, I'll surely come back to that subject!

BigDumbDinosaur wrote:
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.
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.
Attachment:
1.jpg
1.jpg [ 957.07 KiB | Viewed 8871 times ]

Attachment:
2.jpg
2.jpg [ 1 MiB | Viewed 8871 times ]

_________________
Marco


Top
 Profile  
Reply with quote  
 Post subject: Re: MARC-2 ready
PostPosted: Mon Jun 09, 2014 7:37 am 
Offline

Joined: Wed Sep 11, 2013 8:43 pm
Posts: 207
Location: The Netherlands
A special VT-100 version of Supermon816 is also working. Thanks BDD!
Attachment:
supermon816a.png
supermon816a.png [ 37.32 KiB | Viewed 8844 times ]

_________________
Marco


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 13 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: