View unanswered posts | View active topics It is currently Thu Mar 28, 2024 7:36 pm



Reply to topic  [ 266 posts ]  Go to page 1, 2, 3, 4, 5 ... 18  Next
 EPiC - A new 68k multi-processor motherboard project 
Author Message

Joined: Tue Jun 03, 2014 2:40 pm
Posts: 127
Greetings!

First off, let me say how glad I am I found this place! I've been kicking the idea of building a 68K based homebrew computer around for a while now, and for the longest time I couldn't find an adequate forum for projects featuring this processor.

Before I begin, my goals for the system I'm envisioning are as follows:

CPU: Motorola 68060/68LC060 @ 100 MHz (expandable with other additional CPU cards)
RAM: up to 2GB RAM
ROM: 1MB EPROM containing custom bootloader and BIOS firmware
Video: custom VGA controller with 8MB double frame buffer capable of 24 bit color up to 1280 x 1024 (SXGA)
Audio: dual SID or custom audio controller
Storage: IDE Interface
Connectivity: 2 x PS/2, 1 x Infrared, 1 x Serial, 4 x USB, 1 x Ethernet, 1 x Audio In, 1 x Audio Out
Glue: Atmel ATF750C-7PX-ND CPLD

Now, I acknowledge these specs are very ambitious. I have no formal electronics engineering training, so baby steps will be my best friend here. I just figure, if I'm doing something like this, why not aim high? So building one of the most advanced homebrew PCs ever should be within reach... right? :lol:

Lots of people have asked why I want the 68K family and, more specifically, why the 68060. I have several reasons:
- I have always been enamored with the flexibility of the 68k instruction set
- Full backward compatibility with object code from the other members of the 68k line
- No bloody segmented memory model! Just 32 bits of straight addressing power. 8-)
- Built-in multiprocessor capability!
- The '060 was the most powerful and fastest member of the 68k family
- Other than a limited number of Amigas, the chip never got use in a modern mainstream system. It would be awesome to see how it could perform when given a full complement of modern hardware.

Needless to say, I won't be accomplishing this overnight. First, I'll be happy to simply get the CPU to power up and do basic SRAM memory accesses. Next, I'll most likely start on a simple serial interface followed by the video controller. I am mainly a programmer, so it may take me a while to wrap my head around many electronics concepts. I have begun to source parts and will be ordering the CPU, EEPROM, and socket shortly. Unsurprisingly, I am unable to find an adapter which allows the '060 to be used with a breadboard, so I'll probably throw together a breakout board of some sort.

Finally, I'm not just doing this for me - once the basic hardware design is functional, I would like to make this system available in kit form. I think this would be an excellent way for beginners to learn how computers work from the ground up. I started out in computers by coding when I was a kid, was fascinated with CPU design and assembly code as a teenager, became interested in electronics in my 20s and just now in my 30s do I feel mildly confident that I can begin a such a project. Having a kit like this available when I was young would've easily been the most amazing thing on the planet, and I'm sure hundreds of other budding computer scientists would feel the same.

So... that's it! If anyone has any feedback, I'd love to hear it. This will be a long road for me and some company would be nice. All due credit would be given, of course. :) As I said, I'm by no means an expert, and I'm sure I'll make a bunch of stupid little design mistakes here and there so a second (or third, or fourth...) pair of eyes would be great.


Last edited by mercury0x000d on Fri May 27, 2016 4:37 pm, edited 10 times in total.



Tue Jun 03, 2014 9:54 pm
Profile

Joined: Tue Dec 11, 2012 8:03 am
Posts: 285
Location: California
Yep, that's pretty ambitious. I have a 6502 primer which is mostly about hardware, at http://wilsonminesco.com/6502primer/index.html, but there will be things that carry over; for example, there's
page 9 on avoiding AC-performance problems in your construction, at http://wilsonminesco.com/6502primer/construction.html (be sure to follow the links too),
page 12 on answering wire-wrap questions and doubts, at http://wilsonminesco.com/6502primer/WireWrap.html,
page 13 on custom PC boards, at http://wilsonminesco.com/6502primer/CustomPCB.html, and
page 17 on steps for a successful project, at http://wilsonminesco.com/6502primer/steps.html.

