A very simple one. It may recall the DEC PDP-11 or some other mini from the early 1970's but Heritage/1 will be a lot simpler than that and it won't use ferrite core memory!
Basically it will be a sequential 16-bits digital minicomputer with two's complement arithmetic, a "decent" probation of RAM (about 32 KB) and for storage it will employ some sort of magnetic tapes. Lamps and switches, of course, and RS232 ports to communicate with "Terminals", that is PCs running Terminal emulation software such as Kermit or Hyper Terminal.
It will lack ROM memory. You will be able to turn the computer on without having to wait for the "boot up"; software will be entered from storage after had "typed" a little loader program by the mean of switches. I will really enjoy that part!
My personal motivations -I guess other people had had their own- are basically these two: For one part, I wanted to traverse that frontier that microprocessors represent when we see them as "black boxes": I wanted to write software for a hardware that I truly know up to the wire level. For the other part, I wanted to honor the 1970's computer technology by designing a computer similar to those, build it and -what is more important- to use it for solving problems in the same fashion they did in the past... That will be like time-traveling to the 70s, I guess!So this project has a lot of cultural as well as technical, hence the severe historical constraints that I have imposed to my self when designing the minicomputer.
What ignited my desire for getting into this was the Harry Porter's Relay Computer project. That was in May 2009. I spent four days researching and sketching my own solution until I saw that, as fascinate as the project might be, there is no too much room for software in a relay computer.
I turned then to TTL and started to be very influenced by Bill Buzbee's Magic-1. This effort last for one months until I realized that what Bill Buzbee did is far beyond my experience and knowledge on the matter.
Nevertheless these two attempts had exposed me already to a lot of readings and a better understanding on how computers (in general) really work. It also allowed me to approach the matter from the cultural angle which is important.
It was then when I turned to John Doran's D16/M which I recognize as the definite influence for the Heritage/1 project.
I plan, indeed, to use the Heritage/1 minicomputer for doing tangible work. Actually that is an important design principle that I imposed to my self: usefulness. It is important because it sets the difference between a toy and a product... well, she is not exactly a "product", but the fantasy of been so pushes the design toward a very interesting direction.
Working in Batch Processing, Heritage/1 could possibly resolve Math problems such as Interpolation, Linear Equations Systems, Fourier Transform and things like that... if I get to write the software correctly, of course...
Time-Sharing? I'm not truly aimed for those nowadays familiar interactive multi-user environments but chances are for that to happen in the future, why not?
It's all about software. If I get to write the software (including the Operating System), Heritage/1 will be able to run it. Could I? not sure... time will tell.
I started the current hardware design without any operating system in mind. During my first attempt I got to dream with porting Minix to my machine as Bill Buzbee did with his Magic-1 but, as mentioned, I realized that I don't have the knowledge nor the experience required for such a venture.So I focused on hardware design for many months until recently that I started to sketch a simple operating system for the computer that I designed. This would be a proprietary multiprogramming single-user operating system oriented to batch processing and magnetic tapes. The simpler the better but (as I've seen so far) no operating system is truly simple...
I started moving this project by personal motivation instead of dead lines; some days I were so motivated that I spend the whole night working on it; at some other times I were disappointed or lacy so I went to sleep early.
I realized that the project were moving too slowly so I started to set dates for completions, a sort of Project Plan divided into managable phases. According to this plan, a functional Heritage/1 computer (hardware only) would be ready by May 2010. But May came, went away and the machine is still unfinished.
Hence I learned that a project that can only be worked out at free times (which is not too abundant in my life) simply can not be planned in time. What I used to do now is to make "estimates". According to the lastest one, Heritage/1 cannot be finished by this year (2010).
I designed the machine around SSI/MSI integrated circuits, no LSI, so ROM chips got automatically discarded. With no ROM for storing microcode, the microprogramming approach gets some how discouraged.
There is a philosophical argument too: According to the Heritage/1 culture, Software is something "external" to the computer, something that has to be loaded at a later time and not while the computer is still waking up. Microcode is not strictly "software" but it is "soft", some kind of ghost doing its magic inside the CPU. I wanted logic functions to be done with logic circuits, not with "ghost logic".
I also find that hardwired logic is more clear: When I say that the Op Cod Fetch sequence takes 3 clock cycles I mean exactly that: 750 nanoseconds (assuming a 4 MHz clock frequency), not 3 microinstruction cycles each of which takes in turn some other nanoseconds to complete.
I am new to this matter and, yes, I've read about the so called MDR and MAR registers and I've seen how other homebrew designers have implemented such a thing, but -I may be wrong- I haven't seen the need for those so far in my design.
I read the instruction operational code from memory directly into the IR register (a single transfer: 3 clock periods) and it stays there for the instruction's life-term. Similarly, I read the operand (if any) into the Operand Register (OR) while my IR is still providing the operational code to the instruction decoding circuitry. I don't see the need for any intermediate register.
If the operand happens to be a direct address, I open the Address Buffer of the OR register for providing the address to the bus. If it happens to be an immediate value, I open the Data Buffer instead. It is maybe that I've replaced the so called MAR register with the double-buffering design of my registers... I don't really know, but again, I don't see the need for intermediate registers.
What I guess is that not having intermediate transfers will make my CPU to work faster... I guess...
It is not bizarre. The idea came to me from the DEC PDP-11 Manual. I just simplified it to the minimum: just one IRQ/IAK couple plus a third signal that I had to add: Interrupt Service End (ISE). I'm not sure if it's going to work. It works on paper, at least.
I'm very attached to the idea of using magnetic tapes instead of disks. Why? Historical reasons: (1) Tapes was around for decades before disks were invented and they last long before disks got to settle as dominant technology for storage, and (2) because tapes present interesting limitations that I definitely want to deal with.
You can not insert records in the middle of a tape nor you can replace existing records in place. Instead, you need to read data from a source tape, perform the required processing in memory, then copy the result to a second tape. As your memory is limited, you can not simply copy the whole file into memory so you need to process your data in sequence, one block at a time.
Since tapes are sequential in nature, data structures such as queues and stacks are natural to them and sequential algorithms such as Merge Sort are essential, which is interesting to try out.
Specially challenge is to implement a Time-Sharing system based solely on tapes. I don't think is even possible, but it is definitely interesting to think about those kind of complex applications within the tremendous limitations that tapes portrait.
Obviously, not those 9-tracks systems used in the pass. I have plans for using open reel 1/4 inch audio tapes, audio cassettes and even VHS video tapes. Those are projects on their own and they will be tackle at a later time. But the idea that I have at this early stage is to record bi-phase signals for audio tapes and NTSC black and white video signals for VHS. Some sort of error correction method such as CRC will be needed as well as PLLs for locking to the imprecise speed of the transport... that will be tremendously interesting, I guess.
It makes no sense is you consider the historical context of this project. If memory were so abundant that I could build a "solid state disk" out of it, why not to employ as many chips for increasing the main memory instead?
RAM DISK appeared actually in the 80s, the microcomputers era. Heritage/1 belongs to the 60s and 70s, when 32 KB of core were a luxury for a minicomputer of its kind. Storage, however, ran in the order of tens of megabytes at that time in history; actually storage were unlimited since it consisted of mountable media such as tape. Moreover disk were also mountable at that time.
Memory, on the contrary, is always a scarce resource, and it was very scarce in the era that Heritage/1 tries to represent. In modern times, RAM DISK is perfectly possible, but that would defeat the main idea of this project in particular.
The obvious idea is to use a PC running a terminal emulation software such as Kermit or Hyper Terminal, connected via RS232. I surely will try that.
Another idea is to adapt a modern type-writer to become a "teletype" attached to Heritage/1 via RS232. Teletypes are similar to tapes in the sense that they are part of the folklore of computers as they was used since the beginning to quite recently that "glass teletypes" were available.
Not exactly. I have no option but to employ modern equipment for peripherals and they already use microprocessors internally. But this is not too inconsistent with history since some peripherals in the 70s did make use of 8-bits microprocessors.
I will ensure that my CPU will NOT use any kind of LSI (actually, RAM is external to the CPU). I will try to extent this policy for peripherals as well but only within the margins of sanity.
No. Actually, RS232 ports are peripherals by their own and they are in dedicated rack-mount units separate from the CPU cabinet.
Peripheral connect to the CPU via the external bus (that I called "U-BUS"); as seen from the outside this bus consists of two ribbon cables ended with DB-SUB connectors. Memory, for example, is considered a peripheral since it resides in a dedicated unit connected to the CPU via U-BUS, as everybody else.
Tape controllers will be constructed the same way. They contain dual-port buffers (say for instance 1 KB) occupying a portion of the addressable space (memory mapped) and they interrupt the CPU throughout the U-BUS.
Many. But each peripheral is a project per se so they will be tackled later when the CPU is fully functional.
I've considered, for instance, a Real-Time Timer (RTT) which is a unit with 7-segments displays similar to an Alarm Clock: you set the current date and time by pressing buttons on the front panel!
Also a "GANG UNIT": a rack mount cabinet for conveniently placing single-card peripherals such as GPIOs (General Purpose Inputs/Outputs consisting in relay closures). Others will surely come, such as A/D, D/A converters and "line-printer" controllers.
The architecture is open to any sort of extension by simply adding new units to the U-BUS. The only problem is the enormous amount of time and effort involved in each of those creatures...
Well, I see that must hobbits have built compact CPUs housed in a single cabinet which also contains the Main Memory and even an IDE hard drive. I agree in that such is a convenient setup for the purpose but I'm putting an emphasis on the "old flavor" of my machine so I want it to look similar to those minis in the late 60's and early 70's... that is bulky!
I'm not planning for specific cabinets yet but most likely those will be sort of rack mount frames. Not just one but many of them. The whole thing will possibly compose a large piece the size of a refrigerator.
I think the large space will be justified because I'm not building just a CPU but the entire computer with different device controllers occupying separate units (enclosures). Moreover the storage (open-reel audio tape, VHS VCRs etc) will take a lot of space on its own.
I think she's going to be pretty and will have a nostalgic flavor. Actually, that is the idea.
Because the big ones are very expensive. That's the one reason, the other is modularity.
Despite my "usefulness" metaphor, the fact of the matter is that Heritage/1 is going to be experimental. This means that I'll be adding functionality over time so extensibility (adding instead of replacing) is important to me.
The use of small boards forces a modular design from the beginning so extending existing circuits in the future can hopefully be done without braking the original design.
Good question. I don't think I have a good answer for it. As a matter of fact, I've never used wire-wrapping but I got to consider it and when I did, I found that wire wrap boards and IC sockets are really, really expensive...
For the other part, I'm very familiar with soldering components and wires on prototyping boards; honestly, to solder is something that I actually enjoy. The only bad thing about soldering is the enormous amount of time it takes to build a single circuit board.
Again, choosing soldering over wire-wrapping is not very convincing indeed but, personally, I don't feel particularly uncomfortable with that.
David Brooks, the designer of the Simplex-III homebrew computer, has founded the Homebuilt CPUs Web Ring. To join, drop David a line, mentioning your page's URL.
He will then add it to the list. You will need to copy this code fragment into your page.