John Coffman
2014-11-29 22:21:24 UTC
Dave,
I am slowly going forward with the ECB/ATX board design for the MC68030
CPU. Your suggestion to go with PLD's for some of the glue logic is
sure a space saver. I have chips on order, and want to actually play
with them a bit before putting them in an actual board.
A lot will depend on board space, but I would like this board to be
upward compatible with the existing Mini-68K (MC68008 CPU). So far this
looks feasible, but porting each of the sub-systems from the MF/PIC
board is a tedious process. There are a couple of things I would like
to add to the board: a high speed IDE-8 interface for CF-cards (Mark IV
variety), an SD card socket, and an FPU coprocessor socket. I list the
items in order of descending usefulness & priority.
The main item I'd like your opinion on is the MC68881/68882 FPU
coprocessor: PGA or PLCC. The respective board footprints are 10x10 or
11x11, not a great difference. Personally, I prefer the look of the
ceramic PGA.
Your opinion is solicited.
====================================================
So, here's the board at a glance:
1. MC68030RC16 cpu (design speed is 16Mhz). Anything faster is gravy.
2. 4Mb on-board SRAM.
3. NS32202 interrupt system. (We have to get with Rich on
distributing these chips with the board.)
4. TL16C550FN -- the hardware flow control works in the PLCC-44
package, and it takes up less space.
5. 82C55 for 26-pin parallel port, or PPIDE disk interface.
6. DS1302 clock/calendar.
Space permitting:
7. IDE-8 socket for CF card adapter
8. SD card socket (bit banged inteface)
9. MC68881/58882 co-processor socket.
Caveat:
10. GAL's will be used. A kit of these will have to be made
available to those who cannot burn a JEDEC file.
=====================================================
It will be a couple of weeks before there is anything concrete to
publish for comment. I attach a plot to indicate what space
requirements may be looking like.
--John
I am slowly going forward with the ECB/ATX board design for the MC68030
CPU. Your suggestion to go with PLD's for some of the glue logic is
sure a space saver. I have chips on order, and want to actually play
with them a bit before putting them in an actual board.
A lot will depend on board space, but I would like this board to be
upward compatible with the existing Mini-68K (MC68008 CPU). So far this
looks feasible, but porting each of the sub-systems from the MF/PIC
board is a tedious process. There are a couple of things I would like
to add to the board: a high speed IDE-8 interface for CF-cards (Mark IV
variety), an SD card socket, and an FPU coprocessor socket. I list the
items in order of descending usefulness & priority.
The main item I'd like your opinion on is the MC68881/68882 FPU
coprocessor: PGA or PLCC. The respective board footprints are 10x10 or
11x11, not a great difference. Personally, I prefer the look of the
ceramic PGA.
Your opinion is solicited.
====================================================
So, here's the board at a glance:
1. MC68030RC16 cpu (design speed is 16Mhz). Anything faster is gravy.
2. 4Mb on-board SRAM.
3. NS32202 interrupt system. (We have to get with Rich on
distributing these chips with the board.)
4. TL16C550FN -- the hardware flow control works in the PLCC-44
package, and it takes up less space.
5. 82C55 for 26-pin parallel port, or PPIDE disk interface.
6. DS1302 clock/calendar.
Space permitting:
7. IDE-8 socket for CF card adapter
8. SD card socket (bit banged inteface)
9. MC68881/58882 co-processor socket.
Caveat:
10. GAL's will be used. A kit of these will have to be made
available to those who cannot burn a JEDEC file.
=====================================================
It will be a couple of weeks before there is anything concrete to
publish for comment. I attach a plot to indicate what space
requirements may be looking like.
--John
John
If I recall the EC version is without a MMU so I don't think you want
that version. Look at doc you sent 030 says on chip memory management
- the EC030 does not.
I am no expert at GALS but I use galasm which is an open source
assembler that will take .PLD files and turns them in to .JED files
that most eprom programmers can read and write the GALs. The format
is pretty easy and you basically define the pins and write boolean
equations for them. I will be glad to help where needed. Here is a
http://www.uchobby.com/index.php/2008/03/30/gals-for-electronics-hobby/
If you look in the Gryphon directory on pbworks Paul put a copy of
galasm for the pc (I got the sources and compiled for Mac) and the
.pld files he is using on Gryphon. I think from looking at the PLD
files you can see they are pretty straight forward. And they sure
make changing things easier. For example I think one of the problems
that I am having with the board is the chip selects are going low
before they should because they are not qualified with AS* - so I can
attach AS* to the /NC pin that is still free and qualify all the chip
selects with AS* as they should be only valid when AS* is asserted.
Dave
If I recall the EC version is without a MMU so I don't think you want
that version. Look at doc you sent 030 says on chip memory management
- the EC030 does not.
I am no expert at GALS but I use galasm which is an open source
assembler that will take .PLD files and turns them in to .JED files
that most eprom programmers can read and write the GALs. The format
is pretty easy and you basically define the pins and write boolean
equations for them. I will be glad to help where needed. Here is a
http://www.uchobby.com/index.php/2008/03/30/gals-for-electronics-hobby/
If you look in the Gryphon directory on pbworks Paul put a copy of
galasm for the pc (I got the sources and compiled for Mac) and the
.pld files he is using on Gryphon. I think from looking at the PLD
files you can see they are pretty straight forward. And they sure
make changing things easier. For example I think one of the problems
that I am having with the board is the chip selects are going low
before they should because they are not qualified with AS* - so I can
attach AS* to the /NC pin that is still free and qualify all the chip
selects with AS* as they should be only valid when AS* is asserted.
Dave
Dave,
There is nothing like hashing something out with another person.
After sending off the last e-mail, I came to the conclusion that fooling
with a home-brewed MMU had two drawbacks: board space, and new software
requirements. Board space was the clincher. The 68030 has exactly the
same board acreage as the 68020, plus no board space needed for the MMU.
The 6U board design allows 4 x 512K 55ns SRAM chips (like the Mini-68k),
but ganged into a 32-bit wide memory array. Long-term, DRAM is going to
be necessary. Yuk!
BTW: the MC68030 and MC68EC030 chips are identical, including PGA
pinout. The F91C mask is the tightest (0.8 micron), so it probably means
the least power dissipation. I attach the Motorola mask summary I found.
I'm going to proceed with a tentative 68030 design. I'd like to
eliminate the MF/PIC requirement, if possible.
====================================
Any help you can give me with GAL programming would be appreciated. I
have never used them (I'm a software type, too) in hobby work. What s/w
& h/w do you use to design and program GAL16V8 .. GAL22V10's?
--John
There is nothing like hashing something out with another person.
After sending off the last e-mail, I came to the conclusion that fooling
with a home-brewed MMU had two drawbacks: board space, and new software
requirements. Board space was the clincher. The 68030 has exactly the
same board acreage as the 68020, plus no board space needed for the MMU.
The 6U board design allows 4 x 512K 55ns SRAM chips (like the Mini-68k),
but ganged into a 32-bit wide memory array. Long-term, DRAM is going to
be necessary. Yuk!
BTW: the MC68030 and MC68EC030 chips are identical, including PGA
pinout. The F91C mask is the tightest (0.8 micron), so it probably means
the least power dissipation. I attach the Motorola mask summary I found.
I'm going to proceed with a tentative 68030 design. I'd like to
eliminate the MF/PIC requirement, if possible.
====================================
Any help you can give me with GAL programming would be appreciated. I
have never used them (I'm a software type, too) in hobby work. What s/w
& h/w do you use to design and program GAL16V8 .. GAL22V10's?
--John
John,
In my opinion the 6U board is the way to proceed. In that case I
would choose a 68030 design. I would assume the memory would be on
the same board so that would simplify some of the design. My
concern is memory - thru hole static memory in it's current
densities will not scale up very well. Without SMD devices it is
going to be hard to get to a useful memory size if people want to
play with Linux for example. I think we would need 64M minimum but
256M would be more desirable. The 68030 cost is not too bad - I
picked up 3 of them on eBay for 14 dollars a piece. The FPU I think
was less than that. The dynamic bus sizing and the integrated MMU
will be useful and gluing the FPU is pretty straight forward.
The Gryphon design is not too bad and pretty simple (though I don't
have it working yet - my guess is that a few more signals need to be
used as qualifiers in the GALs). I hope to have it working in the
next couple of weeks. It would be pretty easy to take this and add
a N8VEM buss to it and move some of the I/O off board? This would
make the board much smaller and maybe simpler. What are your
requirements for using programmable logic? Are GALS or CPLDs
allowed? Some of the old Xilinx xc95 series are readily available
on eBay and support 5 volt usage (XC9536, XC9572, XC95108 - all
available in PLCC). GALs are easily programmed by most eprom
programmers though the CPLDs require a JTAG interface.
If we keep the main logic (processor, memory, and bus control) and
single board we could tolerate higher CPU clock speeds and use wait
states for off board I/O. It is nice that 68K has asynchronous bus
but I am not sure how that will work with synchronous bus on ECB,
We definitely have run into problems making this work on S100 bus
(so far I have not been able to make IDE work there) because of some
timing constraints.
I think the best thing now is for me to get basic Gryphon running
and we can see if that might be a starting point for an 030 design.
The memory to me is the big question. I am not seeing an easy way
to get to larger memory without a dynamic memory controller (which
is beyond me to design - I am a software engineer by trade but know
just enough hardware to be dangerous) or going to some SMD type
memory. There are some nice PSRAM from ISSI that are 2Mx16 but they
are 48pin BGA which would be very difficult to use.
Dave
In my opinion the 6U board is the way to proceed. In that case I
would choose a 68030 design. I would assume the memory would be on
the same board so that would simplify some of the design. My
concern is memory - thru hole static memory in it's current
densities will not scale up very well. Without SMD devices it is
going to be hard to get to a useful memory size if people want to
play with Linux for example. I think we would need 64M minimum but
256M would be more desirable. The 68030 cost is not too bad - I
picked up 3 of them on eBay for 14 dollars a piece. The FPU I think
was less than that. The dynamic bus sizing and the integrated MMU
will be useful and gluing the FPU is pretty straight forward.
The Gryphon design is not too bad and pretty simple (though I don't
have it working yet - my guess is that a few more signals need to be
used as qualifiers in the GALs). I hope to have it working in the
next couple of weeks. It would be pretty easy to take this and add
a N8VEM buss to it and move some of the I/O off board? This would
make the board much smaller and maybe simpler. What are your
requirements for using programmable logic? Are GALS or CPLDs
allowed? Some of the old Xilinx xc95 series are readily available
on eBay and support 5 volt usage (XC9536, XC9572, XC95108 - all
available in PLCC). GALs are easily programmed by most eprom
programmers though the CPLDs require a JTAG interface.
If we keep the main logic (processor, memory, and bus control) and
single board we could tolerate higher CPU clock speeds and use wait
states for off board I/O. It is nice that 68K has asynchronous bus
but I am not sure how that will work with synchronous bus on ECB,
We definitely have run into problems making this work on S100 bus
(so far I have not been able to make IDE work there) because of some
timing constraints.
I think the best thing now is for me to get basic Gryphon running
and we can see if that might be a starting point for an 030 design.
The memory to me is the big question. I am not seeing an easy way
to get to larger memory without a dynamic memory controller (which
is beyond me to design - I am a software engineer by trade but know
just enough hardware to be dangerous) or going to some SMD type
memory. There are some nice PSRAM from ISSI that are 2Mx16 but they
are 48pin BGA which would be very difficult to use.
Dave
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to n8vem+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to n8vem+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/d/optout.