Plan B for retirement: DIY SoC with some 8-16 bit CPU & Co

[Aquinus]

So do I have any need for Arduino, I mean they have their advantages but... well, actually kind of want one now...

I don't really have a need for one either, but for how cheap they are it seems like an easy thing to impulse buy. The Uno Rev.3 is nice though because if you blow the chip, you can replace just the chip and not the board, even though the board plus chip is only something like $20 USD. That's a big plus if you're working with circuits and are running the risk of frying an input or something. Also, something simple like an Arduino that has a half decent IDE for writing and programming the board makes it a nice choice (their IDE works on Linux, OS X, and Windows.)

My main point is that once you commit to trying to do a project, you should be happy with the platform you've decided to implement on. Arduino is cheap and flexible which is why I suggest it. There are a lot of components out there for it as well, kind of like the Raspberry Pi, but that's higher level than I think you want. Also, if you're not used to implementing software in assembly or C without the standard library, you really probably want to start with something simple. Just my 2¢.

Edit: Let me give you an example. I once worked on a project that read a numerical keypad input. It was 4 bits (one for each column,) and another 4 for each row. You would assert a bit high on the row bits to access it to see if a button was pressed. You basically walk through the rows to figure out what the input is, however there is a catch. Due to capacitance on the data lines, if you don't wait long enough, the data line will still be high from a key press on the same column, but the previous row. The solution is to `nop` (no-op) for a cycle or two to let the data line transition. If you're not used to these kind of characteristics, then definitely go with the Arduino to learn.

 

[ArdWar]

I'm even more confused with you guys...

If you're going to brew your own microprocessor, almost definitely you don't need OS, not even BIOS. You're going to write your own code. Probably from scratch in binary/machine code since, depends on your architecture and instruction set design, no one made compiler or assembler for it yet. Forget interfacing with complex peripheral, you're likely going to bit bang your I/O.

