Last visit was: Sun Sep 19, 2021 10:23 am
It is currently Sun Sep 19, 2021 10:23 am



 [ 37 posts ]  Go to page 1, 2, 3  Next
 Billy I: The 68K computer 
Author Message
User avatar

Joined: Thu Oct 08, 2015 11:57 pm
Posts: 65
Last year I started making a 68K computer I named Billy I. I wanted it to be fast (none of those 4 MHZ builds I always see), flexible; So much so that I made my own interface port (like PCI or ISA), and I wanted it to be 100% from scratch. Okay, so I cheated a little on the third part, but then again I don't know how to make my own hard drive, and I modified a laptop charger to serve as my power supply. But everything else is all designed by me. The "North Bridge" is going to be made up of several 22V10 PLDs, and will be in control of the RAM timings, the IDE hard drive, and the address decoding/memory mapping. The "South Bridge" is going to be the ATMEGA328 and will support 2 PS/2 ports for a mouse and keyboard, and will have integrated graphics supporting text only, B/W TV output, in either PAL or NTSC, which can be selected with a jumper. The NB will run at 24 MHZ, the SB at 16 MHZ (I don't know if I can go higher without screwing up the video timings), and the CPU at 12 MHZ. There will be 2 30pin SIMM RAM slots, since I kind of need two for fast 16bit capabilities. The RAM timings will be changeable through the BIOS, so you can squeeze every last bit of performance out of this thing. I was going to have this thing support overclocking, but I decided to wait until the next model. Below is a picture of my progress. The metal box with the big fan on it is my power supply. It consists of a laptop charger soldered to a board full of regulators, 2/3 of them being linear, and the last one a buck converter. There are three power rails: 12V, 5V, and 5V stand by. The 5V rail can supply up to 3A, the 5V SB can supply 1.5A, and I have no clue on how much power the 12V rail can supply, I hope my buck converter will be able to supply enough to get by. The silver heatsink on the left of the motherboard is for the two mosfets that are in two more buck converters, one for each expansion slot on the right of the board. The small fan next to the mosfets is for the 5V regulator under it, the regulator supplies power to the rest of the board. On top are the main power connections and the IDE connector, and in the middle(?) is the 68K. The chip on the top right is the ATMEGA328. So far everything has been smooth sailing, I haven't run into any problems yet. Let me know what you guys think!


You do not have the required permissions to view the files attached to this post.


Sun Oct 11, 2015 11:43 pm
User avatar

Joined: Thu Oct 08, 2015 11:57 pm
Posts: 65
Okay, scratch the 22V10. I'm going to go for the ATF2500C instead, due to it being larger and actually in stock at Digi-Key.


Mon Oct 12, 2015 12:05 am
User avatar

Joined: Thu Oct 08, 2015 11:57 pm
Posts: 65
Hello everybody! About time for another update, isn't it? I have MOST of the parts needed to finish this thing, I'm just missing the RAM slots and a programmer cable for the CPLD (which has changed again into the Altera MAX7000 EPM7032). But I do have enough to start writing the BIOS and some simple test programs. I'll be using my Raspberry PI to program the EEPROM, which is just one IO short of being able to use all 512K of memory. In my design I'm going to be ignoring the LDS and UDS pins, and giving the CPU a full data bus the entire time. That shouldn't cause problems (right? someone correct me if I'm wrong). I have also realized that my power supply is stronger than I thought. It was able to power a CD drive, a Hard Drive, and the motherboard all at the same time. The only downside is that it gets REALLY hot, and the HDD can't start if there is a CD in the CD drive when the system turns on. I'll just have to keep that in mind...


Tue Oct 27, 2015 3:55 am
User avatar

Joined: Tue Jan 15, 2013 5:43 am
Posts: 184
I don't recognize the package -- is that an actual 68000 or some other 68K family member? And 30 pin SIMMs are just 8 bits wide, isn't that right? That's OK; I just wonder why you didn't choose a wider device (so you could use fewer). It would use less space and reduce the number of connections that need to be made.

Speaking of connections, what sort of wiring will you use -- wire-wrap?