75MHz might be do-able in wire-wrap, but not without some transmission-line understanding which will almost certainly lead you a multilayer PC board anyway. The Cray-1 was 80MHz and wire-wrap, but the connections were twisted pairs, with the second wire being ground. The most important thing to keep extra clean at high frequencies will be your clock-distribution method.

It looks like you have some strong graphics capabilities for desktop applications in mind. Do you plan to port Linux to it?

I would recommend planning it so you can get useful results long before the end goal is reached. This helps avoid discouragement, and it promotes success.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources


Tue Jun 03, 2014 10:45 pm
Profile WWW

Joined: Tue Jun 03, 2014 2:40 pm
Posts: 127
Thanks for the tips and links! At first I'm planning to run at only a minimum clock speed which (at least in my mind) will make hardware debugging easier. Even 1KHz would work for me. I figure once that works and everything acts as it should, then I can start increasing speed. If (When?) I have problems, then I'll know the speed increase is the culprit and not my design or components or whatever, which means it's time to move to a professionally designed prototype.

As to the system's graphical abilities, I insist on having it this way. It seems every single homebrew out there has low-res video and I think it'd be great to change that. Not that I'm knocking low-res at all, or the projects that use it, but it just seems to me that if this is going to be a learning example for someone then it should function as close to a modern PC as possible.

I like your closing thought, and I completely agree. I'd much rather put a ton of thought into the project now before things are set in stone than halfway through when I'm stuck and the stupid thing won't boot. Ugh, roadblocks...


Wed Jun 04, 2014 4:53 am
Profile

Joined: Tue Dec 11, 2012 8:03 am
Posts: 285
Location: California
ElEctric_EyE on the 6502.org forum was working toward a 32-bit 65-family processor in programmable logic, and got off on this productive rabbit trail on hi-res video, and has used the topic at http://forum.6502.org/viewtopic.php?f=10&t=2247 as more or less a blog on his progress. It's on page 41 at the moment, so I doubt you'll want to read all of it, but there may be material there that would save you some grief.

The transmission-line behavior comes into play with fast rise times, and slowing the clock down does not by itself remedy that. Leaving longer between edges does give time for ringing to die out which helps on things like address and data lines; but the clock lines still have to be done right if the rise times (or slew rates, or edge rates) are fast, or things won't work. If you heed the things on the page I pointed to, and the links there, you'll be fine. One of them is the 6502.org forum topic, "Techniques for reliable high-speed digital circuits," at http://forum.6502.org/viewtopic.php?f=4 ... 664#p17664.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources


Wed Jun 04, 2014 8:22 am
Profile WWW
User avatar

Joined: Tue Jan 15, 2013 5:43 am
Posts: 189
welcome, Mercury!
Quote:
First, I'll be happy to simply get the CPU to power up and do basic SRAM memory accesses. [...] I'll probably throw together a breakout board of some sort.
Good idea. Garth's advice about useful results early in the game bears repetition. For stage one, you'll be doing well just to bring up the CPU and some SRAM, together with some sort of assembler and a link to the host. So a pre-project project makes a lot of sense, IMO. Even so, I hope you have some prior construction experience. (You mention none.)

Be aware that, even for an experienced person, the DRAM interface is a major challenge unless you intend to make use of a controller IC that'll administer the timing. Do yourself a favor, and plan to interface to the controller IC -- not the DRAMs themselves. Defining a workable bus for I/O cards is also non-trivial.

BTW, where does a person your age catch wind of 74S and 74AS technology? IMO, 74S is quaint, whereas 74AS is merely obsolete -- and hideously expensive. (Or is there an economical EBay channel for the stuff?) Both suck power and have limited noise immunity. Even the now dated 74AC series cmos is a far better choice.

cheers,
Jeff

_________________
http://LaughtonElectronics.com


Wed Jun 04, 2014 8:40 am
Profile WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1780
I will follow this with interest!
Cheers
Ed


Wed Jun 04, 2014 10:43 am
Profile

