|
Ya gotta upgrade to adamantium. Much stronger...
|
|
|
|
|
How much memory does a 8 bit computer need?
Practical answer: As much as you can squeeze onto the circuit board. In the past that used to be much less than what you hoped for and also far less than the 64k the processor could address.
Simple answer: 64k minus ROM, Video memory and memory mapped I/O devices is what's left for RAM in the memory map. In this case that would be exactly 32k. Today you can have that in one IC for two bucks. No need for a memory board, just put it onto the processor board.
Traumatized answer: 4k is not very much, but all there was in the old computer. Since then I have put together a few computers and all of them got as much memory as I could afford, preferrably the maximum. That would be those 32k, right?
Wrong. It turned out that I could squeeze a little more onto a memory board: Circuit board Design[^]
That's a full little board and every pin of those ICs is used. It divides up the 32k area into two 16k areas and provides the logic to switch each of them between 256 memory pages.
Fully loaded, this board will give an 8 bit processor access to 2 x 256 x 16k memory (plus the 32k of the rest of the memory map). That's 8 Mb! I hope that will last a while.
Edit: I also found a way to integrate the page switching into the stack protocol for calling subroutines (plus mapping logical to physical pages). This way the code will not be aware that it's running in paged memory. I can call anything at any time and the code will not notice anything of the bank switching.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
modified 21-May-18 14:25pm.
|
|
|
|
|
Nice one... Not that I ever remember that the 64k memory stopped me from doing things, but 8Mb sound fascinating...
Not sure however I have heard those numbers in my days of C64... Amiga 500 with its 512k was a dream...
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
|
|
|
|
|
I saw a Z80 S-100 CP/M system that was full to the brim with 64k memory boards, but I guess that was was done more recently.
Look at this magazine from 1980[^]. They have an article about those 'upcoming' 16 bit processors, 8086, Z8000 and 68000. They came to the conclusion that those processors are neat, but not for home use. They needed at least 128k, if not more and who could afford to go to the limit?
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
As I recall, the Z8000 went virtually unnoticed in comparison with those other two 16-bit processors. I also remember that many people called the 68000 a 32-bit CPU. Another amusing memory is buying my first PC that had an 8MHz 8088. Back then no one had heard of the word "overclocked."
|
|
|
|
|
Rick York wrote: I also remember that many people called the 68000 a 32-bit CPU.
That's because it was 32 bit internally (data-bus, command-set), and therefor was a small miracle of the time by being forwad-compatible with later itself...
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
|
|
|
|
|
Ahh, then my little 8 bit CPU actually is a 16 bit CPU. It has 16 general purpose registers, each also 16 bits wide.
This actually is cheating. What counts is how many data lines go to the bus, not what the CPU can do internally.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
It is cheating only if there is nothing behind those 16 bit registers... In 68000 there was an instruction set that was designed to work with 32 bit addressing too (the idea was to create binary code that continues to work as the CPU evolves)...
It was designed to be the first step and with 68020 they hit it.
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
|
|
|
|
|
Yes, the 68010 68008 was analogous to the 8088 with a multiplexed data bus but the 68020 had true non-multiplexed, 32-bit data bus.
modified 22-May-18 2:03am.
|
|
|
|
|
Kornfeld Eliyahu Peter wrote: It was designed to be the first step and with 68020 they hit it.
And don't overlook that any pre-68020 program would run perfectly fine on a 68020 (or later) - not in an emulation mode, but 100% as native programs. The 68020 added a few instructions, as we have seen dozens of times in other architectures as well, but the architeture of the 68K and 6010 was carried on.
It is a pity that the 68K series didn't win the CPU battles. The instruction set is so clean that is resembles a RISC, the addressing modes are logical, ... the x86 is a terrible mess, in comparison. (It is actually so messy that have not dared to look into the x64, from fear of finding a similar mess.)
I could make a long list of processors with fewer data or address lines than the width of the CPU registers and internal data paths. It is, actually, quite common. Logically, the MMS of the 386 handled 32 bit addesses, but if my memory is right, it had only 25 physical address lines, so it could handle at most 32 MByte physical RAM.
Some of the early 8-bit CPUs had only 8 address lines, yet addressed 64K: The most significant 8 bits where sent out first, and one clock cycle later, the least significant 8 bits followed on the same lines. I believe some (quasi) 16-bit CPUs used similar methods for transferring 16 bit data values over 8 data lines.
On the other hand: The machine on which I did my first serious programming was a 16-bit "mini" (cabinet size) with 25 address lines: Through a quite fancy memory management system for its time, it could juggle segments around for up to 64 simultaneous users (plus background / daemon processes). That didn't make it a 25 bit CPU. It even had hardware for 48 bit floating point arithmetic, operating on triplets of 16 bit words; that didn't make it a 48 bit CPU. (Funny detail: It had this special machine instruction to reduce by one and multiply by 3, MIX3, which was tailored to Fortran float arrays, indexed from 1 rather than 0. So this instruction converted from the "logical" array index to the value to be added to the array base address to find the array eleement.)
The 8080 had an 8 bit architecture. Some instructions allowed two registers to be paired, as if they were one 16 bit register, but this was limited to a subset of operations. 8086 had 16-bit data paths and 20 bit addresses (that didn't make it a 20 bit CPU!) - you could operate on register halves, such as AH and AL (Accumulator High and Low), but the special case was splitting them up, the normal was to treat them as 16 bit registers.
|
|
|
|
|
Member 7989122 wrote: Logically, the MMS of the 386 handled 32 bit addesses, but if my memory is right, it had only 25 physical address lines, so it could handle at most 32 MByte physical RAM.
There were various variants of the 80386. The original version (later renamed 80386DX) was a full 32-bit processor, with a 32/32-bit data/address bus. The 80386SX used the same instruction set, but had a 16/24-bit data/address bus. Other variants had a 16/26-bit data/address bus. Lastly, there was a 486-compatible chipset that replaced an 80386DX/80387DX combination with a single chip that did most of the work, and an additional chip that provided the FERR signal and not much else.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Member 7989122 wrote: Some of the early 8-bit CPUs had only 8 address lines, yet addressed 64K: The most significant 8 bits where sent out first, and one clock cycle later, the least significant 8 bits followed on the same lines. I believe some (quasi) 16-bit CPUs used similar methods for transferring 16 bit data values over 8 data lines.
Multiplexing, the CPU I'm building this memory board for does this with the address bus. It may have been a blessing back then, but it certainly made everything more interesting for me now.
Latching the upper 8 address bits is easy to do, but some I/O chips from the CPU's family want to latch and decode the address lines themselves. The interrupt controller, for example, hogs 4k precious memory space for its registers, but would only need about 32 bytes if the address lines were properly decoded externally. Back in the day this may have helped to build small systems without much glue logic, but today it makes a proper design hard to realize.
Still, these and other microcontrollerish features made it the first CPU in space. It's low power requirements, being CMOS, may also have helped.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Yes, I know that. Externally it was not though. The 68010 was kind of like the 8088 in that it had a multiplexed 16-bit data lines whereas the 68000 did not.
Kind of like the 8088 but the difference is the 8088 had multiplexed 16-bit data lines where the 68000 did not. The 68000 had an eight-bit data bus. (brain fartage)
modified 21-May-18 16:35pm.
|
|
|
|
|
Rick York wrote: The 68000 had an eight-bit data bus
68000 had a 16 bit data bus (internally 32 bit) and a 24 bit address bus...
There where those (embedded controller) versions that could work with 8 bit data bus to fit better to the environment...
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
|
|
|
|
|
Sorry - had a brain fart. 
I meant the 68010 was the chip with the multiplexed data bus. The 68000 and 68020 had non-multiplexed data busses, 16 and 32-bits wide respectively.
|
|
|
|
|
I believe that you are confusing it with the 68008, which was a 68K with multiplexed data bus.
The first really fully grown 68K CPU was the 68030, with on-chip cache and MMU. Besides, it was significantly faster than its predecessors, primarily because it required fewer clock cycles for most instructions, and it could be clocked higher. That is the CPU that really deserved to win the market - but IBM was too strong, and Apple had far from the strength is has today. Besides, there was RISC wave coming, blinding people so they didn't see that 68K was as close to a RISC archictecture as you can possibly get while being a CISC  . So several of the former 68K engineering workstation-type manufacturers (e.g. Sun) abandoned 68K in favor of "pure" RISC design. Which is a pity. None of the RISCs survived. If they (including Apple) had stayed with the 68K, we could have had much cleaner architectures today.
|
|
|
|
|
I think you are right about the 68008. Didn't the 68010 have an on-chip MMU or something like that?
I remember fairly well the RISC psuedo-revolution that gave rise to the SPARC and 88000, Sun and Motorola's RISC chips. Intel even made something of an attempt at one with 80860. I think the only RISC chip that has survived, at least somewhat, is the PowerPC but it has changed a fair amount over the years. The MIPS instruction set has survived also, in an evolved form.
|
|
|
|
|
Wikipedia is ususally fairly correct when it comes to unarguable technical details. If that holds for 68K, the on-chip MMU came with the 68030. 68010 could use an external MMU chip (thanks to an upgraded fault handling), but it was not not on-chip. The 68010 also had a couple extensions (including one not perfectly backwards compatible) for coordinating multiple CPUs within one machine.
|
|
|
|
|
I see. Thanks for the info. I never dealt with the 68010 at all. I encountered practically every other one in the family up to the 68040 but not the 68010. Mostly that was with various VME bus systems and some STD bus systems for the older ones.
|
|
|
|
|
Now that you remind me of the PowerPC - I had almost forgotten that one!
It certainly deserves to be remembered: A very clean hardware achitecture, with core modules that always had to be present, and then a very regular and highly standardized internal interconnect for extending the core, similar (although in details quite differernt) to an I/O bus, but much closer to the core. The developer could add modules for, say, hardware implementation of matrix multiplication, FFT, trancendental functions... depending on the specific application area for that chip variant, an leaving "unneccessary" modules out, without compromising the RISC nature of the core, in a very clean and systematic way.
Some designers of ARM based (and probably other) embedded style chips have implemented on-chip "peripherals" (which may have nothing to do with I/O, but e.g. handle encryption), in ways that conceptually resemble the Power architecture, but never nearly as closely integrated with the core as in the Power.
Years ago, there was a Windows-NT implemenetation for the Power-PC. At that time, I was still hoping for it to squeeze out the x86 (anything that could squeeze out the x86 would be great!) ... It failed. I was hoping for Apple to go for the Power-PC: They made a try, but decided that accepting the x86 mess would give them higher profits... However, IBM and maybe others made a number of highly parallelized mainframe CPUs based on arrays of PowerPC chips. That didn't help to squeeze out the x86, though...
Then, when I check Wikipedia, to my surprise I see that as late as November 2015, a new version of the Power ISA standard was published. It is unclear to me whether IBM still develops Power based machines, but at least they did in 2015. So the architecture certainly not completely dead - but I guess that the primary users of Power based machines could care less about the processor architecture, as long as they have their problems solved. (Which is also the reason for the x86 mess to survive for 30 years more than it deserved!)
Frequently, I see people point to VHS as a prime example of the second best (or third, or fourth...) winning the battle. In the CPU world, the x86 is more like the fifth og sixth. It still won.
(Youngsters out there: If "VHS" is greek to you, ask your grandpa about it  )
|
|
|
|
|
Rick York wrote: Back then no one had heard of the word "overclocked."
That's not true. The same little 8 bit processor that I'm working with was often overclocked. It is a CMOS processor, which made it very flexible with its input voltage and its clock frequency. At 10v it went up to 6.4 MHz without being overclocked. Not so bad for a processor from 1976.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Yes, it is true. While it happened, CPUs were sometimes clocked higher than their rating, the word "overclocked" was not used. It was also not that common because CPUs usually did not have heat sinks back then. The IBM PC did not have a heat sink on its CPU for several generations, not until the 80486 become the standard processor. I remember when I bought a higher clocked 80287, they called it "turbo-speed" I believe. The standard chips were clocked at 6MHz and this one was 12MHz and it was unique in that it had a heat sink attached to the FPU. The stock ones did not, nor did this 80387 chips.
|
|
|
|
|
I worked with the Z8000 for about 5 years, and it was a damn good chip (or at least compared to the Z80 I was also working with - much better memory access for starters).
Pity it was overshadowed in the media by the 68-series, it could have been much better if it was wider used. Very nice instruction set!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I was studied computer architecture in graduate school at the time and we spent many class periods discussing the various chips and instruction sets of the day. I recall the Z8000 did have some attractive attributes but I can't remember the specifics now.
|
|
|
|
|
If you really want to be impressed by fancy architectures, try to get hold of a detail description of iAPX 432, coming to the market in 1981. A fully object oriented CPU - to the degree that if you mailed an object to another process (both communication and process concepts were realized by the CPU), you didn't mail a copy: You lost access to it yourself!
The architecture was extremely fancy; the implementation not quite as successful. Rumours were that a complete 432 CPU software simlator running on an 8086 was faster than the first physical CPUs sent to market. (Consider this a rumour; I can't document it.) But Intel people have been quite clear in that even though 432 was a total flop, they learned so much about how not do to things that when they soon after developed the MMS for the 386, they got it right.
Some times I think: What if Intel picked up the ideas from 432 today, and set out to make an object oriented CPU the right way today? Of course you couldn't just implement the original 432 architecture (e.g. it could handle at most 8K objects), but scaling it up to fit today's needs, with all the protection and safety of a capability based architecture. In 1975, when the 432 project started, only a few academics knew of OO; now it is mainstream. Running Fortran on a 432 would be rather meaningless; running dotNet could be great!
I am not holding my breath waiting for it to happen, though. It is just that I was extremely fascinated by that chip in the early 1980s. I sure would like to re-experience that same fascination!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