Remember your DRAMs will need address multiplexing, some timing-critical strobe signals and a means of refresh. And if DRAM is the only RAM you've got then the computer will never wake up if the DRAM system hit a snag -- and there are plenty of snags to be hit!

And how would you diagnose a flaky DRAM system? With a DRAM test that runs entirely out of EEPROM? (I suppose it's possible, but... )

Here's a suggestion. Include at least a few K of SRAM for use in initial development! SRAM is much easier to get working, and would serve as a stepping stone. Later after you get the DRAM working reliably and tested you can easily convert those SRAM sites to contain extra EEPROM capacity.

FloppidyDingo wrote:
I haven't run into any problems yet. Let me know what you guys think!
Um... not all problems arise when you're listing the stuff you're gonna do. A remarkably high percentage :roll: appear during the actual doing.

_________________
http://LaughtonElectronics.com


Tue Oct 27, 2015 9:40 pm WWW
User avatar

Joined: Thu Oct 08, 2015 11:57 pm
Posts: 65
Dr Jefyll wrote:
I don't recognize the package -- is that an actual 68000 or some other 68K family member? And 30 pin SIMMs are just 8 bits wide, isn't that right? That's OK; I just wonder why you didn't choose a wider device (so you could use fewer). It would use less space and reduce the number of connections that need to be made.

Speaking of connections, what sort of wiring will you use -- wire-wrap?

Remember your DRAMs will need address multiplexing, some timing-critical strobe signals and a means of refresh. And if DRAM is the only RAM you've got then the computer will never wake up if the DRAM system hit a snag -- and there are plenty of snags to be hit!

And how would you diagnose a flaky DRAM system? With a DRAM test that runs entirely out of EEPROM? (I suppose it's possible, but... )

Here's a suggestion. Include at least a few K of SRAM for use in initial development! SRAM is much easier to get working, and would serve as a stepping stone. Later after you get the DRAM working reliably and tested you can easily convert those SRAM sites to contain extra EEPROM capacity.

FloppidyDingo wrote:
I haven't run into any problems yet. Let me know what you guys think!
Um... not all problems arise when you're listing the stuff you're gonna do. A remarkably high percentage :roll: appear during the actual doing.


The chip is an original 68HC000 made by Hitachi, in the rare(?) PGA package. It was more expensive, but in my eyes it looks much nicer than the DIP version. Just a personal preference. I chose 30 Pin RAM because as far as I know, it's the only format I could fit in a breadboard without drilling more holes. And 72 pin RAM is 32 bit, much more than I need. If there is some other magical format that I don't know about, then please tell me.

I'm going to solder all of the wires together using a mix of solderless breadboard wire and enameled wire. I find wire wrap a bit too messy for me (at least, when I do it :lol: ).

I know the challenges of using DRAM, and that's what makes it fun! It's challenging! All of the timing and address control are going to be handled in the CPLD and 4 latches to split the address. The DRAM is going to be refreshed using CAS before RAS. I'm also going to make the user able to change the RAM timings in the BIOS settings, so that way I can tweak things without having to take apart the system. And when you mean snag, do you mean imperfections in the system itself, or the RAM? Because if you're talking about the system, then that's okay because then I'll just work towards fixing that imperfection. Adds to the fun. If it's the RAM at fault, then I guess I'm a little screwed :| But I've been studying RAM functions very well, and am using this computer as an example: https://www.ist-schlau.de/hardware.html#DRAM

Pretty much all diagnostic utilities are going to be stored in the EEPROM, since I have so much space (128 KB!) to play with. For the RAM test, it's just going to place a sequence of bytes in the start of the RAM, and then continue checking that sequence until a fault happens, or until someone turns the system off.

I'd LOVE to use SRAM as a starter, but then 1) I have no more board room to place them, 2) The CPLD doesn't have enough IO to add more devices to the memory map. I could use one of the expansion ports to hold some SRAM to start with, but that'd only limit me to 256 bytes of RAM to work with, since Slot B (the name I gave my port) only has an 8 bit address bus.

Dr Jefyll wrote:
FloppidyDingo wrote:I haven't run into any problems yet. Let me know what you guys think!
Um... not all problems arise when you're listing the stuff you're gonna do. A remarkably high percentage appear during the actual doing.


I said this because when I build something, I am a bit paranoid when it comes to something not working. So I build my projects in segments, and then test each one before moving on to the next. That way, I find any problems in that particular part and can fix it before It affects anything else. If I were to make the entire thing in one sitting and not make my mini-tests, then any problems that arise will be harder to troubleshoot. But I do have one possible problem that could show: ignoring the LDS and UDS lines. I'm pretty sure the chip will be fine if I supply it the full 16 bits no matter what it requests (right?). If not, then I can just get a couple AND gate ICs and use those. No big deal. But I'd rather not.


Tue Oct 27, 2015 10:55 pm

Joined: Tue Dec 11, 2012 8:03 am
Posts: 285
Location: California
I offer a 32Mb (4Mx8) 5V 10ns SRAM module. The data sheet is at http://wilsonminesco.com/WM-1_4Mx8SRAMm ... -15-13.pdf . This is the largest, fastest 5V SRAM module available that I know of, and its pin header makes it easy for hobbyists to build with. The pin header can be straight or right-angle. When fully populated, it has 64 times as much RAM as the Commodore 64 did, and 32 times as much as the original Mac did. Being SRAM, it can be battery-backed, and is free of the complications of DRAM management requirements. There's more discussion of it, and pictures, on the 6502.org forum, here. Daryl Rictor's SBC-4 computer which he sells uses it. I can provide the sockets too, both in soldertail and in wire-wrap. Prices fluctuate depending on the current price of the ICs, but is now $69 for a fully populated module and probably won't get much below that since I can now get 100 chips at a time for $2.50 each (including shipping, and I don't have to pay sales tax since I have a resale number) and the assembly & test labor is dominating the overall price. If you're in California, I have to charge sales tax, but not otherwise. Shipping to you will be about $6 by Priority Mail, regardless of quantity.

I have a page answering wire-wrap questions and doubts, at http://wilsonminesco.com/6502primer/WireWrap.html , as part of the 6502 primer. Other chapters may help you too. There are several chapters that are not specific to the 6502.

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


Tue Oct 27, 2015 11:56 pm WWW
User avatar

Joined: Thu Oct 08, 2015 11:57 pm
Posts: 65
Garth wrote:
I offer a 32Mb (4Mx8) 5V 10ns SRAM module. The data sheet is at http://wilsonminesco.com/WM-1_4Mx8SRAMm ... -15-13.pdf . This is the largest, fastest 5V SRAM module available that I know of, and its pin header makes it easy for hobbyists to build with. The pin header can be straight or right-angle. When fully populated, it has 64 times as much RAM as the Commodore 64 did, and 32 times as much as the original Mac did. Being SRAM, it can be battery-backed, and is free of the complications of DRAM management requirements. There's more discussion of it, and pictures, on the 6502.org forum, here. Daryl Rictor's SBC-4 computer which he sells uses it. I can provide the sockets too, both in soldertail and in wire-wrap. Prices fluctuate depending on the current price of the ICs, but is now $69 for a fully populated module and probably won't get much below that since I can now get 100 chips at a time for $2.50 each (including shipping, and I don't have to pay sales tax since I have a resale number) and the assembly & test labor is dominating the overall price. If you're in California, I have to charge sales tax, but not otherwise. Shipping to you will be about $6 by Priority Mail, regardless of quantity.

I have a page answering wire-wrap questions and doubts, at http://wilsonminesco.com/6502primer/WireWrap.html , as part of the 6502 primer. Other chapters may help you too. There are several chapters that are not specific to the 6502.


I've actually come across this thing before, and I want to get one, but using it in THIS system would require I redesign the memory controller. But I will consider it in some future build. Maybe when I start working with the Z80 (That'll happen when my TI-83 dies :twisted: ). Plus, I would have to get two for 16 bit capability, and that would cause a price that's a bit excessive for RAM of this capacity. And I just so happen to be in California.


Wed Oct 28, 2015 12:53 am
User avatar

Joined: Tue Jan 15, 2013 5:43 am
Posts: 184
FloppidyDingo wrote:
I'd LOVE to use SRAM as a starter, but [...]
If you're unable to accommodate both DRAM and SRAM then omit the DRAM -- that's my suggestion. A coupla 32-pin DIP sites can hold anywhere from 4KB to 512KB or more, so it's not like you'd be hurtin'.

Quote:
The RAM timings will be changeable through the BIOS, so you can squeeze every last bit of performance out of this thing. I was going to have this thing support overclocking, but I decided to wait until the next model.
I like the second sentence of this quote (omitting/postponing a feature), whereas the first sentence is just plain hard to take seriously. With three different clock rates required to mesh in the proposed system it'll take somewhat of an expert to make anything work at all! And you want the timing to be variable as well! Is that worth risking the project's success? No. Are you gonna be too busy for that anyway, making the video work and writing cool programs? :) Of course you are!