Joined: Tue Jun 03, 2014 2:40 pm
Posts: 127
Garth:
I neglected to answer your previous question: I wasn't planning to do a Linux port, but I wouldn't be offended if it ended up runnable on this machine lol I'm planning to roll my own OS tailor made for the hardware in use. I'll definitely check out the links you gave and see what I can learn.

Dr Jefyll:
Thanks for the welcome! :)
I like the pre-project project idea... my thoughts exactly! I've never been a fan of making great strides in progress then finding out one of the five dozen changes you made is at fault. I agree it's far better to make baby steps and verify that everything is working before proceeding.
So far as my construction experience, I've only ever tackled small electronics projects on breadboards, like series counters and digital logic and such. The same principles I'll be using here but on a smaller scale... so yes, I've done some construction before but I don't know how well my current experience will benefit me in this endeavor.
What would you recommend for a good DRAM interface IC? I'd love to not have to do the timing myself, but I will if I have to... I guess. *sigh*
Like I said, I've been kicking this idea around for literally years. Although I forget where now, at some point in my research I saw the 74S and 74AS series chips for sale somewhere on the internet months ago. I don't know if I ever considered the 74AC family, but from my calculations it should be able to handle speeds up to 250MHz or so... plenty for my needs. Thanks for the suggestion! That's why I'm glad I found this place. :)

Big Ed:
Thanks! It's good to have one more along for the ride. :)



By the way... does anyone know of any fairly cheap PCB fab houses out there?


Wed Jun 04, 2014 2:57 pm
Profile
User avatar

Joined: Tue Jan 15, 2013 5:43 am
Posts: 189
hello again, mercury.

To me, 74S logic is reminiscent of equipment I worked on in the 1980's, such as the Prime 100 16-bit mini-computer used in my client's photo-typesetters. That machine provided a marvelous learning experience! In particular I remember a big light bulb going on when I read in the manual that the Prime's micro-coded core was a "computer within a computer." And, unlike the 68EC060, this CPU was NOT integrated -- I had access to its actual schematic, which showed a hundred or so MSI packages -- mostly 74S and standard TTL, as I say.

Oops, off-topic! -- but I'll endeavor to get back on track. Here is the "personal computer" I was using at the time. (For test purposes I had Forth code on the KIM-1 that talked to the Prime 100 via the machines' parallel ports. OOPS! :oops: ) Anyway, the 128K DRAM board I acquired for the KIM used a simple state machine built with 74S logic. The state machine is what controlled /RAS, /CAS and so on for the DRAM. It was basically a pair of 74S288 32 x 8 PROM's whose outputs tied back to their inputs via a pair of 74S374's, the latter clocked at some high frequency I no longer recall. Each iteration (8 states?) of the state-machine loop constituted one DRAM access.

In another of my projects I copied this approach but ended up wishing I'd used a DRAM controller instead -- the headaches trying to reconcile the DRAM's long list of timing constraints weren't worth it, for me at least. YMMV. And PC133 is a far cry from what I was using. Maybe things have gotten easier -- can anyone advise us on that, please?

Sorry I can't recommend a DRAM controller IC, but when I'm looking for anything I usually visit the Digikey web site and use their Product Index to do a search.

BTW, do you have an oscilloscope? If not, I suggest you start shopping.

cheers,
Jeff

_________________
http://LaughtonElectronics.com


Wed Jun 04, 2014 5:02 pm
Profile WWW

Joined: Tue Dec 11, 2012 8:03 am
Posts: 285
Location: California
mercury0x000d wrote:
I don't know if I ever considered the 74AC family, but from my calculations it should be able to handle speeds up to 250MHz or so... plenty for my needs.

250MHz is a 4ns period. When you add up the set-up times, glue-logic times, access times, etc., you'll be way over that. It's only a small exaggeration to say the 6502 does a read or write in half a cycle, which at 200MHz (the fastest speed I know of for it), is 2.5ns. I seem to remember the 68000 took four clock cycles to do a read or write, but I don't know how the 68EC060 compares. Regardless, having eight 060's should deliver some impressive performance if you know how to keep them all relevantly busy which is something I have no knowledge of how to do. I'll be very interested in how that all develops, and I wish you great success.

