(M)MC68HC000P10
2E60R
DJQFJ9513Now what can I do with it? How can I find RAM and other peripherals to go with it?Have a look into the old Amiga A500. This was what they used
Of course, always consult the datasheet, http://pdf.datasheetcatalog.com/datasheet/motorola/MC68HC000.pdf (http://pdf.datasheetcatalog.com/datasheet/motorola/MC68HC000.pdf)I have this feature set in mind:
Yes 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 work
CPU 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 system
CPU 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, the
primary 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.
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...If another processor is required, I would prefer using a PIC16 for this. I think that the modern Linux kernel have workarounds for this?
*The additional hardware might, of course, be another 68000
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...If another processor is required, I would prefer using a PIC16 for this. I think that the modern Linux kernel have workarounds for this?
*The additional hardware might, of course, be another 68000
No 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.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...If another processor is required, I would prefer using a PIC16 for this. I think that the modern Linux kernel have workarounds for this?
*The additional hardware might, of course, be another 68000
Period-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.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...If another processor is required, I would prefer using a PIC16 for this. I think that the modern Linux kernel have workarounds for this?
*The additional hardware might, of course, be another 68000
I 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.
Period-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.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...If another processor is required, I would prefer using a PIC16 for this. I think that the modern Linux kernel have workarounds for this?
*The additional hardware might, of course, be another 68000
I 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.
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.
No 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.
Is 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.No 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.
If 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.
No 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.
If 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.
No 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.
If 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.
Didn't the CMOS 68HC000 implement the proper MMU?
Is 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.
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.
I 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.)Is 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.
Well, 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.
I 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.)Is 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.
Well, 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.
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.
That'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 to finally go 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...
.. if you want a 68k machine, make an ACTUAL 68k machine.+1
When was the last time you had a 20Mhz machine run Linux?
Then 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.
Well, 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/FUZIX (https://github.com/EtchedPixels/FUZIX)
http://www.bigmessowires.com/2014/11/06/building-uclinux-for-a-68000-target/ (http://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 :)
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.
Enough 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.Well, 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/FUZIX (https://github.com/EtchedPixels/FUZIX)
http://www.bigmessowires.com/2014/11/06/building-uclinux-for-a-68000-target/ (http://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 :)
Well, 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.
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.That is the purist in you.
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."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.
Again, 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 @ 120mhz
a 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.
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.
If you are a non-purist, you'll probably be best served by running your 68000 as a hosted coprocessor similar to https://en.wikipedia.org/wiki/Tube_(BBC_Micro) (https://en.wikipedia.org/wiki/Tube_(BBC_Micro))That 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.)
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.
Enough 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.
DDR2 goes to the 68030/68882 machine.Enough 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.
DDR2 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.
DDR2 goes to the 68030/68882 machine.
DDR2 goes to the 68030/68882 machine.
Sorry, 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.
Remember 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.DDR2 goes to the 68030/68882 machine.
Sorry, 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.
You 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?DDR2 goes to the 68030/68882 machine.
Sorry, 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.
@OP
Man, 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.
You 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?DDR2 goes to the 68030/68882 machine.
Sorry, 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.
@OP
Man, 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.
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.
Period-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.
Period-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.
Ahem, 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;)
If you love your ASCII terminal and PS/2 keyboard so much you go ahead build your own SBC with it.Period-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.
Ahem, 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;)
You could also use an ASCII terminal, and have the USB host on a SBC.
Remember 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.
There 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.Remember 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.
Which 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.
If you love your ASCII terminal and PS/2 keyboard so much you go ahead build your own SBC with it.Period-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.
Ahem, 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;)
You could also use an ASCII terminal, and have the USB host on a SBC.
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.)
If I were asking for technical help I wouldn't post it in General Chat in the first place.If you love your ASCII terminal and PS/2 keyboard so much you go ahead build your own SBC with it.Period-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.
Ahem, 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;)
You could also use an ASCII terminal, and have the USB host on a SBC.
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.)
Then 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.
If I were asking for technical help I wouldn't post it in General Chat in the first place.
I pulled the plug and bought a MC68HC000. Help.
If I were asking for technical help I wouldn't post it in General Chat in the first place.
The title says:QuoteI pulled the plug and bought a MC68HC000. Help.
Help = You want HELP = 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 ?
It 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.If I were asking for technical help I wouldn't post it in General Chat in the first place.
The title says:QuoteI pulled the plug and bought a MC68HC000. Help.
Help = You want HELP = 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 ?
Yea, 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.
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.My 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.
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.I haven't bothered with Microchip's portfolio yet... Is there any PIC24 that also have a PSP though?
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.
0x00000000 - 0x0006ffff = NVRAM (14x FM18W08)
0x00070000 - 0x000700ff = Graphics
0x00070100 - 0x000701ff = USB Host
0x00070200 - 0x000702ff = USB Slave
0x00070300 - 0x000703ff = Ethernet
0x00070400 - 0x000704ff = Coprocessor
0x00074000 - 0x00077fff = Expansion slot 1
0x00078000 - 0x0007bfff = Expansion slot 2
0x0007c000 - 0x0007ffff = Expansion slot 3
0x00080000 - 0x007fffff = SRAM (15x IS61C25616)
0x00800000 - 0xff7fffff = shadow RAM
0xff800000 - 0xffffffff = SRAM (16x IS61C25616)Microchip's PIC24 PMP/EPMP modules support an 8 bit slave mode, however you wont find that on a 5V capable partIs there any 16-bit mode?
Here is the plan for the MC68HC000 Gen 1 machine:
* CPU: MC68HC000 @ 20MHz
Code: [Select](M)MC68HC000P10
2E60R
DJQFJ9513
Can it run at 20MHz as specified in the manual, or can it only run at up to 10MHz?
Here is the plan for the MC68HC000 Gen 1 machine:
* CPU: MC68HC000 @ 20MHzCode: [Select](M)MC68HC000P10
2E60R
DJQFJ9513
Can it run at 20MHz as specified in the manual, or can it only run at up to 10MHz?
It 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 (http://www.cpu-world.com/CPUs/68000/Motorola-MC68HC000P10.html)
.html]http://www.cpu-world.com/CPUs/68000/Motorola-MC68HC000P10.html[/url]Here is the plan for the MC68HC000 Gen 1 machine:
* CPU: MC68HC000 @ 20MHzCode: [Select](M)MC68HC000P10
2E60R
DJQFJ9513
Can it run at 20MHz as specified in the manual, or can it only run at up to 10MHz?
It 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-[quote author=technix link=topic=77757.msg1075993#msg1075993 date=1479817811)Code: [Select](M)MC68HC000P10
2E60R
DJQFJ9513
Can it run at 20MHz as specified in the manual, or can it only run at up to 10MHz?
.html]http://www.cpu-world.com/CPUs/68000/Motorola-MC68HC000P10.html[/url]Here is the plan for the MC68HC000 Gen 1 machine:
* CPU: MC68HC000 @ 20MHzCode: [Select](M)MC68HC000P10
2E60R
DJQFJ9513
Can it run at 20MHz as specified in the manual, or can it only run at up to 10MHz?
It 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-[quote author=technix link=topic=77757.msg1075993#msg1075993 date=1479817811)Code: [Select](M)MC68HC000P10
2E60R
DJQFJ9513
Can it run at 20MHz as specified in the manual, or can it only run at up to 10MHz?
Incorrect, it is a 20 Mhz part, because it's the CMOS variant. I think I posted the datasheet as the second or so posts.
Alright, whatever.
Nah it's fine. Offense would be hard to accomplish.Alright, whatever.
Sorry, if I have caused any offence.
http://www.cpu-world.com/CPUs/68000/Motorola-MC68HC000P10.html (http://www.cpu-world.com/CPUs/68000/Motorola-MC68HC000P10.html)Here is the plan for the MC68HC000 Gen 1 machine:
* CPU: MC68HC000 @ 20MHzCode: [Select](M)MC68HC000P10
2E60R
DJQFJ9513
Can it run at 20MHz as specified in the manual, or can it only run at up to 10MHz?
It 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-[quote author=technix link=topic=77757.msg1075993#msg1075993 date=1479817811)Code: [Select](M)MC68HC000P10
2E60R
DJQFJ9513
Can it run at 20MHz as specified in the manual, or can it only run at up to 10MHz?
Incorrect, it is a 20 Mhz part, because it's the CMOS variant. I think I posted the datasheet as the second or so posts.