|
|
|
|
Re: Gryphon 68030 [message #1991 is a reply to message #1983] |
Sat, 11 March 2017 05:56   |
lynchaj
Messages: 1080 Registered: June 2016
|
Senior Member |
|
|
I think the Gryphon plan presented here represents the best path forward. We have a third generation board ready to go which has been shown to work previously. If we need 4 layer PCBs we can get those but at a higher unit price.
The plan has a clear path to a 68K Linux SBC. I don't think this will be easy but it is certainly doable. We need to get people on-board for this approach. I think it represents a system at least as capable as the KISS-68030 and probably more because it doesn't rely on an ECB bus for mass storage. 16 bit IDE can be fairly quick assuming the CPU has enough memory.
[Updated on: Sat, 11 March 2017 05:57] Report message to a moderator
|
|
|
|
|
|
|
Re: Gryphon 68030 [message #1996 is a reply to message #1995] |
Sat, 11 March 2017 13:12   |
lynchaj
Messages: 1080 Registered: June 2016
|
Senior Member |
|
|
Even if you don't want to build one of the prototype boards you can help this project along by buying a prototype board. Either donate it to a someone building it like Ewout or just to offset the cost a bit. The 4 layer PCB is $40 each and if we go with the 2 layer PCB its $20 each.
There are many options available for PCBs each with tradeoffs.
1. 2 layer PCB, ~$100 for 5 prototype boards. Least expensive option but least stable too. Easiest to debug.
2. 4 layer PCB, ~$200 for 5 prototype boards. Internal signal routing (on inner layers). Best grounding, EMI, and thermal performance, more difficult to debug since traces are buried. KiCAD/FreeRouter default approach.
3. 4 layer PCB, ~$200 for 5 prototype boards. External signal routing (on outer layers). Good grounding, EMI, and thermal performance, easier to debug since traces are exposed.
4. 4 layer PCB, ~$200 for 5 prototype boards. Mixed signal routing (on inner and outer layers). Better grounding, EMI, and thermal performance, medium difficulty to debug but fewest vias. Very direct traces.
I am OK with any of the options above. Just let me know your preferences. By default, KiCAD/FreeRouter goes with #2 since it produces the cleanest and best grounding, EMI, and thermal performance. Appearances are really nice but you can't manually follow the traces. However the KiCAD tracing diagram is available so you know where they are and all the signals *eventually* surface due to connections to the components. Being nearly 100% through-hole construction you at least have some access.
[Updated on: Sat, 11 March 2017 13:15] Report message to a moderator
|
|
|
|
|
Re: Gryphon 68030 [message #2000 is a reply to message #1998] |
Sun, 12 March 2017 05:21   |
lynchaj
Messages: 1080 Registered: June 2016
|
Senior Member |
|
|
OK, I am assuming people want the 4 layer PCB with all traces on external layers (VCC & GND planes internally). That seems to be the only preference expressed so far. If anyone has different opinion or questions please speak up. That means the 5 prototype PCBs cost $40 each.
If you'd like to buy a prototype board (regardless of whether you intend to build or not although I certainly welcome it) please send me a PM and I'll set you up. I'll set any funds aside until the order is made. If you change your mind I will refund your money.
It will take about 2 weeks for the PCB trace route optimization to complete. Once the PCB checks out, I'll order it assuming everything works out. Otherwise I'll refund your money.
[Updated on: Sun, 12 March 2017 05:21] Report message to a moderator
|
|
|
|
|
Re: Gryphon 68030 [message #2005 is a reply to message #2003] |
Sun, 12 March 2017 14:14   |
mikemac
Messages: 250 Registered: March 2017
|
Senior Member |
|
|
Both the Gryphon and the Jackalope designs use a 8bit data bus to the Ethernet controller while the video gets a 16bit data bus. Can anyone explain why the Ethernet doesn't also use a 16bit data bus? Just curious.
Mike
|
|
|
|
Re: Gryphon 68030 [message #2007 is a reply to message #2006] |
Sun, 12 March 2017 17:40   |
mikemac
Messages: 250 Registered: March 2017
|
Senior Member |
|
|
lynchaj wrote on Sun, 12 March 2017 14:34mikemac wrote on Sun, 12 March 2017 14:14Both the Gryphon and the Jackalope designs use a 8bit data bus to the Ethernet controller while the video gets a 16bit data bus. Can anyone explain why the Ethernet doesn't also use a 16bit data bus? Just curious.
I think it was off-the-shelf parts the original designer (Paul Fincato) selected. I think the over-riding criteria was working with the 68030 which is not very common for IO components.
OK, I grabbed a couple different versions of the datasheet. It looks like we're trying to run the RTL8019AS in 8bit ISA mode. But it's not entirely clear to me. As they say, the datasheet is "clear as mud".
So, does the Ethernet work with the CS fix? Does the driver work?
Guess I'd better grab all of the Gryphon software I can find and see what's there. And reread this whole thread again so I don't keep asking questions that were answered before.
Mike
|
|
|
Re: Gryphon 68030 [message #2008 is a reply to message #2007] |
Mon, 13 March 2017 02:55   |
lynchaj
Messages: 1080 Registered: June 2016
|
Senior Member |
|
|
mikemac wrote on Sun, 12 March 2017 17:40
OK, I grabbed a couple different versions of the datasheet. It looks like we're trying to run the RTL8019AS in 8bit ISA mode. But it's not entirely clear to me. As they say, the datasheet is "clear as mud".
So, does the Ethernet work with the CS fix? Does the driver work?
Guess I'd better grab all of the Gryphon software I can find and see what's there. And reread this whole thread again so I don't keep asking questions that were answered before.
Hi
The Ethernet and video represent the frontier of build and test of the Gryphon. Both had serious problems during in the original Gryphon board which were corrected in Xagdin. However Xagdin had some redesign and translation to KiCAD resulting different problems. I think Jackalope resolves those problems and we can finally get down to build and test of the complete package.
Tobster has a 68K Linux running on his 68030 home brew computer with apparently only 16MB DRAM. This gives me hope that we could port a minimal Linux to the Jackalope board as part of build and test. That would help open the doors to a lot more people participating.
[Updated on: Mon, 13 March 2017 03:01] Report message to a moderator
|
|
|
Re: Gryphon 68030 [message #2009 is a reply to message #2008] |
Mon, 13 March 2017 05:43   |
lynchaj
Messages: 1080 Registered: June 2016
|
Senior Member |
|
|
One of the goals for Jackalope build and test is to thoroughly ring out the Ethernet and Video sections. We have a pretty good idea that the serial, parallel, and IDE are working. Ideally the full console (video, keyboard/mouse, audio, + RTC) can work together so the machine can be standalone.
I wouldn't want to compile a Linux kernel on it but some software development/testing should be possible.
Also Jackalope supports ATX case and power supply so it doesn't require a host PC or a bunch of bare PCBs on the workbench.
If we can get the full thing working and a minimal Linux ported (Tobster's or KISS-68030 as a starting point), I see good things for Gryphon.
[Updated on: Mon, 13 March 2017 05:46] Report message to a moderator
|
|
|
|
|
Re: Gryphon 68030 [message #2022 is a reply to message #761] |
Wed, 15 March 2017 13:08   |
 |
tobster
Messages: 11 Registered: June 2016 Location: Denmark
|
Junior Member |
|
|
Hi all
I have been terribly busy the last months (baby boy now 8 months old and we have moved from our appartment to an old house), but I have been following the latest activity in this thread with great interest.
I would love to build and test the Jackalope board, but I simply don't have the time at the moment. I hope other builders will join the project. Let it be known that it is a very rewarding experience to see Linux succesfully boot on a homebrew 68K board 
If the CPLD based DRAM controller I have created for my T030 project can be of any use it would be great. And if others could help improve it, even better. In it's present form the DRAM controller does CAS before RAS refresh and basic read/writes with asynchronous DSACK generation. On the T030 I never got on to use the STERM signal. Burst mode access and DMA is not supported.
On the hardware side, I'd like to chime in on what others have also pointed out: fat wires/traces for VCC and GND for the SIMMs and plenty of electrolytic decoupling capacitors are mandatory. I seem to experience the same as John has described, if the T030 board has been switched off for some time it needs to "warm up" before the DRAM is stable. I guess the electrolytic capacitors need to be energized for some time before they reach stable operation. Leaving the system running I have managed to get more than 100 days uptime with Linux (until the ENC28J60 ethernet module died).
Let me know if I can be of any help to get Linux running on the Gryphon once the hardware is ready, even though I'm still a kernel newbee. That I got Linux running on my board, I mostly owe to Will's work with the KISS-68030.
Btw, I am VERY interested in the Alderaan project. The 68040/68360 combo looks really nice. I will definately want to build such a board when I get the time. Just looked at the 68360 documentation, whoa, it's not for the faint of heart...
Regards,
Tobias
|
|
|
|
|
Re: Gryphon 68030 [message #2053 is a reply to message #2032] |
Tue, 21 March 2017 09:55   |
mikemac
Messages: 250 Registered: March 2017
|
Senior Member |
|
|
I have 2 68K questions not strictly related to Gryphon that i hope someone can answer:
1) I've read that the 68K takes minimum of 4 clock cycles for memory access. If the ROM/SRAM on the board has an access time roughly equal to the clock period, is there ever any reason to delay DTACK? Slow I/O devices may need some delays but fast ROM/SRAM should be ready long before the 68K is. Am I missing something?
2) For 8 bit I/O devices, there seems to be a wide variety of ways the 8 bit I/O devices is connected to the data lines. A lot of them seem to use the upper most byte on the data bus. The TS2 puts one 6850 on the high byte and the other 6850 on the low byte. Why do most people use the high data bus byte for accessing 8 bit devices?
Mike
Mike
|
|
|
Re: Gryphon 68030 [message #2054 is a reply to message #2053] |
Tue, 21 March 2017 10:22   |
norwestrzh
Messages: 196 Registered: November 2015
|
Senior Member |
|
|
1) I've read that the 68K takes minimum of 4 clock cycles for memory access. If the ROM/SRAM on the board has an access time roughly equal to the clock period, is there ever any reason to delay DTACK? Slow I/O devices may need some delays but fast ROM/SRAM should be ready long before the 68K is. Am I missing something?
If you can find a copy of the Wilcox 68000 book, take a look at Figs. 7.12 and 7.16. The address bus isn't stable until the middle, or end, of the first clock cycle, and the address strobes (used for most memory access) aren't stable until the middle of the second clock cycle. The decision to assert DTACK* has to be made before the middle of the third clock cycle. So there is really only one clock cycle for data access.
2) For 8 bit I/O devices, there seems to be a wide variety of ways the 8 bit I/O devices is connected to the data lines. A lot of them seem to use the upper most byte on the data bus. The TS2 puts one 6850 on the high byte and the other 6850 on the low byte. Why do most people use the high data bus byte for accessing 8 bit devices?
I don't think there is any actual technical reason to choose the high or low data byte for 8-bit access. Maybe just convenience? One would require using even addresses, the other, odd addresses (for the 8-bit device). MOVEP can be used for 8-bit devices, and I don't believe there is any advantage for either even or odd addresses.
Roger
|
|
|
|
|
|
|
Re: Gryphon 68030 [message #2095 is a reply to message #2083] |
Sat, 25 March 2017 16:19   |
mikemac
Messages: 250 Registered: March 2017
|
Senior Member |
|
|
That's got to be a punch in the gut, after all that work and waiting. Hopefully it's come out right this time. Good luck!
Do any of the 68K designs have a periodic interrupt aka jiffies? I'm used to seeing a 100Hz timer to run the scheduler off of.
Mike
|
|
|
|
|
|
|
|
|
|
|