Does the 68EC060 have DRAM management built in?

Quote:
By the way... does anyone know of any fairly cheap PCB fab houses out there?

PCB Express and Express PCB are a couple I mention, with some explanation, on my custom-PCB page at http://wilsonminesco.com/6502primer/CustomPCB.html. There's a topic on 6502.org where others have pitched in with their experiences with other low-cost board houses, but I can't think of adequate search terms to find it at the moment. I bet Ed can.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources


Wed Jun 04, 2014 5:42 pm
Profile WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1780
Oh, yes, welcome, mercury!

For PCB experiences, it might be worth consulting the posts at http://forum.6502.org/viewtopic.php?t=1913 - your preference might differ depending on where you are in the world. Once you want a handful of boards made up, the Chinese suppliers might well be best, but for 1-3 boards I would suspect somewhere local is best. Unless you're in China, in which case it's the same thing...

Cheers
Ed


Wed Jun 04, 2014 6:09 pm
Profile

Joined: Tue Jun 03, 2014 2:40 pm
Posts: 127
Dr Jefyll:
I don't mind a little nostalgic off-topicness lol
Yeah, I was thinking it shouldn't be too hard to design a logic-based DRAM timing circuit, but perhaps I'm mistaken... I've been looking into some ICs which do this but haven't found much so far.
I don't have an oscilloscope just yet, but I have been eying the Saleae.

Garth:
I was factoring 4 ns from this Wikipedia article which places 74AC parts between 74S (3 ns) and 74F (3.4 ns) parts. I figured 4 ns would be adequate. After studying your timing diagrams, I see I was mistaken because I didn't factor in both the high and the low cycling for the gates. The actual speed should therefore be around 125-ish MHz, which is still plenty for my needs. The CPU is only rated at 75 MHz, but I'm sure with the modern cooling options we have available today I can squeeze a bit more out of them... maybe 80 or 85? 100 would be awesome, but I'm not holding my breath. Especially when the chip's predecessor never set any heat dissipation records... that's why the Mac laptops stayed stuck on the '030 for a long time, even after the '040 came out.
I must say again, thanks for your resources! I'm glad I can recalculate my propagation delays now rather than after I order them in bulk! lol
The "EC" in the 68EC060 stands for "Embedded Controller." From my research, this means it's a 100% fully functioning 68060, except for having the FPU and MMU removed. The downside is no native floating point math (not a big deal) and no virtual memory. I'm not sure, but I don't think the MMU would support DRAM timings even if it was still included. At east I've seen nothing about it in the '060's user manual.

BigEd:
Thanks for the welcome and the link! I'm in the US, and I'd like to have the first couple boards made here too, just in case I screw something up. At least that way there's no exorbitant shipping costs, long delays or miscommunication. Nothing against the offshore houses (I'm sure I'll go to them eventually) but since I'm a total noob when it comes to this fab business, I figure I'd keep it simple to start.



In other news, I've been going over the details of the video subsystem and I fail to see where it's necessary to support a multitude of screen modes these days. Initially, I was intending to make most of the standard VESA modes available:

Code:
mode
number     resolution     color count   bit depth   RAM required
100h       640x400        256           8           250 K
101h       640x480        256           8           300 K
103h       800x600        256           8           480000 b (468.75 K)
105h       1024x768       256           8           768 K
107h       1280x1024      256           8           1280 K (1.25 M)
10Dh       320x200        32767         15          125 K
10Eh       320x200        65535         16          125 K
10Fh       320x200        16777215      24          192000 b (187.5 K)
110h       640x480        32767         15          600 K
111h       640x480        65535         16          600 K
112h       640x480        16777215      24          900 K
113h       800x600        32767         15          960000 b (937.5 K)
114h       800x600        65535         16          960000 b (937.5 K)
115h       800x600        16777215      24          1440000 b (1.37 M)
116h       1024x768       32767         15          1572864 b (1.5 M)
117h       1024x768       65535         16          1572864 b (1.5 M)
118h       1024x768       16777215      24          2359296 b (2.25 M)
119h       1280x1024      32767         15          2621440 b (2.5 M)
11Ah       1280x1024      65535         16          2621440 b (2.5 M)
11Bh       1280x1024      16777215      24          3932160 b (3.75 M)


