I pulled the plug and bought a MC68HC000. Help. - Page 1
Forum section: electronics / general

author: technix
author_rank: Super Contributor
timestamp: November 22, 2016, 12:30:11 pm
content: I visited the vendor who sold NOS parts today, and she got one last MC68HC000 remaining. She offered it to me for $3.2 (last time it was $9) and I bought it. Now what can I do with it? How can I find RAM and other peripherals to go with it?Here is the mark on the chip:Code:(M)MC68HC000P102E60RDJQFJ9513Can it run at 20MHz as specified in the manual, or can it only run at up to 10MHz?

author: Ampera
author_rank: Super Contributor
timestamp: November 23, 2016, 06:56:42 am
content: Of course, always consult the datasheet,http://pdf.datasheetcatalog.com/datasheet/motorola/MC68HC000.pdfYes you can clock it to 20Mhz, you could probably even do more, depending on how well one cools it, how clean the power is, and other factors. Don't expect to triple the speed, but Overclocking is technically possible.Wiring up processors into your own computer is not an easy task, and I have stayed up many many many night dreaming up an awesome 4 CPU 68k machine. I love these things, and I think they are in many way superior to 8086/8088 CPUs of the time.Man, my concept was to build a 4 CPU machine, but not specifically for multi threaded operations, but to split their functions across many uses.CPU 1 was gonna be program code only, a chip you could rely on for 100% availability, and not need to do anything with it.CPU 2 was the Aux processor, used for second thread computing, and for I/O workCPU 3 was the Primary graphics computer, used mainly for simple graphics work like 2D stuff, with built in code through some form of abstraction layer to allow easy function of the graphics systemCPU 4 was the Aux graphics computer, useful for dual threaded graphics work, so that in tandem they could do more complicated graphics work, like one chip could run vector calculations for 3D visuals, theprimary chip could pull 2D work, or they could double team on either or whatever.You can see why this never left the conceptual phases, but it was a dream that one day with enough training and research I could do.Start small, as I said this isn't gonna be your plug memory into board, but with more wires and a handful of passives, this is confusing even to me. Depending on your skill level (Probably better than mine, not hard to to) you may even want to look at schematics for other 68k machines, like the Macintosh line, Amiga line, ST line, Genesis, etc. etc. There really is no shortage of example work here, the 68k was the prime competition to the 80x86 powerhouse until they moved onto PPC and ultimately folded as history tells.Ben Heckendorn (Element14 Ben Heck show on YT) has done stuff like this, for example his Apple 1 from chips construction.Honestly the easiest part will be the programming, 68k remains TO THIS DAY, the BEST ASM language I have ever seen. You have 8 registers, 32 bits, address and data (Although I think address was limited to 16 bit externally, could have even been 16 internally, not sure) and a set of commands easy to follow, it's the reason why I maintain CISC programming is FAR superior to RISC. Check out MarkeyJester's tutorials, they are not complete, but they are easy enough to follow, and they will ultimately give you enough understanding to find stuff on your own.Again, not sure how skilled you are, I could be digging a hole with a thimble here, but this is the base stuff you need to know.

author: AlfBaz
author_rank: Super Contributor
timestamp: November 23, 2016, 09:13:22 am
content: Quote from: technix on November 22, 2016, 12:30:11 pmHave a look into the old Amiga A500. This was what they used

author: technix
author_rank: Super Contributor
timestamp: November 23, 2016, 09:51:37 am
content: Quote from: TwoOfFive on November 23, 2016, 06:56:42 amI have this feature set in mind:* VGA or HDMI video output* SDXC card for bulk storage* USB Full Speed host controller (keyboard & mouse)* Fast Ethernet* Runs LinuxThere are USB Full Speed controller and Fast Ethernet controllers based on the 16-bit Intel ISA architecture. I need to design a bus bridge to interface those ISA hardware with m68k. For the graphics and bulk storage, I am thinking about building my own. Graphics can be done using high speed counters and dual port RAM. SDXC can probably be implemented in a microcontroller.I do have a CS background and getting a m68k cross compiling toolchain up takes no time to me. A few line of ASM to set up a stack and the remainder is all C, to initialize DRAM, relocate the startup code, load the Linux kernel from SD card and run it.

author: nfmax
author_rank: Super Contributor
timestamp: November 23, 2016, 09:59:27 am
content: Beware - if you are thinking of running stock Linux. The 68000 cannot support virtual memory without additional hardware*, as an instruction which encounters a bus fault part way through its execution cannot be restarted. So if the memory addressed needs to be loaded from disk, something else must do it, while the 68000 can only sit there waiting for DTACK...*The additional hardware might, of course, be another 68000

author: technix
author_rank: Super Contributor
timestamp: November 23, 2016, 10:23:46 am
content: Quote from: nfmax on November 23, 2016, 09:59:27 amIf another processor is required, I would prefer using a PIC16 for this. I think that the modern Linux kernel have workarounds for this?

