RetroBrew Computers Forum
Discussion forum for the RetroBrew Computers community.

Home » RBC Forums » General Discussion » Gryphon 68030
Gryphon 68030 [message #761] Wed, 08 June 2016 13:57 Go to next message
lynchaj is currently offline  lynchaj
Messages: 365
Registered: June 2016
Senior Member
Hi
Is anyone working on or still interested in the Gryphon 68030 SBC project?

Andrew Lynch
Re: Gryphon 68030 [message #762 is a reply to message #761] Wed, 08 June 2016 13:58 Go to previous messageGo to next message
lynchaj is currently offline  lynchaj
Messages: 365
Registered: June 2016
Senior Member
https://www.retrobrewcomputers.org/doku.php?id=boards:sbc:gr yphon_68030:start

https://retrobrewcomputers.org/n8vem-pbwiki-archive/0/630388 91/index.htm
Re: Gryphon 68030 [message #763 is a reply to message #762] Thu, 09 June 2016 01:43 Go to previous messageGo to next message
computerdoc is currently offline  computerdoc
Messages: 88
Registered: October 2015
Member

I am still interested, am on and still have the Gryphon 68030 prototype board. Is anyone else still interested?

Kip Koon
computerdoc at sc dot rr dot com
http://www.cocopedia.com/wiki/index.php/User:Computerdoc
Re: Gryphon 68030 [message #765 is a reply to message #763] Fri, 10 June 2016 03:16 Go to previous messageGo to next message
lynchaj is currently offline  lynchaj
Messages: 365
Registered: June 2016
Senior Member
Hi
I am in the process of recapturing the Gryphon 68030 ver 1.1 schematic in KiCAD and will post it here for review once it is done. It is large and complicated so I'll need some reviewers to do a full "pin audit" comparisons between the new KiCAD version and the current Proteus schematic on the wiki to ensure it is 100%. It should take about 2 hours for a full review.

The good news is we don't have to start from scratch but the transition to open source EDA I think will add some flexibility for others to get involved. The downside is there is a lot of rework involved and the two different EDAs don't align very well in some aspects.

Thanks

Andrew Lynch
Re: Gryphon 68030 [message #766 is a reply to message #765] Fri, 10 June 2016 08:56 Go to previous messageGo to next message
computerdoc is currently offline  computerdoc
Messages: 88
Registered: October 2015
Member

Hi Andrew,
In reference to schematic comparison, my HP Laserjet 5 printer is not doing well at the moment. For years it has performed perfectly until recently. When I go to print a multipage document, it will only print one page, then it prints several blank pages. The printer display asks for letter size paper before each and every page is printed. It used to not ask for letter size before. I even checked the default size paper in the printer itself and it is set to letter so I'm at a loss as to what is causing this to happen. I'd like to print the schematics to do the comparison, but I'll have to figure out a way to print one page at a time. It should be easy, just specify one page at a time. I'll have to see how it goes.
I personally like the idea of having everything on one PCB so I'm very glad to hear that activity on the Gryphon 68030 has resumed. Please keep me in the loop. I'd like to see OSK, Fuzix or maybe Linux and CP/M 68K ported over to run on this board. Is there an MP/M 68K? I will be interesting to see what people do with these boards. Take care my friend.


Kip Koon
computerdoc at sc dot rr dot com
http://www.cocopedia.com/wiki/index.php/User:Computerdoc
Re: Gryphon 68030 [message #767 is a reply to message #766] Fri, 10 June 2016 09:16 Go to previous messageGo to next message
lynchaj is currently offline  lynchaj
Messages: 365
Registered: June 2016
Senior Member
Hi
My goal is to recreate the original Gryphon 68030 PCB with corrections from the original build and test with the version 1.0 PCBs. Once those are available I am sure there will be plenty of opportunities for new developers to write software, port operating systems, etc. However for now the project seems stalled out since the PCBs are no longer available. Since the updated version 1.1 PCBs were never made (AFAIK), the development halted pending updates and corrections. My theory is updated version 1.1 PCBs should restart the build and test cycle.

As for the schematic, it is only four pages long so printing it should not be an issue even with a balky HPLJ5 printer. I'll post PDF versions of the schematic along with other files as they are available.

Thanks

Andrew Lynch
Re: Gryphon 68030 [message #768 is a reply to message #767] Fri, 10 June 2016 10:46 Go to previous messageGo to next message
yoda is currently offline  yoda
Messages: 99
Registered: October 2015
Location: Austin, TX
Member
Hi Andrew,

I know we have talked privately about the board but might as well get some feed back in the open. I have to ask what is the final end game here? As it stands, the 1.1 version still has some issues in stability - maybe the updates will make it better as there were quite a few soft wires on the board. I fear the 1.1 board may be of limited use/interest. The small memory support is a problem and ROM mapped at address 0 will cause some problems (that can be over come). The video was never able to be checked because the foot print did not match the chip (rotated 90 degrees if I recall) I tried make a wiring jig for it and could not get it to communicate so there may be more issues there. The network interface has never been checked either. Both of these chips are fairly dense pin SMT devices which will not appeal to the casual hobbyist to solder. There are some very good design innovations in the board that should be carried forward but I am not sure making a replica of the original design is where we would want to start from. I think a subset would be better (a core with an I/O board add on). As you know I spent a lot of time with Paul on the bring up of this board and we got pretty far but I don't want to speak for Paul but I think we had agreed that 1.1 would be somewhat different that 1.0. I am pretty sure that the schematics would be a whole lot different and would have to be re-done (unless you have isolated things to separate sheets - not sure how much rework would occur even in that mode). Of course you know I am very interested in this so I guess a schematic is a good place to start from but I am just saying I don't think the final schematic is going to look anything like the 1.1 schematic. I just don't want to cause a lot of extra work. Again it is all about what is the end game. I would like to see a board that can run multi-user linux in the end so have a display, keyboard, and sound is not a high requirement for me initially which simplifies the board and board area significantly. Also I would like to use an Altera CPLD or two, to consolidate the GALs which would simplify the board layout and the patch work that happened in the other GALs as changes were made.

Dave
Re: Gryphon 68030 [message #769 is a reply to message #768] Fri, 10 June 2016 11:43 Go to previous messageGo to next message
lynchaj is currently offline  lynchaj
Messages: 365
Registered: June 2016
Senior Member
Hi

My plan is to capture the original design in KiCAD first and use it as a basis for further work because that's what is available right now and is necessary work regardless. There are many issues with the translation from Proteus to KiCAD and a lot of opportunities for problems to be introduced. Once we know there is a solid design foundation, the Gryphon schematic can be further decomposed into small modular subsystems much like the hierarchical schematic of the 6x0x-ATX-6U board. We need a KiCAD schematic that can reasonably pass ERC first though as a basis for modification.

IMO, there is a lot of IO on the Gryphon that can be exported off the main PCB onto IO subsystem board(s). Also opportunities for reusing the DRAM logic from the KISS-68030 and/or consolidating some off the glue logic & PALs into a CPLD for a more integrated "CPU and memory" board. However without some basis of a design in KiCAD that is all theoretical. Since the PCB version 1.1 schematic is available here and now that's where I started.

I think the most important thing we can do for the Gryphon is to release it from the trap of proprietary EDA of Proteus and get a solid verified design in KiCAD so others can more directly participate. It almost does not matter where we start with that as long as the cycle of prototype PCBs can begin somewhere. As with other boards I helped create it is not unusual for the design to evolve significantly over time introducing major changes. We can do the same with the Gryphon. I am using the technical data we have now to capture the design and it can be modified once it is decomposed into smaller schematic modules. For instance the first page of the schematic 1.1 could easily be broken down into a CPU+coprocessor, Flash+SRAM, and controller+DRAM subsystem pages if not even further.

Thanks

Andrew Lynch
Re: Gryphon 68030 [message #770 is a reply to message #769] Fri, 10 June 2016 11:49 Go to previous messageGo to next message
yoda is currently offline  yoda
Messages: 99
Registered: October 2015
Location: Austin, TX
Member
Hi

I understand - I think we are in agreement - I just don't know how hard it is to rework schematics in KiCad and am trying to minimize the amount of rework. I will review and verify schematics as they become available. I am just trying to start the discussion of what the group's expectations and requirements may be.

Thanks

Dave
Re: Gryphon 68030 [message #771 is a reply to message #770] Fri, 10 June 2016 12:10 Go to previous messageGo to next message
lynchaj is currently offline  lynchaj
Messages: 365
Registered: June 2016
Senior Member
Hi
Well, it is sort of like building a library of modules. It is easy to rework once you know you have good parts.

I think the ultimate goal of the project should be a completely open source general purpose, modular, 68030 based system which can run Linux.

The main board can be reduced to a small ATX format board with CPU, SRAM, Flash, DRAM, serial port, SD card and expansion bus (TBD -- not ISA but something akin to it for the 680x0 CPU family). Have just the bare minimum necessary to run Linux. All other IO exported to an optional AT sized format board. This would allow usage of cheap and plentiful ATX PC cases and power supplies.

Much of this concept is already embedded in the Gryphon schematic. It is highly modular right now and is just begging for a breakout. Page three even has an initial bus interface separating the CPU+memory from the IO subsystem.

Thanks

Andrew Lynch

Re: Gryphon 68030 [message #772 is a reply to message #771] Fri, 10 June 2016 12:24 Go to previous messageGo to next message
yoda is currently offline  yoda
Messages: 99
Registered: October 2015
Location: Austin, TX
Member
Great!

I look forward to seeing the schematics and where we go from there.

Thanks

Dave
Re: Gryphon 68030 [message #773 is a reply to message #761] Fri, 10 June 2016 15:06 Go to previous messageGo to next message
jcoffman is currently offline  jcoffman
Messages: 146
Registered: October 2015
Senior Member
Andrew,

A couple of things learned with the KISS-68030 project:

1. DRAM requires lots of big electrolytic decoupling caps to handle the refresh current surges. High frequency decoupling with 0.1uF on each chip is enough.
2. 4-layer design is a must; inner 2 layers should be power and ground planes.
3. To run 0 or 1 wait-state, you'll need F-logic & 7ns GALs.
4. Best thing learned from Gryphon 1.0 was to have SRAM available while you sort out the DRAM quirks.

Will's Linux runs like a charm on a 32Mb KISS + MF/PIC combo. The 10.2 BIOS has CP/M-68 as well.

--John
Re: Gryphon 68030 [message #774 is a reply to message #773] Sat, 11 June 2016 03:29 Go to previous messageGo to next message
will is currently offline  will
Messages: 137
Registered: October 2015
Senior Member
Hi

Getting Linux booting may prove a pain if there is ROM at physical address 0; the kernel expects to be loaded here and expects the MMU disabled on boot.

The KISS-68030 gives us a solid 68K machine with MMU and DRAM already. Enhancements I would like to see in a future 68K board would be;



  • 68040 or 68060 CPU at high clock speed
  • Memory controller which makes use of the CPU's synchronous, pipeline and burst mode transfer features
  • Support for DMA, primarily for ethernet and hard disk interfaces



I think the idea of exchanging GALs for a CPLD or FPGA is excellent. There is now a fully open-source toolchain for Lattice ICE40 FPGAs. I am told it is possible ("easy", some bravely claim!) to hand solder TQFP-144 packages so we could use a iCE40HX4K-TQ144, an inexpensive part with over 100 I/O pins. This, and the later 68K CPUs, would require the board to run on 3.3V.

It would be nice to have a keyboard and high-resolution video output although this could be on a peripheral board as I am very happy with a serial console.

W

[Updated on: Sat, 11 June 2016 03:32]

Report message to a moderator

Re: Gryphon 68030 [message #776 is a reply to message #774] Sat, 11 June 2016 10:43 Go to previous messageGo to next message
yoda is currently offline  yoda
Messages: 99
Registered: October 2015
Location: Austin, TX
Member
Hi Will

Paul and I had talked about the ROM at 0 in the Gryphon and that was a planned change in next version - it is pretty simple to do. The problem with 68040 and 060 is there is no dynamic bus sizing support so things now all devices have to be 32 bit wide (Rom, ram, I/O). There are ways around it like the 68360 and 68150. Andrew and I played with the 68360 a while ago and might be time to resurrect it. It is definitely not for the faint of heart to program (there are so many registers and modes for the device). It does provide some useful I/O and a dynamic memory controller. Knowing what I know now from the Gryphon bring up and other things I think it might be a useful device to bring back (I guess I will have to dust off my proto board and remember where I left off). Andrew's and my intentions were to eventually marry this to a 68040 - that might be the next direction after getting a core Gryphon running smoothly.

I have also thought about FPGA's in the design but the drawback is that you have to "download the design" into the FPGA before you can use, so if you don't have some way of boot code sequence, you have a hard time using them for glue logic. I got a bunch of Altera Max 7128slC84's which are relatively cheap from UtSource and they are 5 volt tolerant versions and the JTAG pod for Altera is reasonably cheap as well - can be had on eBay for less than 20 dollars normally. The software is free and runs on Windows and Linux so that is nice as well. I must admit I have not tried them out yet but I think it is pretty straight forward to use them.

The high resolution display is a real issue because getting beyond 800x600 is non trivial. An FPGA might be the route to use for that. I plan on on experimenting with a DE0 nano to do something like that. So many projects in the queue.

I am somewhat excited as this project can expand in many different directions going forward

Dave
Re: Gryphon 68030 [message #781 is a reply to message #776] Sun, 12 June 2016 04:15 Go to previous messageGo to next message
lynchaj is currently offline  lynchaj
Messages: 365
Registered: June 2016
Senior Member
Hi
OK. I've been reading the above discussion and it sounds like there are two issues which need to be addressed before moving on to a more advanced prototype board. I am nearly complete with the recapture of the Gryphon version 1.1 schematic and will be posting it soon.

First, the ROM at address 0 is blocking progress on a Linux port. So modify the existing Gryphon design to add another 512K SRAM and some minimal glue logic to allow swapping of the Flash with the SRAM. It really is pretty trivial and the original N8VEM SBC has simple memory swapping circuit. We can use something like that.

Second, the build and test of the original Gryphon was not completed due to PCB problems and various debugging issues that Yoda discussed earlier. This needs to be accomplished so the later core CPU boards and IO boards have a reasonable chance of working.

So I propose a slightly revised plan going forward. Begin with building the existing Gryphon 1.1 plus swappable 512K SRAM + minor glue logic fixes. That can be made into a PCB which can be used to begin a Linux port while simultaneously completing the original Gryphon build and test cycle. It also recaptures the Gryphon EDA in KiCAD which I cannot emphasize enough is a huge and risky step by itself. Oh BTW, I have found there are a number of errors embedded in the original Gryphon 1.1 schematic so we still have to deal with verifying the basic design.

Next taking the results of the initial Linux port and completed build and test, prepare the updated Gryphon board with a small core CPU board and separate IO board. This would entail the CPLD changes, swapping out the DRAM glue from VT8242 to the 68030-KISS style logic, and creation of some sort of crude 68030 version of ISA bus. These are all huge changes and will take some time to lay them out properly. Some of this can be done in parallel with the Linux port and Gryphon 1.1 build and test.

I think this new approach breaks up the development into logical phases so we are not trying to make too many changes at once. Previous projects have done this and it results in a lot of non-working prototype boards and general frustration all around. Let's try a more modest, less risky, phased approach that allows different people to do different tasks in parallel.

Thanks

Andrew Lynch

[Updated on: Sun, 12 June 2016 04:21]

Report message to a moderator

Re: Gryphon 68030 [message #782 is a reply to message #781] Sun, 12 June 2016 06:36 Go to previous messageGo to next message
yoda is currently offline  yoda
Messages: 99
Registered: October 2015
Location: Austin, TX
Member
Hi Andrew

I think your proposal looks good. The only thing I would do different is introduce the CPLD now. If you look at it now, a lot of the GALs have a lot of the same signals into them and some are dependent on others. It would be simpler to consolidate. Also the 1.1 schematics are missing another GAL to make interrupts works which I will try to paste in when you get schematics. Let me see what will fit in a CPLD and we can decide then, but I would want at least 2 unwired GALS (except for power and GND) on the board to do more glue work - I think there is some still left.

Dave
Re: Gryphon 68030 [message #783 is a reply to message #782] Sun, 12 June 2016 07:03 Go to previous messageGo to next message
lynchaj is currently offline  lynchaj
Messages: 365
Registered: June 2016
Senior Member
Hi

As promised, a Gryphon 1.1 schematic converted to KiCAD. Includes the EEschema ERC file if anyone would like to work on that also. Several (14) severe warnings on bidirectional pins connected to tristate pins. This should work regardless but KiCAD is complaining about it. Is there anything we can do?

To do a pin audit, just print out both the original Proteus Gryphon 1.1 schematic and the new KiCAD Xagdin schematic PDFs. Get a fine point red marker and go through both schematics on component at a time and compare. If they are the same put a red dot next to each pin. If there is a mismatch or something missing, extra unexplained stuff, etc. put a red circle around the offending item and post results here.

Thanks

Andrew Lynch

PS, I gave my schematic the temporary junk name Xagdin to separate it from the Gryphon main branch so people can keep them straight. Xagdin is literally a random username generated to distinguish the two schematics. Once we know the Xagdin (KiCAD) schematic is good we can erase Xagdin and conform the schematic in the Gryphon design series.
  • Attachment: Xagdin.zip
    (Size: 1.05MB, Downloaded 25 times)
Re: Gryphon 68030 [message #784 is a reply to message #783] Sun, 12 June 2016 07:13 Go to previous messageGo to next message
lynchaj is currently offline  lynchaj
Messages: 365
Registered: June 2016
Senior Member
Hi Dave
OK looks good to go with the CPLD. I like the idea of some spare logic capacity since the 512K SRAM would require a bit of decoding and swap logic to get it to replace the Flash on command. My concern is to keep the project focused and not introduce too many changes at once or it will blow up into massive complexity. Lets get what we have working first and then modify something we know works. The bus, more advanced CPUs, DMA, etc. can wait for now.

While others are working on reviewing the schematics, making the CPLD changes, etc. I will start on replicating the Gryphon 1.0 PCB layout so we can verify part footprints. There will have to be some differences because the Gryphon specified parts like the stacked 9 pin dual male DB connectors which are unobtainium in KiCAD. Those will have to be replaced with single male DB9s.

Thanks

Andrew Lynch

PS, BTW do we really need 512KB Flash and 1024KB SRAM just to boot this thing? How about a 32KB EEPROM and a pair of 32KB skinny SRAMs instead? Pull the rest of the initialization data from external stores. It is something to consider and may simplify this design a bit -- possibly a 32KB EEPROM for boot only to bring in the DRAM and swap out the EEPROM for an all DRAM system.

[Updated on: Sun, 12 June 2016 07:25]

Report message to a moderator

Re: Gryphon 68030 [message #785 is a reply to message #761] Sun, 12 June 2016 07:27 Go to previous messageGo to next message
will is currently offline  will
Messages: 137
Registered: October 2015
Senior Member
Hey

On the memory map front: The ideal mapping for Linux would place 32-bit wide DRAM from physical address 0 upwards. Linux locates the kernel here at the bottom of physical memory so placing narrower RAM or less than about 16MB of RAM at 0 is likely to be a pain or limit performance (or both!).

32KB EEPROM would be enough to boot the system from disk I expect. Even my minimal ROMs for the KISS board are about 48KB, though, so I would prefer to see the 512KB ROM capability.

One thing confuses me -- why not start from the known-working KISS-68030 design, convert the GALs to a CPLD, possibly enlarge the board, and add new features to that? The KISS design is in KiCAD already. Starting with the known non-working Gryphon design, taking out the interesting features like DMA, bringing in the KISS memory controller etc, then fixing it until it works , just feels a bit like re-inventing something we already have?

W

[Updated on: Sun, 12 June 2016 07:28]

Report message to a moderator

Re: Gryphon 68030 [message #786 is a reply to message #784] Sun, 12 June 2016 08:07 Go to previous messageGo to next message
yoda is currently offline  yoda
Messages: 99
Registered: October 2015
Location: Austin, TX
Member
lynchaj wrote on Sun, 12 June 2016 09:13
Hi Dave
OK looks good to go with the CPLD. I like the idea of some spare logic capacity since the 512K SRAM would require a bit of decoding and swap logic to get it to replace the Flash on command. My concern is to keep the project focused and not introduce too many changes at once or it will blow up into massive complexity. Lets get what we have working first and then modify something we know works. The bus, more advanced CPUs, DMA, etc. can wait for now.


The SRAM does not replace the Flash. Flash is mapped at the top of memory then the SRAM is mapped directly below it. DRAM is mapped from 0. The SRAM can be used for stack, variable scratch space and buffers.

Quote:

While others are working on reviewing the schematics, making the CPLD changes, etc. I will start on replicating the Gryphon 1.0 PCB layout so we can verify part footprints. There will have to be some differences because the Gryphon specified parts like the stacked 9 pin dual male DB connectors which are unobtainium in KiCAD. Those will have to be replaced with single male DB9s.

Thanks

Andrew Lynch

PS, BTW do we really need 512KB Flash and 1024KB SRAM just to boot this thing? How about a 32KB EEPROM and a pair of 32KB skinny SRAMs instead? Pull the rest of the initialization data from external stores. It is something to consider and may simplify this design a bit -- possibly a 32KB EEPROM for boot only to bring in the DRAM and swap out the EEPROM for an all DRAM system.


Yes keep the size. Paul and I did a very nice curses monitor that uses more than 32k and is/was growing.
Re: Gryphon 68030 [message #788 is a reply to message #785] Sun, 12 June 2016 10:19 Go to previous messageGo to next message
yoda is currently offline  yoda
Messages: 99
Registered: October 2015
Location: Austin, TX
Member
will wrote on Sun, 12 June 2016 09:27
Hey

On the memory map front: The ideal mapping for Linux would place 32-bit wide DRAM from physical address 0 upwards. Linux locates the kernel here at the bottom of physical memory so placing narrower RAM or less than about 16MB of RAM at 0 is likely to be a pain or limit performance (or both!Wink.


I think that is the plan: To re-arrange the memory map from the original - it was non optimal

Quote:

32KB EEPROM would be enough to boot the system from disk I expect. Even my minimal ROMs for the KISS board are about 48KB, though, so I would prefer to see the 512KB ROM capability.


I think the original intent was to do other OSes besides Linux - so let's keep the Flash at least the same size - It requires a healthy size ROM to be able to run diagnostics on all the I/O on the board.

Quote:

One thing confuses me -- why not start from the known-working KISS-68030 design, convert the GALs to a CPLD, possibly enlarge the board, and add new features to that? The KISS design is in KiCAD already. Starting with the known non-working Gryphon design, taking out the interesting features like DMA, bringing in the KISS memory controller etc, then fixing it until it works , just feels a bit like re-inventing something we already have?

W


I think the intent is to preserve the Gryphon board as well. It was designed before KISS-68030 and did take a different approach. I think Paul wanted to run some type of Amiga OS as well as eventually Linux so let's not preclude those things from happening as well.
Re: Gryphon 68030 [message #789 is a reply to message #783] Sun, 12 June 2016 10:26 Go to previous messageGo to next message
yoda is currently offline  yoda
Messages: 99
Registered: October 2015
Location: Austin, TX
Member
lynchaj wrote on Sun, 12 June 2016 09:03
Hi

As promised, a Gryphon 1.1 schematic converted to KiCAD. Includes the EEschema ERC file if anyone would like to work on that also. Several (14) severe warnings on bidirectional pins connected to tristate pins. This should work regardless but KiCAD is complaining about it. Is there anything we can do?

To do a pin audit, just print out both the original Proteus Gryphon 1.1 schematic and the new KiCAD Xagdin schematic PDFs. Get a fine point red marker and go through both schematics on component at a time and compare. If they are the same put a red dot next to each pin. If there is a mismatch or something missing, extra unexplained stuff, etc. put a red circle around the offending item and post results here.

Thanks

Andrew Lynch

PS, I gave my schematic the temporary junk name Xagdin to separate it from the Gryphon main branch so people can keep them straight. Xagdin is literally a random username generated to distinguish the two schematics. Once we know the Xagdin (KiCAD) schematic is good we can erase Xagdin and conform the schematic in the Gryphon design series.


Hi Andrew

I have downloaded the schematics and will start to take a look at them - probably will take a week or so. I need to compare to all my errata notes as well that did not make 1.1 of schematics. Quick perusal I can say there are changes in the IDE area as the '139 area needs updated and the connector on video should be a VGA connector instead of a DB15 connector. Also I think most would prefer the Serial I/O come out on the board to headers that a TTL to USB adapter would accept. For the cost of the Max 232, caps and db9 the dongles tend to be cheaper and work better with modern PCs.
Re: Gryphon 68030 [message #790 is a reply to message #761] Sun, 12 June 2016 10:48 Go to previous messageGo to next message
Andrew B is currently offline  Andrew B
Messages: 312
Registered: October 2015
Location: Hawthorne, CA
Senior Member
Administrator
All - all of the v1.00 information should be updated on the wiki page:

https://www.retrobrewcomputers.org/doku.php?id=boards:sbc:gr yphon_68030:start

Let me know if I missed anything.
Re: Gryphon 68030 [message #793 is a reply to message #776] Sun, 12 June 2016 16:52 Go to previous messageGo to next message
will is currently offline  will
Messages: 137
Registered: October 2015
Senior Member
Dave

Re the FPGA startup issue - I believe the FPGA can be set to load their configuration automatically from a small and inexpensive SPI flash memory chip. I think it's pretty quick, and they also have a "config done" pin that can be used to hold the reset of the circuit in reset until they are ready.

Will
Re: Gryphon 68030 [message #794 is a reply to message #793] Sun, 12 June 2016 17:16 Go to previous messageGo to next message
lynchaj is currently offline  lynchaj
Messages: 365
Registered: June 2016
Senior Member
Hi
Today has been a good day. Got outside, did stuff with the family, and got a chance to work on the Gryphon schematic and PCB.

Here is an updated KiCAD EDA file set to include and updated schematic and initial PCB layout. Doing the PCB layout was highly educational and I discovered numerous errors in the part footprints and in my schematic as well.

Regarding the CPLDs; since we are going down the programmable logic path anyway I have a suggestion. Rather than consolidate the 7 PALs into one CPLD how about focus on eliminating the 13 74LSxxx glue logic chips instead? If you look at the board, there are a whole bunch of miscellaneous logic chips in the center left of the board which are going to be a pain for trace routing. If you want to save PCB space take a look at them first. Maybe two CPLDs to consolidate the PALs and the 7LSxxx glue logic.

Thanks

Andrew Lynch
  • Attachment: Xagdin.zip
    (Size: 1.61MB, Downloaded 31 times)
Re: Gryphon 68030 [message #795 is a reply to message #790] Sun, 12 June 2016 17:18 Go to previous messageGo to next message
lynchaj is currently offline  lynchaj
Messages: 365
Registered: June 2016
Senior Member
Thank you
Re: Gryphon 68030 [message #796 is a reply to message #795] Sun, 12 June 2016 17:40 Go to previous messageGo to next message
lynchaj is currently offline  lynchaj
Messages: 365
Registered: June 2016
Senior Member
Hi
When reviewing the PCB layout please pay special attention to the footprints especially the SMT components. There are three SMT components we are probably stuck with as there aren't any reasonable alternatives: ethernet, video, and video DRAM chips.

In particular the video chip is tiny. It is a 14mmx14mm QFP with 0.4mm pin spacing as best I can tell from the datasheet. Don't drink any coffee before soldering that one in!

The net effect of this is the board requires 0.006" trace width and 0.006 trace clearance to even attempt to route video chip. That is true angel hair fine tracing and it might be an issue with the board.

Andrew Lynch
Re: Gryphon 68030 [message #797 is a reply to message #793] Sun, 12 June 2016 17:50 Go to previous messageGo to next message
yoda is currently offline  yoda
Messages: 99
Registered: October 2015
Location: Austin, TX
Member
will wrote on Sun, 12 June 2016 18:52
Dave

Re the FPGA startup issue - I believe the FPGA can be set to load their configuration automatically from a small and inexpensive SPI flash memory chip. I think it's pretty quick, and they also have a "config done" pin that can be used to hold the reset of the circuit in reset until they are ready.

Will


Hi Will,

That is true - the big issue is that it is very hard these days to find FPGAs that are 5V tolerant, so you end up with a lot of level translators as well. It is still pretty easy to find CPLDs that are 5 Volt tolerant though. The Altera ones are 5 dollars in quantity 10 from UtSource and when you consider they could replace 5 GALs then they are cheaper in the long run.

Dave
Re: Gryphon 68030 [message #798 is a reply to message #796] Sun, 12 June 2016 17:55 Go to previous messageGo to next message
yoda is currently offline  yoda
Messages: 99
Registered: October 2015
Location: Austin, TX
Member
lynchaj wrote on Sun, 12 June 2016 19:40
Hi
When reviewing the PCB layout please pay special attention to the footprints especially the SMT components. There are three SMT components we are probably stuck with as there aren't any reasonable alternatives: ethernet, video, and video DRAM chips.

In particular the video chip is tiny. It is a 14mmx14mm QFP with 0.4mm pin spacing as best I can tell from the datasheet. Don't drink any coffee before soldering that one in!

The net effect of this is the board requires 0.006" trace width and 0.006 trace clearance to even attempt to route video chip. That is true angel hair fine tracing and it might be an issue with the board.

Andrew Lynch


Hi Andrew

The Video chip was not directly on the board. It was down as a breakout board that plugs in. You can go to Proto Advantage and they will solder to their adapter for 20 dollars as I recall and you can have them get the part from Digikey. I would highly recommend that way if you have any concerns on SMT soldering. The ethernet and dram was not too bad to had solder but the video is scary.
Re: Gryphon 68030 [message #799 is a reply to message #761] Sun, 12 June 2016 18:05 Go to previous messageGo to next message
Andrew B is currently offline  Andrew B
Messages: 312
Registered: October 2015
Location: Hawthorne, CA
Senior Member
Administrator
I think it's a good practice to keep 1 type of programmable device per board, so I'd go for 2 MAX 7000S or ATF15xx-type CPLDs replacing the PALs and the remaining glue logic chips. (The Atmel parts tend to be cheaper but the software they provide is not as nice, but the 15xx and 7xxx parts are generally compatible see https://www.retrobrewcomputers.org/doku.php?id=builderpages: abingham:cpld-compatibilityWink.

That way a builder only needs 1 type of programmer.

CPLDs in general seem more reliable because you can buy 1 $20-$60 USB programmer and program them on the board with a JTAG header. GALs have several vendors that may or may not work with a given programmer - the Lattice parts and Atmel parts use different programming algorithms for instance and programmer compatibility with the lower-cost programmers and the Atmel parts can be spotty. Also only the Atmel parts are currently in-production which are the harder to program of the two.


Re: Gryphon 68030 [message #800 is a reply to message #794] Sun, 12 June 2016 18:06 Go to previous messageGo to next message
yoda is currently offline  yoda
Messages: 99
Registered: October 2015
Location: Austin, TX
Member
lynchaj wrote on Sun, 12 June 2016 19:16
Hi
Today has been a good day. Got outside, did stuff with the family, and got a chance to work on the Gryphon schematic and PCB.

Here is an updated KiCAD EDA file set to include and updated schematic and initial PCB layout. Doing the PCB layout was highly educational and I discovered numerous errors in the part footprints and in my schematic as well.

Regarding the CPLDs; since we are going down the programmable logic path anyway I have a suggestion. Rather than consolidate the 7 PALs into one CPLD how about focus on eliminating the 13 74LSxxx glue logic chips instead? If you look at the board, there are a whole bunch of miscellaneous logic chips in the center left of the board which are going to be a pain for trace routing. If you want to save PCB space take a look at them first. Maybe two CPLDs to consolidate the PALs and the 7LSxxx glue logic.

Thanks

Andrew Lynch


I would not propose to consolidate them all. I would leave the DRAM glue one alone as we barely got that one to work (the original equations were for a dialect of equations that were not well documented). I would move the chip decodes into the CPLD for sure as well as some of the remap of ROM after the Reset Trampoline. I would also bring the 4 address lines that you discovered that are not used into the CPLD to fully qualify the Chips selects as the original design ignored them so all chip selects mapped into multiple addresses because of this which is not very nice in the end. I would probably include the DSAcks here as well - so we would consolidate 4 GALS into one CPLD. Looks like Coprocessor decode would also go into as well as it mostly address lines that go into it which are already going into the Chip decodes so 5 into 1 and there would be 2 left plus the Interrupt one you don't have - I will have to look at the equations to see if that would would be standalone or consolidated.

Dave
Re: Gryphon 68030 [message #801 is a reply to message #799] Sun, 12 June 2016 18:12 Go to previous messageGo to next message
yoda is currently offline  yoda
Messages: 99
Registered: October 2015
Location: Austin, TX
Member
Andrew B wrote on Sun, 12 June 2016 20:05
I think it's a good practice to keep 1 type of programmable device per board, so I'd go for 2 MAX 7000S or ATF15xx-type CPLDs replacing the PALs and the remaining glue logic chips. (The Atmel parts tend to be cheaper but the software they provide is not as nice, but the 15xx and 7xxx parts are generally compatible see https://www.retrobrewcomputers.org/doku.php?id=builderpages: abingham:cpld-compatibilityWink.

That way a builder only needs 1 type of programmer.

CPLDs in general seem more reliable because you can buy 1 $20-$60 USB programmer and program them on the board with a JTAG header. GALs have several vendors that may or may not work with a given programmer - the Lattice parts and Atmel parts use different programming algorithms for instance and programmer compatibility with the lower-cost programmers and the Atmel parts can be spotty. Also only the Atmel parts are currently in-production which are the harder to program of the two.




Well a builder is going to need an EEPROM programmer as well as a JTAG programmer for the board. Most EEPROM programmers can do GALs as well. So you are going to have 2 programmers once you go down the CPLD path. The Altera USB JTAG is darn cheap (less than 15 dollars) and their software seems to be more robust that say Xilinx so I vote using Altera. The UtSource prices are reasonable and the 6ns versions would probably be ideal as we push the speed. I picked up a bunch as they are 5 dollars each in quantity 10 and they should be able to replace 5 GALs so they are cheaper in the end.

Dave
Re: Gryphon 68030 [message #802 is a reply to message #801] Sun, 12 June 2016 18:30 Go to previous messageGo to next message
Andrew B is currently offline  Andrew B
Messages: 312
Registered: October 2015
Location: Hawthorne, CA
Senior Member
Administrator
Yeah, my TOP853 programmer does great on EEPROMs serial and parallel and GAL/ATF16 parts, but won't work on GAL/ATF22 parts. Every time new people do a board with GALs, it ends in a lengthy discussion of which programmers work and which don't....
Re: Gryphon 68030 [message #803 is a reply to message #802] Sun, 12 June 2016 20:07 Go to previous messageGo to next message
yoda is currently offline  yoda
Messages: 99
Registered: October 2015
Location: Austin, TX
Member
Andrew B wrote on Sun, 12 June 2016 20:30
Yeah, my TOP853 programmer does great on EEPROMs serial and parallel and GAL/ATF16 parts, but won't work on GAL/ATF22 parts. Every time new people do a board with GALs, it ends in a lengthy discussion of which programmers work and which don't....


I tend to stay away from the Atmel part because I too have had difficulty. I make sure that I always get Lattice ones - never had problems with them - I keep a healthy stock of 16V8's and 22V10's - pick them up every so often on eBay.
Re: Gryphon 68030 [message #805 is a reply to message #761] Mon, 13 June 2016 03:22 Go to previous messageGo to next message
lynchaj is currently offline  lynchaj
Messages: 365
Registered: June 2016
Senior Member
Hi, yes regarding the video chip that was an area I had compromise on because the SMT chip carrier/daughter board part is not available in KiCAD. So I am assuming it will mount directly on the PCB.

Where was the problem with the video chip on the original Gryphon? I think you mentioned it was rotated 90 degrees or something like that. Was the footprint for the daughter board wrong?

I'd like to see if the video chip idea works.

Thanks

Andrew Lynch
Re: Gryphon 68030 [message #807 is a reply to message #789] Mon, 13 June 2016 04:58 Go to previous messageGo to next message
lynchaj is currently offline  lynchaj
Messages: 365
Registered: June 2016
Senior Member
yoda wrote on Sun, 12 June 2016 10:26
Hi Andrew

I have downloaded the schematics and will start to take a look at them - probably will take a week or so. I need to compare to all my errata notes as well that did not make 1.1 of schematics. Quick perusal I can say there are changes in the IDE area as the '139 area needs updated and the connector on video should be a VGA connector instead of a DB15 connector. Also I think most would prefer the Serial I/O come out on the board to headers that a TTL to USB adapter would accept. For the cost of the Max 232, caps and db9 the dongles tend to be cheaper and work better with modern PCs.


Hi
OK. I can roll in the changes for the IDE no problem. The VGA connector is an HD-15 on the PCB although the schematic indicates a DB15. The pin connections are identical other than the arrangement so it shouldn't be a problem. Adding serial headers (5 pin SIL, if I recall correctly) is no problem. Just leave the caps, MAX232, and serial ports unpopulated if you prefer those serial header to USB cables. Laying out the PCB gave me a lot of insight and resulted in numerous corrections to the schematic and part footprint selections.

Andrew Lynch
Re: Gryphon 68030 [message #809 is a reply to message #805] Mon, 13 June 2016 08:04 Go to previous messageGo to next message
yoda is currently offline  yoda
Messages: 99
Registered: October 2015
Location: Austin, TX
Member
lynchaj wrote on Mon, 13 June 2016 05:22
Hi, yes regarding the video chip that was an area I had compromise on because the SMT chip carrier/daughter board part is not available in KiCAD. So I am assuming it will mount directly on the PCB.

Where was the problem with the video chip on the original Gryphon? I think you mentioned it was rotated 90 degrees or something like that. Was the footprint for the daughter board wrong?

I'd like to see if the video chip idea works.

Thanks

Andrew Lynch


Hi Andrew

Not sure what you are saying here but please do not put the chip directly on the board. The adapter board is simple and you should be able to make the part easily in KiCad. It is just 2 inches square with 32 pin dual male headers on each side. The even pins went on the outside and odd on the inside if I remember correctly. It should be easy to do in KiCad - the tedious part is putting the pin labels on. I will take a shot at it if you want. The way Gryphon was done was the dynamic ram for the video was place on the board (this is very easy to solder) and the 3 resistor that attached to the video ram and then the 2 inch square around it had female headers to accept the adapter board so the video memory was underneath the video board. This chip is just too hard for the hobbyist to solder directly on the board. If not done right it will cause all kinds of shorts and the rest of the board will not be able to be debugged. The ethernet chip is hard enough and it has an easier footprint - I would even suggest doing the same for it if possible. I know Paul was unsuccessful on first board soldering the ethernet and severely damaged that board.

I will send you some photos tonight and we can see if we can make it work. Look at http://www.proto-advantage.com/store/product_info.php?produc ts_id=2600011 for reference. They will order the chip from Digikey and attach it to the board for a small fee for those that don't feel comfortable soldering it themselves. I have one from them already, though I don't know if I fried the chip because Paul's original footprint had rotated and mirrored the signals if I remember right.

Dave
Re: Gryphon 68030 [message #810 is a reply to message #809] Mon, 13 June 2016 09:17 Go to previous messageGo to next message
lynchaj is currently offline  lynchaj
Messages: 365
Registered: June 2016
Senior Member
Hi
I don't mind what video chip foot print we use. However if I need to construct a custom footprint I need detailed technical data.

I think the adapter we have to use is this one for LQFP 14mmX14mm and 0.4mm pitch to PGA-128

http://www.proto-advantage.com/store/product_info.php?produc ts_id=2600014

If it is a straight up PGA-128 it should be an easy swap since that footprint is a JEDEC (?Wink standard part.

However it does not look like a standard PGA-128 to me. I think the MC68030 uses a PGA-128 also but doesn't look like that footprint.

I'll make the swap tonight.

Thanks

Andrew Lynch
Re: Gryphon 68030 [message #812 is a reply to message #810] Mon, 13 June 2016 09:39 Go to previous messageGo to next message
yoda is currently offline  yoda
Messages: 99
Registered: October 2015
Location: Austin, TX
Member
lynchaj wrote on Mon, 13 June 2016 11:17
Hi
I don't mind what video chip foot print we use. However if I need to construct a custom footprint I need detailed technical data.

I think the adapter we have to use is this one for LQFP 14mmX14mm and 0.4mm pitch to PGA-128

http://www.proto-advantage.com/store/product_info.php?produc ts_id=2600014

If it is a straight up PGA-128 it should be an easy swap since that footprint is a JEDEC (?Wink standard part.

However it does not look like a standard PGA-128 to me. I think the MC68030 uses a PGA-128 also but doesn't look like that footprint.

I'll make the swap tonight.

Thanks

Andrew Lynch



Hi Andrew!

My bad. I did not look carefully this morning when I got up - it is the 14mm x 14mm version 0.4mm pitch - I picked the wrong one whey I looked it up. PGA is a misnomer here - it is what they call anything that has pins on all sides here vs DIP when it only has pins on 2 sides. It is 4 dual rows of header pins on 0.1in centers i.e. think of 16 x 2 headers arranged in a square such that the square is 2 inches on a side. I think the image makes it pretty clear - I just need to check at home whether pin 1 is on inside row or outside row.

index.php?t=getfile&id=104&private=0
  • Attachment: PA0190_2.jpg
    (Size: 33.94KB, Downloaded 741 times)
Re: Gryphon 68030 [message #813 is a reply to message #812] Mon, 13 June 2016 09:59 Go to previous messageGo to previous message
Andrew B is currently offline  Andrew B
Messages: 312
Registered: October 2015
Location: Hawthorne, CA
Senior Member
Administrator
One of my projects that I have never finished is a small reflow oven using a toaster/convection oven. I have the Arduino-based controller all assembled that will "self leran" how to follow the actual industry standard reflow profile. I just need to buy the right oven and tear into it and make some modifications.

If one of us got something like that up and running, it would not be difficult to make a few batches of adapter boards with ICs reflowed on them. Certainly less than $20 each.

I have a week off in July, maybe if I don't end up traveling I will work on that during that week.
Previous Topic: SBC-188
Next Topic: My 6809 board: MAXI09


Current Time: Sun May 28 01:22:42 PDT 2017

Total time taken to generate the page: 0.06497 seconds