But is all that really needed? I mean, I can see where back in the day you may not always have a decent monitor around which could display the higher resolution or color depth modes, but today I think 1280x1024 isn't that taxing, right? Heck, I've seen LCDs at flea markets for $50 that could handle that. So, what if I support only the one best resolution on the list? Do you guys think it would really be that bad?

And speaking of video, I've been thinking about the whole video RAM access timing issue as well. I read somewhere that the original Macintosh had a "strobed" clock (for lack of a better term) which didn't pulse all the clock inputs on every chip simultaneously. Instead, it would send a pulse to the CPU, then one to the video circuitry, then the audio, etc. The downside is that your base clock has to run much higher than the desired CPU speed. Therefore, if you want a 100 MHz computer and you have 4 devices (the CPU, video controller, audio controller and a UART or something for I/O) sharing the bus, you'd have to have a 400 MHz (!) base clock. I'm not sure if that's the best option, or if I should just tie everything into the CPUs existing bus arbitration pins. I was planning on the video controller having two dedicated 4MB banks of RAM and letting the hardware draw from one while you write to the other, then when you're done drawing (maybe signaled via an interrupt?) the banks swap and the process starts over. I'm not quite sure how I'd make that system tie into the bus access scenario.

Another area I've been giving a lot of thought to is I/O access. I would like to come up with a system where - assuming there is actually 4GB of RAM installed - the CPU can access all of the memory and still talk to the I/O without "holes" in the memory map. I'm assuming I'll probably have to use a CPLD or FPGA for this, but I was thinking of the following scenario. The CPU could be linked to RAM at all times, and the address decoder could simply look for an access to the top of RAM, e.g. 0xFFFFFFFF. When it sees this address, it swaps to a different memory map for I/O, which stays in play until another access to 0xFFFFFFFF, at which point the maps swap again. Is that useful or just stupid? Maybe I'm over-thinking the whole thing.


Thu Jun 05, 2014 4:38 am
Profile

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1780
I had a look at the short product description (not quite a datasheet) at
http://cache.freescale.com/files/32bit/ ... M68060.pdf

I note the device has 8k+8k cache. So for bring-up purposes you could have a very slow (multi-cycle) memory subsystem and still get reasonable performance. The device offers a general purpose bus - it's not a DRAM or SDRAM specific bus. So you have to built a memory subsystem which accepts and eventually acknowleges requests on that bus, and generates whatever memory access signals or strobes your memory chips need. If you have a mix of RAM and ROM, which you probably will (although you could possibly start with ROM only, using the caches) you might have two different kinds of memory access signal.

If you're talking about 4G of RAM, you'll have some extra considerations, probably. I think that's some way down the road. I'd recommend starting with static RAM, and just a single chip deep.

I wouldn't worry about trying to emulate a separate I/O space and memory space until much further down the line: 2G+2G would be remarkable enough for a home built system, and the 68k is not built for that approach - it's built for memory-mapped i/o, like the 6800 and 6502.

These might be useful:
http://research.cs.tamu.edu/prism/lectu ... sd_l15.pdf
http://meseec.ce.rit.edu/eecc250-winter ... 2-8-99.pdf

Edit: see also the much more detailed user manual: http://cache.freescale.com/files/32bit/ ... 8060UM.pdf
I don't yet see how CLKEN might be able only to deliver half speed or quarter speed bus system - I can see how it could knock out arbitrary edges and allow for half, quarter, third, eighth speed and so on. Perhaps it was only anticipated that it would be used for half speed and quarter speed.


Cheers
Ed


Thu Jun 05, 2014 10:58 am
Profile

Joined: Tue Jun 03, 2014 2:40 pm
Posts: 127
BigEd wrote:
I had a look at the short product description (not quite a datasheet) at
http://cache.freescale.com/files/32bit/ ... M68060.pdf