author: Ampera
author_rank: Super Contributor
timestamp: November 23, 2016, 10:44:19 am
content: Quote from: technix on November 23, 2016, 10:23:46 amI think you're getting ahead of yourself. ISA is not something you can just port, it has for it's entire lifespan been x86 only, and nobody I know of has ever ported it to ANYTHING. ISA has specific memory requirements, and really needs an x86 to run well.You're also asking too much out of this poor 68k, it's not a modern processor, and it can't run all of your modern stuff. Everything you want to do here will have to be programmed, implemented, and debugged on your own.I suggest using some form of ASCII terminal off the data bus, getting 16 or so K of memory working, and get some form of Basic running. As I said, there is a reason I never did anything with the 68k.And I know how you feel too, I was gun-ho about building my machine, thinking it was gonna be so cool, but if you're in the position of asking people here, you don't know enough to do something like port ISA over.Start with more period accurate technology, I don't mean source exact parts, but instead of HDMI out, run with an ASCII terminal and then go for a composite video generator. HDMI is hard to do, and WILL require more than a PIC16. "Fast" ethernet is practically impossible. You have to understand that your understanding of "Fast" is not the 68k's understanding of fast. Take your 68k, it can clock at 20 Mhz. That's your effective FSB speed, you of course don't have a memory controller, but you literally have nothing faster than 20Mhz. That is slower than VESA Local Bus. USB is pointless since you don't have drivers for anything useful anyways, try an AT or PS/2 style keyboard.All this sorta awesome stuff is really something for a more modern chip. You can of course buy a newer 68k, but once you get into anything higher than basic handmade computing, you really need a team at that point.For the TL;DR version, start by learning how to address memory, then move up to designing your first board with a basic ASCII terminal interface that can send and receive bytes of information. The next step is to program some sort of PROM (EPROM or EEPROM will be fine as long as it's non-volatile) and program a simple interface in 68k ASM to echo characters received out again. At that point you should know enough to carry on.It's not as simple as wiring parts together and plopping some programming down, I mean we are talking the predecessor to real motherboard design, and if you've ever seen traces on a motherboard, even without understanding what they exactly do, you will understand the sheer weight of all the connections, all the places to go wrong, and all the stuff you need more than one person to do.

author: nctnico
author_rank: Super Contributor
timestamp: November 23, 2016, 11:14:29 am
content: Quote from: technix on November 23, 2016, 10:23:46 amNo there is no way around it. To run Linux you need a processor with virtual memory support which puts each task into it's own memory space. You could give uClinux a try but one of the reasons the 68k Apple computers where so notoriously unstable was the lack of virtual memory support.

author: nfmax
author_rank: Super Contributor
timestamp: November 23, 2016, 11:30:01 am
content: Of course, a sufficiently old Unix can be run without virtual memory, using (process-based) swapping instead, or just putting up with a 16MB memory size limit. But you still need an MMU of some sort. IIRC the 68010 chip design allowed instructions to be restarted. My first introduction to UNIX was on a 68010-based PCS Cadmus system, which supported a dozen or so terminal-based users running under SVR2 on 2MB memory, with virtual memory. It ran rogue just fine. Happy days!You might look at OS/9 68k as an alternative. A much-underrated OS which we used successfully in embedded applications for many years. Still a few machines out there chugging gently along.

author: technix
author_rank: Super Contributor
timestamp: November 23, 2016, 12:59:31 pm
content: Quote from: TwoOfFive on November 23, 2016, 10:44:19 amPeriod-accurate technology won't work for me as I don't have any period-correct peripheral - no PS/2-compatible keyboard, and no display with any form of analog input except VGA. Either I have to get the modern hardware to work, or I cannot do it.What I mean by "Fast Ethernet" is 100BASE-TX. The Ethernet chipset I have in mind is similar to the W5100 used in Arduino boards, but this one comes with 68000-compatible bus interface, so it can sit right in the FSB. The USB host is a similar scenario. The same chip manufacturer also have a USB host chip that is 68000-compatible, so it too can join the front side bus.Linux requires some external hardware to implement the virtual memory system. The required external hardware can be implemented in the PIC16 - that is where this PIC16 is coming into play. It also functions as an fully independent DRAM controller, so the full 10MB of DRAM is ready to go when the CPU is up.As of the display and audio output, I would start with a HD44780-based ASCII display, also sitting in the FSB directly. The HDMI interface I have in mind consists of 5MB of dual-port RAM - 4MB framebuffer and 1MB of audio sample buffer. The HDMI controller is also independent of the main processor, and it just pulls the pixels and audio samples out of the VRAM and audio buffer RAM and send it over HDMI.

author: Ampera
author_rank: Super Contributor
timestamp: November 23, 2016, 05:57:34 pm
content: Quote from: technix on November 23, 2016, 12:59:31 pmSo if you know all this why are you asking any of us? It seems your sorted...

author: technix
author_rank: Super Contributor
timestamp: November 23, 2016, 07:51:00 pm
content: * 4x IS61C25616AL = 2MB SRAM. OK.* 2x FM18W08 = 64kB NVRAM for bootloader and system configuration. OK.* WCH CH395 = Ethernet interface in FSB, with built-in TCP/IP stack. OK.* WCH CH375 = USB OTG controller with special support for USB MSC in FSB. OK.* Both KS0108 and HD44780 can sit in the FSB too. Which display to use then?* PIC16F877 can join FSB as a slave too... OK then.* Now where are those 5V DRAM chips that can be clocked using PIC16F877? I need 8MB DRAM.And can EPM7000 work with USB Blaster? If so I would use that as my PCH. Also can I run part of the FSB (especially RAM) in 3.3V or lower? If so there are 4MB SRAM so I won't have to run DRAM at all.

author: janoc
author_rank: Super Contributor
timestamp: November 23, 2016, 10:06:10 pm
content: Quote from: nctnico on November 23, 2016, 11:14:29 amIf you don't want to spring for a newer variant of the 68k (the later ones had proper MMU), there is always the hack that has been used to run Unix on the original 68k - connect two of them running the same code in parallel, but with clock shifted by some amount (few cycles). If the CPU running ahead hit an exception, the other one took over and recovered from it (because it has never hit it). The crashed CPU was then reloaded and restarted again so that both were back in sync.It is a crazy kludge, but I believe some early Unix workstations were using it.

author: technix
author_rank: Super Contributor
timestamp: November 24, 2016, 02:48:13 am
content: Quote from: janoc on November 23, 2016, 10:06:10 pmIs it possible to let a PIC16F877 to sit in the FSB and catch the fault that way? When the crash happened the PIC try to recover it.

author: Richard Crowley
author_rank: Super Contributor
timestamp: November 24, 2016, 03:29:27 am
content: We seem to have forgotten what these phrases mean...."Pull the trigger" -- To take decisive action with no certainty of the outcome"Pull the plug" -- To put an end to someone's activities or plans.Ref:http://www.urbandictionary.com/

author: technix
author_rank: Super Contributor
timestamp: November 24, 2016, 07:55:29 am
content: Wait. Are you guys sure that the CMOS version MC68HC000 have the same MMU bug as the HMOS version MC68000?

author: technix
author_rank: Super Contributor
timestamp: November 24, 2016, 07:57:27 am
content: Quote from: janoc on November 23, 2016, 10:06:10 pmDidn't the CMOS 68HC000 implement the proper MMU?

author: TiN
author_rank: Super Contributor
timestamp: November 24, 2016, 08:01:42 am
content: If I'd be tinkering about 68000, I'd rather focus on reversing and writing software for already existing hardware, such as many HP/Tektronix/Keithley instruments which use 68000-series processors. If one to find the way to modify firmwares of these old but still capable instruments, that can benefit the community by a LOT. E.g. add support for more memory storage, extra features, more common serial-to-USB interface (many old instruments have GPIB only, which is pricey).Making 68000 system for sake of making bound to run out of juice at first PCB revision, so it's a almost surely a dead end from the start.

author: nfmax
author_rank: Super Contributor
timestamp: November 24, 2016, 09:04:27 am
content: Quote from: technix on November 24, 2016, 07:57:27 amNo.The 'HC000 was just a CMOS version of the original '000. Neither was able to restart instructions in the event of a bus error. The '010 introduced restartable instructions, and a couple of other minor changes to improve multiprocessing. the '020 introduced full 32-bit data & address buses, and a full 32-bit ALU (previously the ALU's were 16 bits, and so took two clock cycles for a 32-bit operation).It wasn't until the '030 that an on-chip MMU appeared. Before that, you had to use a additional 68451 or 68851 MMU chip in conjunction with the CPU.The Wikipedia article on the series explains all this & more:https://en.wikipedia.org/wiki/Motorola_68000_series

author: janoc
author_rank: Super Contributor
timestamp: November 24, 2016, 09:43:25 am
content: Quote from: technix on November 24, 2016, 02:48:13 amWell, everything is possible, but do you really want to spend time developing this? That PIC may be too slow for this, even the early MC68000 can run at 10MHz. The PIC would need to monitor the bus transactions in real time and the old 8bit PICs are not exactly known to be speed demons.It is not really a crash. What happens is that the CPU executes an exception handler but then there isn't a way to restore the state (registers, flags, etc.) so that the code execution can resume. That's why the kludge with the two CPUs running the same code was used - if this happened, the state could have been restored from the second CPU that didn't hit the exception yet.It is pretty much the same issue like the protected mode on Intel 286 CPUs - there was no way to get out of this mode once activated without a full reset, so nothing was using it. Only after the 386 allowed to go back to real mode (and thus DOS), it started to be used for things like extended memory managers and later memory protection in OS/2 or Unix/Linux.If you really want to build a Unix-capable computer with a 68k CPU, then get 68030 or higher which are compatible and have the MMU on board. Just beware of the low cost EC versions that don't have it.

author: nfmax
author_rank: Super Contributor
timestamp: November 24, 2016, 10:01:45 am
content: Quote from: janoc on November 24, 2016, 09:43:25 amThat's not quite how I remember it. IIRC, if the 'main' 68000 tried to access a memory address into a non mapped page, it would simply be held indefinitely waiting for DTACK to go low (by the MMU/bus logic). Meanwhile, the 'helper' 68000 would be alerted, by this same hardware, to go about its business loading the required page and updating the MMU appropriately. Then when all was ready, it allowed the 'main' CPU DTACK tofinallygo low and the 'main' CPU would continue on its merry way.There was a Motorola application note about this. I may even have a copy somewhere...

author: technix
author_rank: Super Contributor
timestamp: November 24, 2016, 12:39:21 pm
content: Quote from: janoc on November 24, 2016, 09:43:25 amI have already put the Linux plan to a future 68030 system (68030, 68882, FPGA for DRAM controller driving a few sticks of DDR2-800s that I have sitting around.)This 68000 project is pretty modernized, with 15MB of memory (SRAM, maybe some DRAM,) 512kB NVRAM for boot code (using FRAM technology,) SDXC card, Ethernet, USB Host, USB OTG and a KS0108-based LCD on the bus. It runs code I will have to write myself.

author: Ampera
author_rank: Super Contributor
timestamp: November 24, 2016, 05:17:59 pm
content: Quote from: technix on November 24, 2016, 12:39:21 pmThen modernize the bloody 68030. The 68k is not designed for modern applications, and is an almost strictly legacy processor. Every single thing you do, including USB, Ethernet, And ISA translations, and trying to run Linux especially, will almost entirely be on your own. Do something else, if you want a modern computer, make a modern computer with a modern processor, if you want a 68k machine, make an ACTUAL 68k machine. Sorry to stop on your ideas, but there is a reason nobody has really tried to do most of this before. And an ISA hardware port has never been done before in my FOV.I have never gone to school for computer engineering, or any engineering of any type, most of what I learn is through osmosis by sticking around here and other youtube spaces, but even I can tell with most of my experience coming from the 68k line, this is not something a 20Mhz max CPU can do. When was the last time you had a 20Mhz machine run Linux? That's mid range 286 territory. I would love to build a machine as you aspire, but I stopped before I began. Fun project, but a lot of work, and it REALLY needs more period accurate (1980-1990) circuitry to run.There's also the principle of the thing. If you just start offloading everything on other chips, why the hell do you have a 68k there?Sorry for being brutally honest, it's a German trait, but a 68k doesn't want to do that, and forcing it to will not be fun.

author: janoc
author_rank: Super Contributor
timestamp: November 24, 2016, 05:23:05 pm
content: Quote from: nfmax on November 24, 2016, 10:01:45 amThe whole point of that hack was that it permitted to runwithout the MMU(which hasn't been even available when MC68k was originally released - it came out only later and instructions could have been restarted only with 68010 and upwards). The hardware that used this dual CPU hack was Apollo DN100 (the workstation, nothing to do with the Moon):http://wikivisually.com/wiki/Apollo_Computer/wiki_ph_id_32https://en.wikipedia.org/wiki/Apollo/DomainOtherwise what you are describing is well possibly correct, it has been a long time since I have seen the description of that setup.Atari ST used another approach as well:http://www.dadhacker.com/blog/?p=1383Sun used the original MC68000 in their Sun-1 workstations, but they have designed their own MMU for it:https://en.wikipedia.org/wiki/Sun-1

author: C
author_rank: Super Contributor
timestamp: November 24, 2016, 05:25:13 pm
content: One thing that the 68000 has is the hardware & software to have many CPU's on a bus. If you want this to be a learning experience, then build with this in mind.With Many CPU's, you CPU board ends up needing 3 buses. System bus, on card bus & local expansion bus. The big change here is the need of a signal "I AM Addressed" generated by what is addressed to select which bus to use.As stated, HP used the 68k in some product lines( series 200, series 9000). Back then HP had created it's own Pascal compiler for 68k and many other processors. The software foundation for series 200 was Pascal for the HPL, BASIC & PASCAL systems. Series 9000 used HP Unix for an OS and had a version of the Pascal compiler. Note that this compiler was built with needed extensions to do system programming & allow many programmers to work together on a project.Radio Shack TRS 6000 that ran unix and had a simple memory protection unit. Note that IO was via a powerful Z80 so that the 68k was not slowed down doing IO.The 68010 fixed a lot of problems.The bus fault that created restart instruction problem that you needed to prevent the 68k from seeing The second 68k would use the information from the bus request to fix the problem, It read the bus while the first 68k was in wait mode. The 68010 expanded the error information that was put on stack to gain instruction restart.The 68010 also added basics needed to create a virtual CPU using the hardware CPU. You could run|test a new OS with little or no change using this.If you put all this together, it is a smarter move to build a two+ processor 68k system if you want multi tasking. Done correctly this can also make creating software easer.With all this in mind you also do not need much for IO on 68k as it will be faster and easer to off load all the IO, you just need little more then shared memory & a way to create interrupts to 68k & from 68k other processors.Break out of the box a little. A GUI screen is great, but adds a huge amount of overhead to do. Much easer to have a character based text overlay over a graphics screen. Not quite all the power of a full dot based screen but has a huge reduction in software costs and uses CPU processing speed better. One system I used back then used a separate board for each layer of the graphics displayed. If you think of possibilities, this makes it real easy to have many programs doing graphics at same time with no conflicts. You could even have a 68k per layer doing graphics.Think of the simple hardware to do this. For some memory area you have hardware ram that can function as shadow write memory. The 68k is creating a graphics layer using normal ram. Each write to this ram also gets written into display buffer at same time. Each board has common input signals for display signal timing & outputs to a combiner to turn the layers into color or gray scale.If you add programmable address for shadow write ram location you can switch between what is displayed on a layer. Just need to do a read & write to same location to update display buffer on switch change.This is all just changing mind set from thinking single CPU to thinking many CPUs with little conflict. Common boards used many times.What was a problem for one 68k with memory buss errors becomes a two+ 68k system where both can run programs while handling the memory bus errors of the other.

author: grumpydoc
author_rank: Super Contributor
timestamp: November 24, 2016, 05:40:17 pm
content: Quote from: TwoOfFive on November 24, 2016, 05:17:59 pm+1HoweverQuoteWell, I suspect that Fedora 25 is out of the question but the 68k should be adequate to run uClinux or FUZIX. You do not need demand paging to run a unix-like OS.https://github.com/EtchedPixels/FUZIXhttp://www.bigmessowires.com/2014/11/06/building-uclinux-for-a-68000-target/Doing it all from the bare metal up is going to be a challenge though

author: janoc
author_rank: Super Contributor
timestamp: November 24, 2016, 05:40:46 pm
content: Quote from: TwoOfFive on November 24, 2016, 05:17:59 pmI think you should calm down a bit. Heck, people have built Z80 or 6502 based machines having ethernet, USB and what not. 68k can certainly handle that, given enough "coprocessing" hardware. E.g. if you put a $5 ARM core on an addon-board as some sort of "I/O processor", you can easily have USB, ethernet, serial port and more. Is it going to make a practical computer? Not likely, but I think that wasn't OPs point anyway. If it is about having fun and learning heck lot of stuff in the process, why not?BTW, there is nothing really intrinsic about ISA why that couldn't work with a 68k. That it hasn't been ported/used with any other architecture has more to do with the fact that e.g. MC68k or Alpha or MIPS would be more efficient with its own native bus than trying to shoehorn it into ISA, not because it cannot be done. BTW, I believe that some Alpha based workstations had ISA slots as well (in addition to e.g. PCI), so ISA was certainly not an Intel-only affair.Ground the DTACK pin and the MC68k starts to essentially behave like a 8080/8086 or similar where the peripherals had to be fast enough to manage to reply to the CPU in time instead of sending an explicit handshake signal. A bit of glue logic to translate the control signals would be probably all that would be required to get a classic ISA slot running. I have been actually thinking about doing the same, because I have some old ISA cards and an ISA backplane collecting dust. Writing drivers for the hardware would be another story, though.Re period circuitry - you need that only if you really want to build a machine which is completely period for some reason (e.g. for a museum or simply as a challenge).Otherwise your life would be infinitelly easier if you use modern CPLDs for the glue logic and things like the various custom I/O chips that were common at the time could be easily replaced by a small microcontroller today. Etc. You really don't need a ton of period unobtanium hw to make a machine like this.OTOH, if you have never built a computer yourself, then it is way easier to start with e.g. Z80 or 6502. Less wiring too68k is a bit different league, but certainly within the reach of a hobbyist. Heck, people are reviving 386 and 486ses from eBay on self-built motherboards already!

author: janoc
author_rank: Super Contributor
timestamp: November 24, 2016, 05:45:01 pm
content: Quote from: grumpydoc on November 24, 2016, 05:40:17 pmWell, if he upgrades to 68030, then there are native ports of both Linux and BSDs, given enough RAM (which shouldn't be an issue today).The classic 68k makes a great CP/M machine, though.

author: nctnico
author_rank: Super Contributor
timestamp: November 24, 2016, 05:59:54 pm
content: Building a 486 machines sounds like more fun to me. I think I still have the socket I bought 25 years ago. Nowadays you just plonk a load of SRAM onto the board, use an mSATA to IDE converter and go from there.

author: Ampera
author_rank: Super Contributor
timestamp: November 24, 2016, 06:23:32 pm
content: It's the computer purist in me, I am not demanding getting 80's exact chips, but I am saying do something easier like an ASCII terminal, moving onto a composite output rather than full blown HDMI. And ISA has a lot of specific memory addressing requirements and interrupt settings. It's hard enough to get ISA working on a machine that actually supports it, never mind a platform that never had ISA. PCI would actually make more sense, as it was ported over to the 68k's big brother, POWER, but some form of translation would still be needed due to the less than 33 Mhz effective FSB.If I were to make my own 68k machine here is how I would lay it down, and this is hitting a ball before playing catch.4 CPUs, 2 Graphical, 2 Logical.The first two would be effectively dual threads that communicate by sharing memory addressing. Thus a program on core 1 (A 100% free core) could offload tasks to other processors sharing the same memory.The idea is they can all access the same memory, but their real personal memory is split apart, and writing to other memory is reserved for inter-core communication.For expansion, a proprietary 16 bit expansion system, could even use an ISA connector, but with different pin arrangement.Video would be an RGB system, or possibly Component video.Yea, this is what my problem is. I keep coming up with loads of cool shit, and no plan on how the bugger to implement it. As I said, never went to school for this stuff yet. can dream tho.This is where I speak from when I say don't do stuff like what you want, you will dream for a week, and forget about it and say "It really wasn't that much for the 68k, oh well."Quote from: nctnico on November 24, 2016, 05:59:54 pmAgain, computer purism is like an alternate form of OCD for me, I get annoyed when it's out of place. I built a 486 (Going to make a video for those waiting, AWE32's in the mail.) with a DX4-100 @ 120mhza Diamond Multimedia Stealth SE VL Bus graphics card (2MB upgraded from 1), a DTC dual channel IDE/Floppy/RS-232/Parallel/Gameport MIO card, a 2GB WD Caviar, and a true AT power supply. It even has 32 MB of memory, cached @ 256k.This is my preffered way to 486, don't throw mSATA, and trust me you would be wasting every single extra GB over 2, heck, probably over 512 depending on BIOS, on a SATA solution. Use Compact Flash with a converter if you insist on solid state storage.Again, feel free to do what you want, but once you start adding modern technology to older technology, there is no reason to use the older tech. Your new shell will only be weighed down by the slow 486 core, and you won't get the neatness of having a true 486.

author: nctnico
author_rank: Super Contributor
timestamp: November 24, 2016, 07:34:27 pm
content: Don't get met started on the AWE32... I still have my one somewhere but unfortunately the software which comes with it only runs well on Windows 98.Still using mSata will at least offer a fast way of storing data and if you run Linux on the system I'm pretty confidend you can use all the storage space anyway.

author: technix
author_rank: Super Contributor
timestamp: November 24, 2016, 07:48:36 pm
content: Quote from: janoc on November 24, 2016, 05:45:01 pmEnough RAM... haha those old DDR2 sticks I am planning to use on 68030 packs 2GB each - so maxed out with 4GB RAM already. And I think that with 4GB RAM Linux would be chugging along very happily.As of the classic 68000, that is going to not run any period-correct operating system, and instead I will write something specific for my purpose.

author: technix
author_rank: Super Contributor
timestamp: November 24, 2016, 08:02:31 pm
content: Quote from: TwoOfFive on November 24, 2016, 06:23:32 pmThat is the purist in you.I must use HDMI or there will not be any kind of video output that I can actually see other than HD44780 or KS0108 or ST7920 style LCD displays. I know very well that the 68k cannot drive HDMI on its own, so the entire HDMI affairs are handed to an independently clocked coprocessor, and all the 68k need to do is to tell it the video mode, audio frame format, and fill it in with contents in a dual-port RAM buffer. The same applies to Ethernet and USB - the Ethernet interface chip is pretty much a parallel bus version of W5100 as found on Arduino Ethernet shields, with built-in PHY, MAC and even TCP/IP stack, so the 68k only need to mind the higher layer stuff; the USB interface chip is similar in this way too - in fact I even have two USB chips of this sort, one USB host, and one USB OTG.In a nutshell, the 68k is only seeing what it can handle, all the complexities of driving a modern interface are fully delegated to a coprocessor of some sorts.

author: Ampera
author_rank: Super Contributor
timestamp: November 25, 2016, 02:31:38 am
content: Quote from: nctnico on November 24, 2016, 07:34:27 pmYou kidding? The AWE32 is legendary. It is the powerhouse card for DOS, and Win9x/NT systems.

author: Ian.M
author_rank: Super Contributor
timestamp: November 25, 2016, 03:11:32 am
content: If you are a non-purist, you'll probably be best served by running your 68000 as a hosted coprocessor similar tohttps://en.wikipedia.org/wiki/Tube_(BBC_Micro)The host provides console I/O and mass storage, and is also responsible for grabbing the bus and stuffing the boot image into RAM at startup.You'll need a FPGA or similar as glue logic + a host - either a PC with a USB link to a reasonably fast USB device capable MCU on your board, preferably with an external memory bus (e.g. PIC18F87J50 if you are determined to stick with a PIC) or a Linux SBC with the interfaces you need - e.g. a Raspberry Pi. The Linux SBC host option will be far far easier to get going because you wont have to wrestle with USB and the SBC can directly access the FPGA on your board.

author: technix
author_rank: Super Contributor
timestamp: November 25, 2016, 01:39:11 pm
content: Quote from: Ian.M on November 25, 2016, 03:11:32 amThat isn't too dissimilar from my current plan, using the WCH CH375 USB OTG to 8-bit parallel interface chip. The 68000 have to initialize the USB interface itself using the boot NVRAM code (I am using FRAM for boot code so that is technically not ROM,) but after that the actual program can be uploaded using USB into the RAM (if the SD card is missing or contain no valid kernel.)Here is the boot sequence:1. POST. (The coprocessor, a PIC16F877, have already initialized DRAM and SD card interface for the 68000)2. Read the SD card, search for valid kernel. If a kernel is found, it is loaded into RAM and jumped into, and boot code ends here.3. Initialize the USB OTG chip in Slave mode, wait for enumeration.4. Download kernel from USB into RAM.5. Deinitialize the USB OTG hardware.6. Jump into the downloaded kernel, and boot code ends here.

author: janoc
author_rank: Super Contributor
timestamp: November 25, 2016, 03:48:43 pm
content: Quote from: technix on November 24, 2016, 07:48:36 pmDDR2 RAM? I wonder what are you planning to use as a memory controller then, considering that no 68k series CPU supported anything else but standard SRAM/DRAM. Also the voltage translation required will be fun, considering the width of the bus and the speeds required. If you are going to stick an FPGA there, you could probably emulate the entire 68k in the FPGA as well already.

author: technix
author_rank: Super Contributor
timestamp: November 25, 2016, 06:14:58 pm
content: Quote from: janoc on November 25, 2016, 03:48:43 pmDDR2 goes to the 68030/68882 machine.

author: janoc
author_rank: Super Contributor
timestamp: November 25, 2016, 07:43:31 pm
content: Quote from: technix on November 25, 2016, 06:14:58 pmSorry, I didn't express myself clearly - I meant that *no* 68k series CPU (including 68030) has support for semi-modern SDRAM and you will need memory controller that will translate the synchronous memory to the asynchronous parallel bus the CPU expects. And also do the voltage level translation - DDR2 is 1.8V affair, vs the 5V CPU. Furthermore, the minimal clock of a DDR2 RAM is 125MHz, it will likely not work reliably (or at all) if you clock it slower ...If you really want to use your DDR2 sticks with this CPU, that will take some serious engineering.

author: Ampera
author_rank: Super Contributor
timestamp: November 25, 2016, 10:22:54 pm
content: Quote from: janoc on November 25, 2016, 07:43:31 pm@OPMan, you really seem to be getting into something you don't understand. It's not that I understand, but I know enough to say that you are trying for too much. Adding a whole load of coprocessors, extra this, extra that, it's not good for what I am going to presume is your first computer. Even if it's not I have to assume little experience due to what you have said and asked, and the fact you are asking people here.Get DRAM, it's practically falling off trees.Use a composite video display. I find it hard to believe you don't have a SINGLE display in your entire house and/or in China that doesn't have the yellow RCA composite lead. It's not rare, people often find themselves not being ABLE to get a non composite display. But to start off with use an ASCII terminal, you can design your own using an [insert favourite SBC here] with little effort using GPIO pins. Heck there probably already exists someone who has done it and is using a preexisting standard. I know you want a nice shiny HDMI display, but it's not gonna happen if you need to ask us how it's gonna happen.Same thing with Ethernet, Linux, and DDR2 SDRAM, it's not gonna happen easily, don't do it until you've made 20 68k machines. Heck, settle at making your own expansion bus and adding it on later, a task that is WAY easier, and gives you a nicer experience.I am telling you, you're hitting the ball before you've leaned to catch (American term, kicking the ball before you've learned to run?) and that's not bad, I am guilty of the EXACT same thing and I have still not learned my lesson (I do it practically every day, and I usually get burnt by that).And the suggestion of using a Z80 or 6502 to start out with is not a bad one. Study schematics, if you have to ask US how to do so, then I sadly have to say you don't know enough to embark on this task, and most of us can't help you over a forum.

author: technix
author_rank: Super Contributor
timestamp: November 26, 2016, 07:15:41 am
content: Quote from: janoc on November 25, 2016, 07:43:31 pmRemember the keyword I have been using for quite a while: coprocessors. The DDR2 are not connected directly to the bus, instead there is an FPGA sitting in between that handles all the bus timing and clocking for the DDR2, and I even will include a soft MCU core to read the SPD data for initialization parameters. To the 68030, this entire block appears like 4GB of SRAM.

author: technix
author_rank: Super Contributor
timestamp: November 26, 2016, 07:42:10 am
content: Quote from: TwoOfFive on November 25, 2016, 10:22:54 pmYou still didn't get the point of coprocessors did you? The 68k is not handling USB or Ethernet or HDMI directly, some modern processor (ASIC for USB and Ethernet, FPGA for HDMI) is. Even Arduino, a 8-bit micro, can handle Ethernet or USB host through a coprocessor, why can't a much more powerful 68k?As of the memory, period-correct DRAM chips or modules are nowhere to be found here. I know that Westerners use China as a E-waste dump site, but parts from those E-waste are melted down instead of being resold.

author: Ampera
author_rank: Super Contributor
timestamp: November 26, 2016, 07:53:06 am
content: Quote from: technix on November 26, 2016, 07:42:10 amAnd if you read what I wrote, I said that it's not impossible, and I never said you can't use co-processors, but the more you add, the harder it gets. You should start with basic computer, not a SBC quality computer right off the bat. If you are able to do that, you would have already done so, and never even made a post here. I am trying to not make you waste your time and money, if you want to build a 68k machine, make a simple SBC that has DRAM (Doesn't have to be period accurate, even 72pin SIMMs will work just fine, just has to be DRAM) an ASCII terminal interface, and a PROM of some sort (E or EE PROM is fine, or you can burn and toss if you really want)Adding more co-processors just increases the amount of stuff to confuse you and go wrong, and I know exactly what it's like. You asked us for help, and if you need help then build a very simple computer, and start experimenting with more stuff after you've gotten a machine that can echo ASCII characters back to screen from a terminal interface. If you can just plop down and start doing a 4 processor system with tons of supporting hardware and complicated SDRAM voltage translation and the works, you don't need help from anybody here, as nobody could contribute anything you didn't already know.Learn to catch before you hit a home run, learn to run before you score a goal, learn to dribble before you shoot a basket, learn to etc... It's a simple case of start small and go up from there, otherwise you have a load of parts, get frustrated, and quit. And if you have full confidence you can manage this, you don't need anything from us, because you know everything you need to know.

author: karoru
author_rank: Regular Contributor
timestamp: November 26, 2016, 08:26:45 am
content: Quote from: technix on November 23, 2016, 12:59:31 pmAhem, you can still easily buy PS/2 keyboards -cheapest ones, for like 5$. Just look at your local shopping mall, sometimes these are even marketed as USB but you'll find PS/2 keyboard & PS/2 to USB adapter in the package;)

author: Ampera
author_rank: Super Contributor
timestamp: November 26, 2016, 08:29:48 am
content: Quote from: karoru on November 26, 2016, 08:26:45 amYou could also use an ASCII terminal, and have the USB host on a SBC.

author: technix
author_rank: Super Contributor
timestamp: November 26, 2016, 08:56:10 am
content: Quote from: TwoOfFive on November 26, 2016, 08:29:48 amIf you love your ASCII terminal and PS/2 keyboard so much you go ahead build your own SBC with it.I have repeated myself times and times again that those old peripherals have no use of me and I am not taking it as a stepping stone. I am not building on top of nothing - a good portion of the hardware I am planning to use have already been verified using other CPU architectures, the ones I have not verified yet can be verified similarly, and being a CS major I know better than you do at where to insert a layer of abstraction in the code to make those drivers portable and how to mask off the differences of the underlying hardware. So maybe yes my current library code is based on AVR or ARM Cortex-M3, but the same code is one recompile away from being used on m68k. And I am even using the same compiler (GCC.)

author: janoc
author_rank: Super Contributor
timestamp: November 26, 2016, 04:11:24 pm
content: Quote from: technix on November 26, 2016, 07:15:41 amWhich is why I have commented earlier that if you are going to stick an FPGA there, you can as well use an 68k softcore instead of bothering with the physical CPU. I have no problem using a modern MCU to provide an interface circuitry to an old CPU or using a CPLD for some glue logic, but if I had to interface a modern FPGA to an old CPU, that's likely where I would draw a line. It is certainly possible to do that, but solving crazy engineering issues is fun only to a certain limit. It also wouldn't be exactly cheap, even with Chinese prices.

author: technix
author_rank: Super Contributor
timestamp: November 26, 2016, 05:36:10 pm
content: Quote from: janoc on November 26, 2016, 04:11:24 pmThere is already a soft core (Cortex-M0, Cortex-M1 or 1T-8051, based on what can fit) inside to translate the DDR2 interface into PSRAM, an additional core may not fit if I went for a smaller, TQFP FPGA. Those bigger ones that comes in only BGA packages is an automatic rule-out, as I cannot hand solder it.

author: Ampera
author_rank: Super Contributor
timestamp: November 26, 2016, 06:17:53 pm
content: Quote from: technix on November 26, 2016, 08:56:10 amThen what do you need us for? I am saying, you asked for help, don't get to complicated, if you don't need help, go as complicated as you want. That's all. Don't ask for help if you don't need it.

author: technix
author_rank: Super Contributor
timestamp: November 26, 2016, 06:46:08 pm
content: Quote from: TwoOfFive on November 26, 2016, 06:17:53 pmIf I were asking fortechnicalhelp I wouldn't post it in General Chat in the first place.

author: MK14
author_rank: Super Contributor
timestamp: November 26, 2016, 08:04:06 pm
content: Quote from: technix on November 26, 2016, 06:46:08 pmThe title says:QuoteHelp = You wantHELP= Technical assistance ?Or are you emulating the English language at the next level up, recompiling the definitions library book, as a CS Major, and accidentally changing the definition of the language by mistake ?

author: Ampera
author_rank: Super Contributor
timestamp: November 26, 2016, 08:28:32 pm
content: Quote from: MK14 on November 26, 2016, 08:04:06 pmYea, I mean you asked what parts you can put on it and where you could find them.Look, you can go ahead and build your computer how you want it. If you need help figuring out that SDRAM isn't going to work without a lot of work on a 68k, then I think you should start smaller, but if you have full confidence you can do it, go right ahead.

author: technix
author_rank: Super Contributor
timestamp: November 26, 2016, 09:03:52 pm
content: Quote from: TwoOfFive on November 26, 2016, 08:28:32 pmIt appeared to me that you have confused interface with protocol and stayed blind to what I am talking about the whole time when regarding coprocessors and interfaces. Since you have talked about ASCII terminals so much, let's use a proven ASCII terminal interface chip as an example. I believe you have heard about the 16C450 UART. And there is also SC16IS752 from NXP. Those chips are logically identical albeit using a different interface - 16C450 uses FSB, but SC16IS752 uses I2C or SPI to tunnel the FSB interface. When writing the drivers, a competent programmer (hopefully with some CS background) will isolate the bus bridge layer and the register manipulation layer, allowing for code reuse. In this case, an appropriately layered 16C450 driver will work directly for SC16IS752, by adding a new bus bridge layer pointing to the SPI bus, replacing the original FSB interface.The Ethernet chip I am talking about is WCH CH395, a chip very similar to the W5100 used on Arduino Ethernet Shields but comes with a FSB interface along with SPI. The USB chipset, WCH CH375, is not too dissimilar to the USB host chip used on Arduino Mega ADK, but also comes with a FSB interface. 8-bit AVR can drive those chips with tunneled communication already, why can't m68k do that without a layer of indirection? CH395 and W5500 are similar enough to the point that I can directly copy the Arduino library code over, remove the SPI bus bridging layer, change the locations of the registers and the bits around, and it would still work.For the display on the 68000, the first stage plan does not contain a HDMI interface (in fact, it is the third stage plan,) instead a KS0108-based dot matrix LCD is used. I do intend to run with GUI from day 1 so ASCII terminals are not that appropriate for me. The second stage plan uses the parallel RGB LCD interface and adds an PWM audio output (I2S is simple enough to be implemented on a 64-pin-or-less 5V CPLD and some dual-port RAM), and the third stage uses some existing interface chip to combine the parallel LCD interface and the PWM audio interface into a HDMI stream.As of the 68030 project, I will definitely not put the 68k soft core into the FPGA even if it fits, instead I would rather put a soft core for PCI Express root complex there (OpenCores have multiple working open source implementations already) so I can use a wider range of peripherals. And since 68030 runs Linux, most of the peripherals I can throw at it will have a driver already present in the kernel as long as I can get the PCIe root up and working. This also puts the HDMI argument to the rest, as having a working PCIe root complex means I can use a straight PCIe GPU to mind the HDMI output. Sicne the 68030 is a few times slower than the DDR2-800 memory sticks and PCIe interface, DMA is also a non-issue as I can simply run the DMA requests generated by PCIe peripherals using time slots not used by the 68030.

author: rrinker
author_rank: Super Contributor
timestamp: November 27, 2016, 03:46:22 am
content: Didn't see anyone mention - but the TRS-80 Model 16 and 6000 used a 68000 main CPU with a Z80 for I/O and ran Xenix. Back in the day, my friend and I both had accounts on the display system at the local Radio Shack Computer Center, that was my first exposure to *nix. They did max out at 768KB RAM though.

author: technix
author_rank: Super Contributor
timestamp: November 27, 2016, 06:38:19 am
content: Quote from: rrinker on November 27, 2016, 03:46:22 amMy design is not too different though, with a 68k main processor and a PIC16F877 I/O coprocessor. USB and Ethernet sits in the FSB directly, and I have 15.5MB RAM.

author: Ian.M
author_rank: Super Contributor
timestamp: November 27, 2016, 09:46:46 am
content: Even if you haven't bitten off more than you can chew with this project, you'd be crazy to use the PIC16F877. Assuming you are constraining yourself to 5V PICs available in DIP, why not use the PIC18F4620? Its got the same PSP (Parallel Slave Port) so is equally suited to acting as a slave I/O coprocessor, but its twice the speed with far more memory.However I still think you'd have an easier time of it if you use a Linux SBC as the host for this, with a FPGA gluing the SBC I/O port to the 68000 bus.

author: technix
author_rank: Super Contributor
timestamp: November 28, 2016, 02:37:33 am
content: Quote from: Ian.M on November 27, 2016, 09:46:46 amI haven't bothered with Microchip's portfolio yet... Is there any PIC24 that also have a PSP though?

author: Ian.M
author_rank: Super Contributor
timestamp: November 28, 2016, 04:00:17 am
content: Microchip's PIC24 PMP/EPMP modules support an 8 bit slave mode, however you wont find that on a 5V capable part

author: technix
author_rank: Super Contributor
timestamp: November 28, 2016, 04:06:24 am
content: Here is the plan for the MC68HC000 Gen 1 machine:* CPU: MC68HC000 @ 20MHz* RAM: 31x IS61C25616 = 15.5MiB* NVRAM: 14x FM18W08 = 448kiB* TAP: 8x SN74ABT8245 surrounding the CPU for JTAG access* Graphics: KS0108-based dot-matrix LCD* Ethernet: CH395 (similar to W5500, but uses FSB access)* USB Host Port: CH370* USB Device Port: CH372* General Purpose Co-processor: PIC16F877 or PIC18F4620 (pin compatible anyway)Memory map:Code:0x00000000 - 0x0006ffff = NVRAM (14x FM18W08)0x00070000 - 0x000700ff = Graphics0x00070100 - 0x000701ff = USB Host0x00070200 - 0x000702ff = USB Slave0x00070300 - 0x000703ff = Ethernet0x00070400 - 0x000704ff = Coprocessor0x00074000 - 0x00077fff = Expansion slot 10x00078000 - 0x0007bfff = Expansion slot 20x0007c000 - 0x0007ffff = Expansion slot 30x00080000 - 0x007fffff = SRAM (15x IS61C25616)0x00800000 - 0xff7fffff = shadow RAM0xff800000 - 0xffffffff = SRAM (16x IS61C25616)The coprocessor have a GPIO pin that can cause in RAM in physical addresses 0x00000000 - 0x0007ffff and 0xfff80000 - 0xffffffff (the first 512kB and the last 512kB blocks) switch places, allowing the boot ROM to move itself to the end of RAM, and allow the application to write its own interrupt vector without overwriting NVRAM.

author: technix
author_rank: Super Contributor
timestamp: November 28, 2016, 04:13:46 am
content: Quote from: Ian.M on November 28, 2016, 04:00:17 amIs there any 16-bit mode?

author: MK14
author_rank: Super Contributor
timestamp: November 28, 2016, 04:17:00 am
content: Quote from: technix on November 28, 2016, 04:06:24 amQuote from: technix on November 22, 2016, 12:30:11 pmIt seems to be a 10 MHz part that you bought. Running it at 20 MHz, may cause problems.It is usually best to stick to the datasheet specifications, unless you are happy to have unpredictable results and have something which is not necessarily reliable. If it even works at all, at that speed.Or get a real 20 MHz part.http://www.cpu-world.com/CPUs/68000/Motorola-MC68HC000P10.html

author: Ampera
author_rank: Super Contributor
timestamp: November 28, 2016, 04:20:46 am
content: Quote from: MK14 on November 28, 2016, 04:17:00 amIncorrect, it is a 20 Mhz part, because it's the CMOS variant. I think I posted the datasheet as the second or so posts.

author: MK14
author_rank: Super Contributor
timestamp: November 28, 2016, 04:24:14 am
content: Quote from: TwoOfFive on November 28, 2016, 04:20:46 amIncorrect, it is a 20 Mhz part, because it's the CMOS variant. I think I posted the datasheet as the second or so posts.No,definitelyit does seem to be a 10 MHz part. Checked with a number of sources.There is a 20 MHz part, which end in P20. (MC68HC000P20).

author: Ampera
author_rank: Super Contributor
timestamp: November 28, 2016, 04:26:00 am
content: Quote from: MK14 on November 28, 2016, 04:24:14 amNo,definitelyit does seem to be a 10 MHz part. Checked with a number of sources.There is a 20 MHz part, which end in P20. (MC68HC000P20).Alright, whatever.

author: MK14
author_rank: Super Contributor
timestamp: November 28, 2016, 04:30:52 am
content: E.g.http://pdf.datasheetcatalog.com/datasheet_pdf/motorola/MC68HC000CFN10_to_MC68SEC000PB20.pdfSee page 25.

author: MK14
author_rank: Super Contributor
timestamp: November 28, 2016, 05:01:26 am
content: Quote from: TwoOfFive on November 28, 2016, 04:26:00 amSorry, if I have caused any offence.

author: Ampera
author_rank: Super Contributor
timestamp: November 28, 2016, 05:23:15 am
content: Quote from: MK14 on November 28, 2016, 05:01:26 amNah it's fine. Offense would be hard to accomplish.

author: george.b
author_rank: Frequent Contributor
timestamp: November 28, 2016, 06:12:11 am
content: I have a 68k in a drawer somewhere, waiting until I gather the courage to attempt something like this:

author: technix
author_rank: Super Contributor
timestamp: November 28, 2016, 11:43:20 am
content: Quote from: MK14 on November 28, 2016, 04:24:14 amNo,definitelyit does seem to be a 10 MHz part. Checked with a number of sources.There is a 20 MHz part, which end in P20. (MC68HC000P20).Socket the crystal. Problem solved.

author: C
author_rank: Super Contributor
timestamp: November 28, 2016, 05:18:43 pm
content: technixAfter spending all the time and money to do this, what do you hope to gain|learn out of this?In your latest list, I see a poor PC clone that is not really using more then the large memory of the 68000.Not much mention of where the 68000 was different from other processors of the day but the large linear memory.Yes the 68000 can be used this way, but this leaves out the real nice things the 68000 has that other CPU of the time did not have.With your software background, I could understand you wanting to learn and try out a virtual CPU using a 68010 or later chips. The way the 68010 put in place the basics for this you should be able to have a virtual CPU actually running a virtual CPU. You can build a tree of virtual CPU's all directly running on hardware CPU with only a few instructions needing support from the higher level CPU. But this is the 68010.For the 68000You have outputs needed from chip to do memory management or memory protection. The TRS Model 16, TRS Model 6000 had user program memory protection. A user program only had access to memory between a start & end address, Access outside this range called system. System could change the start & end address range for each user program. A simple memory protection system that works.As I stated before, the 68000 has the hardware & software needed to have many 68000's connected to a bus do work. How many computers have this today? This hints that best design is a simple CPU board that you can many connected to a bus. Yet you do not mention this in your design.The 68000 has a nice vector interrupt with priority, You do not mention this.For a CPU to talk to the world, you need,1. Shared memory with ability to create and receive interrupts.or2. A 9-bit interface so that you can have 8-bit transparent data of many types.or3. A packet based interface that allows 8-bit transparent data.With 8-bit transparent data, you do not have overhead of having to scan & convert some bytes to maintain markers for different data types.SCSI did a combination of #2 & #3 and ended up with 8-bit transparent data and 8 hosts being able to share a bus.HPIB/IEE488 has 8-bit transparent data & many masters.SCSI & IEE488 can be simple and have been done with 8-bit CPUs. The nice thing here is the async parallel data transfer rate using simple hardware.HDLC & SDLC did #3 by using bit stuffing over sync serial.Your USB & Ethernet gives you #3 but not the simple unless you drop back to bare Ethernet.Note that you really only need one interface to do all IO. Back in the day, All IO of a very powerful system could be over SCSI not just storage. SCSI networks did exist. SCSI was used to interface to terminals, printers, wan and more.Look at Linux, Was it built with a foundation of many CPU's using NUMA sharing a bus?The 68000 can do a lot if you do not add a lot of garbage processing.Look at again at very simple that gives you very powerful at start and lets you learn/use many 68000s in future if you want. Think of this 68000 & your 68030 and many more working together.Your current design looks like you are trying to create a poor PC or a microcontroller out of a microprocessor that was designed more as part of a mainframe or mini computer.