If you insist on designing your own microprocessor, you better learn and familiarize how they actually work first. This is usually computer engineering graduate level of study (heck, they probably don't even teach such low-level engineering anymore than passing references, my uni actually teach it in electronics engineering).

Using popular simple microcontroller like PIC/AVR usually work best to understand how computer work. Even more basic uP/uC like MCS-51 or 8088 is even better. Try to make a simple program on them barebones without libraries, bootloaders and optimizations so you can relate the resulting binary/assembly code to what you actually write in higher level language. Take a look at the assembly code to figure out how a simple program is actually done at the processor-level. Also take a look at each opcode documentation to figure out how the opcode is actually done at logic level. How many cycles it requires, how it fetch instruction/data between memories/stacks/registers, how (depends on ISA) a complex operation is done using multiple simpler operation, etc. etc. After that you (probably) have a better understanding at what building a completely new processor architecture (and probably ISA too) entails. You probably will have a better question to ask too at that point....

IMO using Arduino in this context is kind of counterproductive since it doesn't teach you how to actually set up the peripherals and registers. It's good as *a* stepping stone tho. One other thing is that Arduino teach bad C/C++ programming style, but that's a whole other topic...

 

[Maissilapsi]

I'm even more confused with you guys...

If you're going to brew your own microprocessor, almost definitely you don't need OS, not even BIOS. You're going to write your own code. Probably from scratch in binary/machine code since, depends on your architecture and instruction set design, no one made compiler or assembler for it yet. Forget interfacing with complex peripheral, you're likely going to bit bang your I/O.

If you insist on designing your own microprocessor, you better learn and familiarize how they actually work first. This is usually computer engineering graduate level of study (heck, they probably don't even teach such low-level engineering anymore than passing references, my uni actually teach it in electronics engineering).

Using popular simple microcontroller like PIC/AVR usually work best to understand how computer work. Even more basic uP/uC like MCS-51 or 8088 is even better. Try to make a simple program on them barebones without libraries, bootloaders and optimizations so you can relate the resulting binary/assembly code to what you actually write in higher level language. Take a look at the assembly code to figure out how a simple program is actually done at the processor-level. Also take a look at each opcode documentation to figure out how the opcode is actually done at logic level. How many cycles it requires, how it fetch instruction/data between memories/stacks/registers, how (depends on ISA) a complex operation is done using multiple simpler operation, etc. etc. After that you (probably) have a better understanding at what building a completely new processor architecture (and probably ISA too) entails. You probably will have a better question to ask too at that point....

IMO using Arduino in this context is kind of counterproductive since it doesn't teach you how to actually set up the peripherals and registers. It's good as *a* stepping stone tho. One other thing is that Arduino teach bad C/C++ programming style, but that's a whole other topic...

For this exact reason, or the complexity of just 8-bit CPU grows so big, I may want to drop out couple thousand, or couple couple thousand, transistors from it.

Then even the processor units becomes "DIY'able" and could do everything as you want yourself ...which is currently the plan as well. With some number of about 80-100 bytes (that's just a guess as well at this point. Could 10x less or more) ROM chips with logic binary coded on them... Although using 8 or 16-bit mass produced chip would save a lot of work, effort and time, but it's not like there's a deadline or something, and it would increase the dreaded overall complexity even if 99% of capacity was unused.

Using time on one part gives time think through the next and sleeping over night or two after some idea you get idea that's evolved better from original after being critical to it instead of getting committed to half-a**ed one. But those mass produced chips would drive their purpose as ROM's

I don't really have a need for one either, but for how cheap they are it seems like an easy thing to impulse buy. The Uno Rev.3 is nice though because if you blow the chip, you can replace just the chip and not the board, even though the board plus chip is only something like $20 USD. That's a big plus if you're working with circuits and are running the risk of frying an input or something. Also, something simple like an Arduino that has a half decent IDE for writing and programming the board makes it a nice choice (their IDE works on Linux, OS X, and Windows.)

My main point is that once you commit to trying to do a project, you should be happy with the platform you've decided to implement on. Arduino is cheap and flexible which is why I suggest it. There are a lot of components out there for it as well, kind of like the Raspberry Pi, but that's higher level than I think you want. Also, if you're not used to implementing software in assembly or C without the standard library, you really probably want to start with something simple. Just my 2¢.

Edit: Let me give you an example. I once worked on a project that read a numerical keypad input. It was 4 bits (one for each column,) and another 4 for each row. You would assert a bit high on the row bits to access it to see if a button was pressed. You basically walk through the rows to figure out what the input is, however there is a catch. Due to capacitance on the data lines, if you don't wait long enough, the data line will still be high from a key press on the same column, but the previous row. The solution is to `nop` (no-op) for a cycle or two to let the data line transition. If you're not used to these kind of characteristics, then definitely go with the Arduino to learn.

Good reminder that slower binary processing speed creates more stable system and need to figure some kind of, most likely partly mechanical, solution for stopping everything from time to time and go through "self repair/searching sequence, or system check up" that lets it know where it's going in terms of, even if binary is big/little-endian actually, to everything like is it reading 0 as 0 and 1 as 1 which isn't technically problematic: just couple words with certain binary order, and if it's not, followed by some rebooting type of scenario.

...In general something that makes sure it can operate more than a 10 sec or so in changing environment and not just only repeating a function or two in precisely timed order

 

[Aquinus]

MO using Arduino in this context is kind of counterproductive since it doesn't teach you how to actually set up the peripherals and registers. It's good as *a* stepping stone tho. One other thing is that Arduino teach bad C/C++ programming style, but that's a whole other topic...

It totally does if you're writing your application in assembly, which I would recommend for getting started with a microcontroller with limited memory. In C, it's a bit different since the compiler makes those decisions for you. You also have to deal with the size of the C standard library and the amount of memory on the controller (it's not a lot.) You do still need to set registers to control how the I/O ports are going to behave though, so in that respect, it definitely teaches you how to do all of this stuff from scratch. You need to do these kinds of things if you're going to control clock speed via clock dividers and stuff like that, regardless of the language used to tell the controller what to do.

Good reminder that slower binary processing speed creates more stable system and need to figure some kind of, most likely partly mechanical, solution for stopping everything from time to time and go through "self repair/searching sequence, or system check up" that lets it know where it's going in terms of, even if binary is big/little-endian actually, to everything like is it reading 0 as 0 and 1 as 1 which isn't technically problematic: just couple words with certain binary order, and if it's not, followed by some rebooting type of scenario.

The chip that the Arduino uses can give you low power states and lets you divide the input clock to slow down the controller. There are also different power modes that enable and disable different parts of the chip. I think you'd find that the ATMega chip to give you a lot of the things you're looking for, just without a whole lot of resources to work with. Two 8-bit bi-directional ports for digital logic isn't a lot, but it's enough to get going. The controller handles the rest for you and all you need to do is utilize it. So depending on how far you want to go with a project, it might be a nice place to start. Otherwise, you're looking at one of those ARM-based dev kits which are a lot more complicated to work with, have different voltage requirements, and cost more.

All in all, it's easy to throw $20 USD at an Arduino to get started. It's a little harder to justify when that price goes up before you really have a plan for how you want to proceed with this project, otherwise you wouldn't be asking us for guidance and would have began already.

 

[skizzo]

this shit is over my head, but I the overall scope of the project sounds a bit like "The 8-Bit Guy" project he called the "Commander X16"

Commander X16 - Index page

www.commanderx16.com

 

[ArdWar]

It totally does if you're writing your application in assembly

At that point you're programming an ATMega (which I do recommend), not Arduino.

sounds a bit like "The 8-Bit Guy" project he called the "Commander X16"

That's more like system integration.

 

[Maissilapsi]

All in all, it's easy to throw $20 USD at an Arduino to get started. It's a little harder to justify when that price goes up before you really have a plan for how you want to proceed with this project, otherwise you wouldn't be asking us for guidance and would have began already.

It is still in planning stage, nothing been decided yet either. I start drawing ISA etc once the cursed tube connectors, kind of ones you can unplug and liquid stays in, arrive (not even in storage yet) and I can put my desktop PC together...

this shit is over my head, but I the overall scope of the project sounds a bit like "The 8-Bit Guy" project he called the "Commander X16"

Commander X16 - Index page

www.commanderx16.com

There's some interesting stuff, like entire specification section and I given zero thoughts for the specs of this "device", well it's definitely going to become an object. (subject to change) When I got this idea I was reading about C64 architecture and felt so simple at the time but there's just stuff piling up on top of each other further this goes it might reach a point I'll really throw my hands up and agree to: "F*** this. I rather build a sandcastle".

But then I see these specs and feel relieved:

Commander X16P Features & Specifications (subject to change)

CPUWDC 65C02S @ 8 MHz40-pin DIP package
Protoype board currently running stable at 8 MHz
RAM40K of "Low RAM":As 39.75K + 256 bytes of IO space
8 IO spaces of 32 bytes each; one for the VERA, one for the VIAs, one for the audio
512K of "High RAM" standard:As 64 banks of 8K
Expandable to 1 MB, 1.5 MB, or 2 MB by adding additional RAM chips to 3 empty sockets
Up to 256 banks of 8KROM
512K of Flash ROMAs 32 banks of 16K (TBD: Could be expanded to 128 banks RAM or ROM)
Standard Commodore Kernal
Microsoft BASIC version 2.0

 

[Aquinus]

At that point you're programming an ATMega (which I do recommend), not Arduino.

I'm not following. An Arduino Uno uses an ATMega328P. You're programming that regardless of the language you're using because that's the chip that drives it, so your statement confuses me. If you use that board, you're programming a ATMega chip, period. There is really no difference between using the chip standalone and using the board when it comes to how it's programmed and how it operates.

 

[ArdWar]

I'm not following. An Arduino Uno uses an ATMega328P. You're programming that regardless of the language you're using because that's the chip that drives it, so your statement confuses me. If you use that board, you're programming a ATMega chip, period. There is really no difference between using the chip standalone and using the board when it comes to how it's programmed and how it operates.

There's quite a distinction between programming using Arduino compiler/bootloader and programming barebones/using standard C lib. While the result may be same/similar, the former hide a lot of the finer details of setting up the uC and peripherals.

 

[Ferrum Master]

There's quite a distinction between programming using Arduino compiler/bootloader and programming barebones/using standard C lib. While the result may be same/similar, the former hide a lot of the finer details of setting up the uC and peripherals.

You can bypass any of the compiler stuff and put your code in assembly... it will produce the same result.

Sometimes it is even needed due to compiler bugs.

 

[Aquinus]

There's quite a distinction between programming using Arduino compiler/bootloader and programming barebones/using standard C lib. While the result may be same/similar, the former hide a lot of the finer details of setting up the uC and peripherals.

That's fine for someone who is learning how to do it. We're not talking about an experienced embedded engineer here. You also won't have much memory for your application if you load up the standard C lib. That takes up a lot of space for a controller like that. There are a lot of good reasons to write your application in assembly when your memory constraints are tight.

 

[ArdWar]

You also won't have much memory for your application if you load up the standard C lib.

Of course not the entire library (nor the full functionality of the ISO standard C either, I guess). You're not going to do any fancy math or string operation in a MCU like this.

That's fine for someone who is learning how to do it. We're not talking about an experienced embedded engineer here.

I see this as two-stage process here. First is to learn how to program a simple MCU (which programming in Arduino helps), and second is to learn how a MCU work (which programming in barebone helps). I'm referring to the end goal of "building custom SoC" here.

There are a lot of good reasons to write your application in assembly when your memory constraints are tight.

Programming in assembly of course come after you're familiar with the MCU/ISA. For most project, something like avr-gcc is just fine.

 

[Maissilapsi]

I was looking model for arithmetic logic unit schematics and simplest I found was this (from Wikimedia Commons). It's from first complete ALU on one chip and used in first PC's, 4-bit 74181 chip has 75 gates packaged on 24 pins DIP.

It's doable using loose flip-flops etc, "not a big deal" but it's some kind of deal at least...