I note the device has 8k+8k cache. So for bring-up purposes you could have a very slow (multi-cycle) memory subsystem and still get reasonable performance. The device offers a general purpose bus - it's not a DRAM or SDRAM specific bus. So you have to built a memory subsystem which accepts and eventually acknowleges requests on that bus, and generates whatever memory access signals or strobes your memory chips need. If you have a mix of RAM and ROM, which you probably will (although you could possibly start with ROM only, using the caches) you might have two different kinds of memory access signal.


Good catch, I hadn't given much thought to the caches. That should help mitigate some of the bus contention of having the processors and multiple devices going at it all at once.



BigEd wrote:
If you're talking about 4G of RAM, you'll have some extra considerations, probably. I think that's some way down the road. I'd recommend starting with static RAM, and just a single chip deep.


I definitely agree. I'll be happy to just get the single SRAM chip working, let alone a fancy address decoder too.



BigEd wrote:
I wouldn't worry about trying to emulate a separate I/O space and memory space until much further down the line: 2G+2G would be remarkable enough for a home built system, and the 68k is not built for that approach - it's built for memory-mapped i/o, like the 6800 and 6502.


By "memory-mapped I/O" you mean having the RAM, ROM and all device I/O in the same contiguous address space with no swapping like I mentioned before, correct?


Thu Jun 05, 2014 6:05 pm
Profile

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1780
Yes indeed, no messing with the memory map - as with 32bits of address space it's plenty large enough! Your idea, or something like it, is probably workable, but at the cost of complexity, and only worthwhile if you really can fill the rest of memory.

It looks like the 68000 boots from low memory, so conventionally you'd put EPROM in the bottom space, with some vectors and some boot code and maybe a machine monitor. Again, you could take pains to switch that out of the memory map after boot, but I'd say that was an optional optimisation.

BTW, I feel compelled to re-use a favourite quote:
Quote:
Thomson's Rule for First-Time Telescope Makers: "It is faster to make a four-inch mirror then a six-inch mirror than to make a six-inch mirror"
(not that I even own a telescope)

On those lines, have you ever built a micro system before? If not, it might be worth a quick build of something simple, like one of Grant Searle's at http://searle.hostei.com/grant/#My6502

Cheers
Ed


Thu Jun 05, 2014 6:31 pm
Profile

Joined: Tue Jun 03, 2014 2:40 pm
Posts: 127
BigEd wrote:
Yes indeed, no messing with the memory map - as with 32bits of address space it's plenty large enough! Your idea, or something like it, is probably workable, but at the cost of complexity, and only worthwhile if you really can fill the rest of memory.

It looks like the 68000 boots from low memory, so conventionally you'd put EPROM in the bottom space, with some vectors and some boot code and maybe a machine monitor. Again, you could take pains to switch that out of the memory map after boot, but I'd say that was an optional optimisation.

BTW, I feel compelled to re-use a favourite quote:
Quote:
Thomson's Rule for First-Time Telescope Makers: "It is faster to make a four-inch mirror then a six-inch mirror than to make a six-inch mirror"
(not that I even own a telescope)

On those lines, have you ever built a micro system before? If not, it might be worth a quick build of something simple, like one of Grant Searle's at http://searle.hostei.com/grant/#My6502

Cheers
Ed


Okay, I'm liking the no swapping option. The more I think about it, the more I see possibilities for it to go wrong... and that's not even figuring in the added electrical complexity and higher price for the added hardware! I think what I'll end up doing is putting EEPROM low since - as you pointed out - the chip does boot low, then any address under, say, several megs or so would be reserved for I/O and hardware (video, audio, etc.) then RAM all the way up as far as the user wants.

I like that quote! You know, I was thinking of doing something like that, just to familiarize myself. Maybe throwing together a small 68000 unit just to learn some things. That way I'd have much more reference material and folks to talk to who have gone down that road before. Once I learn that, then on to the bigger project! No, I have not built anything like this to date. Maybe building a starter 68000 unit isn't a bad idea after all...


Thu Jun 05, 2014 7:32 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 266 posts ]  Go to page 1, 2, 3, 4, 5 ... 18  Next

Who is online

Users browsing this forum: SemrushBot and 8 guests


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:  
cron
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software