Quote:
But I do have one possible problem that could show: ignoring the LDS and UDS lines.
Hmmm, that's not something you can copy from the other project, is it. (68008 doesn't have LDS and UDS.) Nothing wrong with copying useful features -- I'm actually in favor of learning from what others have done.

I haven't studied the CPU data sheet but I don't think you can ignore these signals. Devices attached to the bus need to know whether to respond, and they also need to know when (during which timing window) to respond. I suspect LDS and UDS may tell them both.

No offense, but this question is a lot easier for you to solve than some of the other stuff you've been talking about -- just sayin'!

cheers,
Jeff


You do not have the required permissions to view the files attached to this post.

_________________
http://LaughtonElectronics.com


Wed Oct 28, 2015 2:05 am WWW
User avatar

Joined: Tue Jan 15, 2013 5:43 am
Posts: 184
FloppidyDingo wrote:
And 72 pin RAM is 32 bit, much more than I need. If there is some other magical format that I don't know about, then please tell me.
Oops, I overlooked this question. (And I admit DRAM is doable, as long as you're not also attempting a dozen other challenging features.)

I think it should be possible to connect both 16-bit halves of a 72 pin DRAM to the data bus of the CPU. IOW the two halves would be tied to each other and to the CPU. You'd need to ensure that only one of the halves is active at a time, but that can be accomplished by withholding either RAS or CAS (or both) from the half you want inactive. (According to Wikipedia there are four RAS inputs and four CAS inputs -- the "32-bit" SIMM is organized as four bytes wide.)

Alternatively, if the SIMM's total capacity is 32MB or more you could simply leave one half unused (with signals tied to Gnd or +5). The waste really doesn't matter. You'll still be able to fill up the 68000's 16MB address space.

_________________
http://LaughtonElectronics.com


Wed Oct 28, 2015 3:53 am WWW
User avatar

Joined: Thu Oct 08, 2015 11:57 pm
Posts: 65
Dr Jefyll wrote:
I like the second sentence of this quote (omitting/postponing a feature), whereas the first sentence is just plain hard to take seriously. With three different clock rates required to mesh in the proposed system it'll take somewhat of an expert to make anything work at all! And you want the timing to be variable as well! Is that worth risking the project's success? No. Are you gonna be too busy for that anyway, making the video work and writing cool programs? Of course you are!


Well, I'm not going to put variable timings in right away! I'm going to get the system to at least boot up and operate correctly, and then try to add the timing variables. But it shouldn't be that hard, should it? It's just telling the NB how many clocks to wait before pulling DTACK low for the RAM, and how long to hold RAS before pulling CAS. Unless there's something else I don't know... I want the NB to run at twice the speed as the CPU so that it responds faster, reducing the wait states needed to complete data transactions. The SB has to run at 16 MHZ because otherwise nothing will work in it. That shouldn't be too hard to implement, should it?

Dr Jefyll wrote:
I haven't studied the CPU data sheet but I don't think you can ignore these signals. Devices attached to the bus need to know whether to respond, and they also need to know when (during which timing window) to respond. I suspect LDS and UDS may tell them both.


All I get from the datasheet is that these control the data masking on the data bus. If LDS is low, supply bits on the lower 8 bits. If UDS is low, supply data to the upper 8 bits. When I don't need to supply data on that line, it just says "no valid data." I'm not sure if this means the processor will ignore the data, or I should leave that half alone. If they do tell which device to respond, then I'm very lucky I modeled my memory map in a way that compensates for it. I'll ignore them first, and add more circuitry if needed. Let's just hope I'm okay.

Dr Jefyll wrote:
No offense, but this question is a lot easier for you to solve than some of the other stuff you've been talking about -- just sayin'!


None taken! My issue is that I like to challenge myself a bit too much. Maybe so much that it's pushing the boundaries of masochistic. Today I spent a couple of hours toning down the complexity if my game console to make it more doable. But I totally agree with you, I need to take baby steps.


Wed Oct 28, 2015 4:34 am
User avatar

Joined: Thu Oct 08, 2015 11:57 pm
Posts: 65
So after looking at a university power point, I have found out that I cannot ignore the LDS and UDS pins. But I can however use four extra latches to remedy the solution. That's one more challenge out of the way. Hopefully. But now I'm starting to wish I got a bigger board...


Wed Oct 28, 2015 4:52 am

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1632
Strobing the DRAM correctly probably isn't too hard - especially if you have a fast clock to arrange everything, as opposed to monostable delays. But you do have to arrange for refresh - unless you're going have a video subsystem do that for you, or an interrupt routine.

It must be true that SRAM is easier than DRAM, but only you can figure out if you're up to the extra challenge on the first iteration.

(Making use of page mode in DRAM is a little bit harder again, for some extra performance, and then SDRAM seems to be even more difficult. Again though, it's possible.)

I did look at the 68000 bus interface signals once, and they are quite a handful compared to an 8-bit micro. But if you choose a 68k, you have to deal with that!

I do wish you good luck in your adventure, and look forward to seeing updates.


Wed Oct 28, 2015 9:12 am
User avatar

Joined: Thu Oct 08, 2015 11:57 pm
Posts: 65
BigEd wrote:
But you do have to arrange for refresh - unless you're going have a video subsystem do that for you, or an interrupt routine.


I'm just going to have the CPLD do CAS before RAS refresh cycles whenever the RAM is idle.


Wed Oct 28, 2015 10:50 pm
User avatar

Joined: Tue Jan 15, 2013 5:43 am
Posts: 184
FloppidyDingo wrote:
I'm just going to have the CPLD do CAS before RAS refresh cycles whenever the RAM is idle.

Good choice -- that's a reasonable solution. (You're lucky not to be using the older DRAM chips that lacked that feature!)

What exactly is an acceptable period of idleness for the RAM -- and what CPU signals will tell you RAM is idle? IOW, how will the CPLD know when it's a good time to start a refresh?

Also, a CAS before RAS refresh cycle takes a certain amount of time to complete. Once a refresh cycle has been started, is it possible the CPU will try to re-commence using RAM before the refresh is done? (A State Diagram is one way to study the issue and ensure the CPU and the refresh don't trip each other up.)

_________________
http://LaughtonElectronics.com


Thu Oct 29, 2015 12:58 am WWW
User avatar

Joined: Thu Oct 08, 2015 11:57 pm
Posts: 65
Dr Jefyll wrote:
What exactly is an acceptable period of idleness for the RAM -- and what CPU signals will tell you RAM is idle? IOW, how will the CPLD know when it's a good time to start a refresh?

Also, a CAS before RAS refresh cycle takes a certain amount of time to complete. Once a refresh cycle has been started, is it possible the CPU will try to re-commence using RAM before the refresh is done? (A State Diagram is one way to study the issue and ensure the CPU and the refresh don't trip each other up.)


The CPLD will do one refresh immediately after a RAM transaction, and set a timer the chip has to wait for until allowing another transaction. I'll have to play around with that number to find a wait time that works (Or I could not be lazy and do some research :lol: ). IOW if the CPU requests RAM usage before the refresh timer is done, then the CPLD will suspend the request until the refresh is done, and then carry out the transaction.


Also, due to the lack of IO after taking into account the LDS and UDS pins, I won't be able to make the timings variable. Oh well, maybe next time. I sooooo wanted to include that feature! Next time I need to add more wiggle room when looking for a large enough CPLD.


Thu Oct 29, 2015 3:17 am
 [ 37 posts ]  Go to page 1, 2, 3  Next

Who is online

Users browsing this forum: CCBot and 0 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

Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software