I decided to make a graphics card for my Amiga 2000
github.com
github.com
I think if you set a goal like "build x for y" and struggle through it, learning as you go, you'll learn faster because you skip all the stuff you don't need (because you literally didn't need it to hit your goal). And think of all the money you'll save!
Skip college. And if you already went, don't go back!
Assuming that nobody can predict the future, how can anyone know the usefulness/uselessness of any knowledge?
It's at least as good a heuristic as "prof said it's important".
Most people are not great autodidacts, as shown by the miserable cometion rates of online courses.
For me (though I consider myself as a pretty good autodidact) the reason why I didn't complete many MOOCs (before you had to pay to even get a certificate) was simply lack of time: My main "job" is completing a PhD in applied mathematics, so if there happened anything for my PhD work that required some time-intense intervention (say, I found out that my proof idea didn't work so well as I originally thought; or if the advisor got the idea (which does not mean that it was always a bad idea, just to be clear) that I should read up more papers in some specific area - also very autodidactic) I sometimes had no other choice than stopping some MOOC that I was attaining.
My primary argument against college is mostly money at this point. The alternatives are so much cheaper in comparison to traditional college (both to produce and consume). The difference-in-quality argument is weaker and weaker.
I don't think free college for everyone fixes this either. It's like trying to solve the transportation problem by buying everyone ferraris. Free college is only good for colleges.
College is just a bad deal. A lot of people already realize this, but the idea of going to college if you care about your career at all is very firmly entrenched. 10-20 years from now, we'll look back at this period of going into debt just to get an education as being super weird and counterproductive. The people pushing the idea that this is somehow a good deal, very respectable people from respectable institutions, will be viewed as sub-prime pushers.
Way OT: Student debt, the war on drugs, prison, and medicine. These are the (US-centric) areas off the top of my head where people in the future will be like "what were they thinking?"
Yes and no. I had troubles in college every now and then because it interfered with my learning. That is, as soon as I found something more interesting to learn by myself I tended to quit paying attention to classes. It was similar in school too. But I owe it my career - all things programming was what I was doing instead of school assignments.
Once I had to spend significant effort on my assigned work, I felt like I had to use my free time for leisure or I'd be wasting it. Plus any time I felt enthusiasm to learn something else, I'd feel like I ought to be spending that effort on my assigned work instead.
But there are a few others too; here is someone who made an entire SoC (including CPU, GPU, and audio --- all of his own design) on an FPGA, plus wrote the software to run on it. And this is apparently his first FPGA project:
This approaches Woz level engineering, if not 100% technically, at least philosophically.
In other words, the Internet is a multiplier that applies to the incredible curiosity and enthusiasm and intelligence of bright kids. So, multiply your 10x (or whatever #x) nerd by the 10x (or probably much greater multiplier) of the Internet, and you get the world we're living in now. Amazingly, the multiplier will likely continue to increase over time. I don't know if it will accelerate in a way comparable to the Internet coming along (I mean, we had centuries between early really big knowledge multiplier leaps), but it might.
We live in amazing times is what I'm trying to say, and I'm genuinely jealous of kids coming up today, despite some minor caveats. I was bright and curious, and lucky enough to have access to a computer (C64 first, later C128 and Amiga 2000), but the access to knowledge was still quite limited. Internet didn't come for me until I was an adult. Internet and a boundless curiosity and practically unlimited free time is heady stuff.
But my kids? Despite being "digital natives" don't even really know how to use computers. (Yes my failure as a parent, but also indicative of the environment.)
Personally I grew up reading Dr. Dobbs, Byte Magazine, a slew of Amiga journals and Scientific American. I probably started reading the latter at a point where I understood maybe 40% - but it was a great way to learn English.
On the plus side, you can now go and play with and read the code from the likes of Bernstein, Percival, Torvalds and things like the entire Solaris system. And there are great resources, like the Arch Linux wiki, the FreeBSD documentation and dev/user lists. But the good stuff is increasingly hard to discover in an ocean of mediocre stuff. And I have yet to find any good canonical resource for "the good stuff". One of my biggest disappointments with college was that academics appear to be doing a terrible job of keeping up to date, or helping students seek out good extracurricular resources, despite the fact that these resources keep growing and growing.
I hope that the trend toward open publishing of research will continue, and maybe see some sister-resources in the form of free popular science resources pop up -- I could easy imagine universities and research institution pooling resources in order to help researcher edit and publish popular science articles in addition to their standard papers -- as a combination of general science education, and to rise awareness/advertise research.
Have you considered books? For example, this book is shaping up to be the canonical tutorial for Haskell:
I do think it's important to point out that there are a lot of open books out there, facilitated by the web, like the haskell-book. But there's always been good books, it's not enough with out good librarians.
My first set of magazines were the Input series, a British monthly magazine about coding for 8-bit systems.
I invested the majority of my allowance in such magazines, "The C User's Journal" (later C/C++ User's Journal), Dr. Dobbs, PC Techniques, GDC Mag and lots of books.
Luckily my university being highly focused in systems programming, had a huge collection of books and SIGPLAN papers, which opened my eyes for the world of safe systems programming. Thanks to it I was able to delve into the work from Xerox PARC and ETHZ, as well as, the research that was happening with ML (Caml Light was rather new back then) and Prolog.
Input was a great series.
http://store.curiousinventor.com/guides/Surface_Mount_Solder...
- With practice we can go down to surprisingly small components. It's less about precision work and more about having an intuition about heat flow and surface tension which let the components align themselves.
- When components are too small or simply impossible (or it is beyond my knowledge) to solder with an iron, we can always just use an oven :) Which is entirely reasonable to do either at home / in the garage as they can be build very cheaply, or locally at a friend's or a fab-lab type deal.
So, as I'm reading this, I'm surprised how nonchalantly he describes what looks like a ton of headaches that's in front of me personally. Doing some basic stuff in Verilog on an FPGA is straight-forward. What he's done was not unless he found some excellent resources that basically let him cheat a lot in the learning. I'd be interested in them as I'm collecting resources with HW knowledge and wisdom.
Electronic Principles 8th Ed Malvino http://www.amazon.com/Electronic-Principles-Albert-Malvino/d...
Note: Look up the 2nd edition or something as I got it for $2. Principles of analog don't really change. Super-easy to read with more heuristics & diagrams than theories. I didn't know until today it was being updated.
Circuit Designer's Companion... for free! http://diagramas.diagramasde.com/otros/The%20Circuit%20Desig...
Note: High-assurance engineer told me this guy was a master and this book is all-in-one most of what you need to know. A reviewer said it's mostly for digital, not analog, stuff but that's probably your goal.
Digital stuff is highly opinionated on whether it's "good" or not. So, read the reviews to determine if it's good for you personally.
http://www.amazon.com/Digital-Design-RTL-VHDL-Verilog/dp/047... http://www.amazon.com/dp/0131678442/?tag=stackoverfl08-20
Note: These were said to be nice for beginners on Verilog, etc. Good tutorials online, too, with practice code and help on StackOverflow. I suggest getting a simulator and/or cheap FPGA then just experimenting.
http://www.amazon.com/dp/1461186293/?tag=stackoverfl08-20 http://www.amazon.com/dp/0470054379/?tag=stackoverfl08-20
Note: First is a cookbook for FPGA designs. Second covers things like floorplanning and resets.
http://www.amazon.com/Digital-Systems-Engineering-William-Da... http://www.amazon.com/VLSI-Test-Principles-Architectures-Tes... http://www.amazon.com/Comprehensive-Functional-Verification-...
Note: Books on Digital System Engineering, VLSI testing, and functional verification to top it off.
Endnote: I don't guarantee quality of any of these except Electronic Principles and Circuit Designer's Companion. The rest just had positive reviews plus what I assessed to be decent information for their target topics.
If you need to know about design, read application notes from manufacturers. There are thousands and thousands. Often they will dictate how you should route a particular component. You can look at reference boards from people like Analog, which typically come with schematics and layout files. Most of the big name companies have guides for layout:
https://www.google.co.uk/search?q=pcb+design+application+not...
What you will quickly find is that there's a lot of differing opinion on what is "right". Until you need boards with high speed digital/analogue/mixed, you don't really need to worry much about how things are laid out. You will almost always be constrained by more practical issues like enclosure sizes or where you have to put connectors.
"If you need to know about design, read application notes from manufacturers. There are thousands and thousands. "
I'll try to remember that.
"You will almost always be constrained by more practical issues like enclosure sizes or where you have to put connectors."
I'll definitely believe that. Thanks for the tips and different perspective.
* PCB with poorly aligned copper layers shorting the second the prototype is plugged in, usually destroying at least one chip. Lots of smoke and burning FR4
* Solder in $100+ high power transistors the wrong way. BOOM
* Using a counterfeit capacitor from shady vendor that either shorts internally or just plain explodes. Happens a lot when I need a really large capacitor and have to get it on short notice
* Forget to use a little extra flux and tin 'whiskers' form between freshly soldered pins that short them the second the device is powered up. This is so common that NASA has a whole website dedicated to the topic [1]
* Use wrong temperature profile or make the pin layout a thousandth of an inch too small or large and bam, two solder balls on a BGA flow together, requiring hours for reflow and reballing if you're lucky, and a new $2,000 FPGA if you're not.
Any nontrivial circuit is going to be impractical to simulate (and impossible to describe analytically as a whole) for all but the most well funded projects so I'd say 90+% of EE is trial and error, even for the most experienced designers. There's many rules of thumb and you develop an intuition for a wide variety of situations just like you do in programming, but it's just a fundamentally different field with different constraints.
https://news.ycombinator.com/item?id=11515190
Any thoughts on them? Particularly, a combo of something like Malvino and Circuit Designer's companion to get a good head start on analog and PCB's respectively. Or do you have other references that kick ass in teaching practice more than theory? Gotta build up links for new people to accelerate hands-on part of their learning just like others did for programming.
Note: Art of Electronics is usually in my list but that link was for digital learner. Not sure if it's needed there.
1. Enough knowledge to get designs working on a FPGA plus integrate that with other chips on a PCB. OSS HW with minimal analog.
2. Enough knowledge to design basic analog circuits for control and stuff. Alternatively, to design digital cell libraries as there's almost nothing available for academic toolbuilders.
3. The serious, mixed-signal shit that lets me do some parts in digital and some parts in analog where it handles it better. I've seen analog coprocessors with 100x performance at 1/8th power on ODE's and stuff. It also seems like certain signal processing or media codec tasks would be crazy fast/efficient in analog. I know high-end ASIC's make extensive use of such techniques. What tidbits I see in blog comments and papers can only be described as black magic without a more thorough resource. :)
4. RF books outside of ARRL that's been recommended to me. Need a lot of people experimenting with this stuff to reinvent things like TEMPEST that are classified. They need some good resources to get head-start.
So, those are some basic categories where I'm looking for both accessible, foundational material and cookbooks with heuristics. Being able to combine COTS components like MCU's and FPGA's on custom PCB's is major help to hobbyists. Being able to make the cells and basic, analog components required in about any ASIC in conjunction with tools like Qflow OSS Synthesis could get custom stuff going quicker. More thorough stuff for mixed-signal for its advantages plus to explore analog and digital interactions in digital systems that can screw either up. And RF for reasons stated.
Whatever you have. Drop it here or email it to me in my profile address. I'll keep circulating that along with others tips and resources whenever people ask.
I've never had electric shocks before, but frying components sure. Don't work with mains voltage directly if it worries you. You can power most hobby projects from a USB port or a wall wart. Designing power supplies is one area where you might want to read up on things like trace clearances, but again, look at YouTube for PSU teardowns (bigclivedotcom has plenty).
As always it's mostly human error. I have never (literally) fried a component from overheating, it still amazes me how hardy modern ICs are. I've also never paid too much attention to ESD protection, though if my job depended on it then I would. What has happened is shorts, often. Even the GPU guy routed his board with GND and VCC back to front, it happens to the best of us. Most chips are at least partially tolerant to silly things like overvoltage, so even if you accidentally short some GPIOs on a micro, the protection circuitry might save you. Simple advice is to put a low-current polyfuse on every prototype you make. It's saved me so many times when I've shorted power supplies by accident.
The more complicated your circuit, the more likely it will be that you mess up. Don't try and solder a 150-pin BGA on your first board. Build some breakout boards for sensors, build your own microcontroller dev board (ARM if you want a challenge) or pick a project from the internet.
Odds of messing up you first board in some subtle way? Unless it's a very simple board, > 80%? Components are cheap though, roll with it! Plus you probably won't brick all the components if something goes wrong, the magic smoke will usually only come out of one.
When I make mistakes, usually they're footprint (e.g. wrong pinout) or construction errors (shorts between pads, etc). If the schematic is incorrect then that's another issue, but most often it's things like not reading a datasheet properly and forgetting to connect a pin, tying an positive-enable pin to GND rather than VCC, etc. In principle layout engineers assume that the circuit diagram is gospel, so the blame doesn't always lie with them. Of course if you're the designer and the layout engineer...
I'm now at a stage where I can get a board back from the fab and it'll usually work :)
How expensive trial and error is depends on your experience. When I'm done with using a board or have some old electronics to throw away, whether I bricked it or its obsolete, I always throw it in a pile. When I have time I just go through and desolder each nontrivial part because it helps build an intuition for how each type of solder will respond to heat and flux, how wick looks as it absorbs solder and how to move it to get all the solder without overheating the chip, and so on. You need to develop that muscle memory like a surgeon would because once you're good enough you can do crazy things like snake a tiny wire under a BGA chip under an xray to fix flaws in the design or reflow. In more expensive designs I'll regularly take small gauge wire and solder it all over to fix the design as well as cut traces or lift copper layers after stripping the FR4.
Hand assembling electronics is largely more craft than engineering.
What's lacking (or I've yet to find) is a simple tutorial-type progression that explains both how, and why, to do certain things, especially when it comes to things like component selection, footprint design, part layout, and actual track routing.
The "try it, make mistakes, learn" approach is almost inevitable, but the cost/time of the feedback loop can be pretty steep for a hobby (you can have 24-hr turnaround on boards if you've the $$$, or you can pay $5/board in 6-8 weeks, but the middle ground is tricky and messy. Plus all teh different board houses might have different design rules and other things that complicate matters for beginners.
My suggestion would be to find some Open Hardware kits or designs, buy a couple to make them, but also get the design files (hopefully in either kicad or eagle, which are free/affordable, and then start by ripping up all the routing, and seeing if you can re-track all the components get get it to pass ERC/DRC checks. Maybe bounce it off a few people in /r/askelectronics or eevblog forums, and then have it sent out for fab. If it works, pick a new OHW project with harder things, and repeat :)
That saves you from having to deal with footprint, schematic capture, and BoM decisions initially, and focus just on teh board design parts. You'll want to get there eventually, and you can learn a lot from how other things are put together.
Maybe pick some simple circuits (basic CMOY headphone amp, say), and redraw the schematic in your EDA tool. Then gather up teh datasheets, and usually they'll have a recommended footprint drawing, and you can learn how to build those in your toolchain.
There are some open libraries of component footprints (I think sparkfun has one? Maybe octopart as well?) but it's a useful skill to learn, and easiest on little things with few pins before you work up to the 192 pin FPGA or something :)
* Always print your designs 1:1 scale before sending out for processing.
* Always check your design file outputs (gerbers) in an external viewer to make sure they look ok/make sense.
* Remember to flip top/bottom layers the right number of times! This should happen properly on export, but it's easy to screw up and have the perfect board if you can find components with the exact opposite pinouts :)
* Don't be scared of starting with surface-mount. You can usually get things in pretty big packages if you want, and an 1812 or 1210 is actually not far off the size of a normal resistor body (minus the leads). You can go smaller as you're comfortable and pick up technique.
* I can't really offer any layout tips, because I'm still not very good. If anyone has pointers to good docs on: (a) how to decide where to place/orient your components on the board to begin with, (b) choosing placement/routing grid sizes and track widths/via sizing, (c) appropriate layer count/usage - when to add more layers, value of pwr/gnd planes, use of fills, etc. And lastly, with kicad especially, how to fix things when you've routed yourself into a corner with just a few pins left, but no way from A-B (preferably without either adding layers, or through-hole links. I know about the 0R resistor bridge, but it has its limitations.
http://diagramas.diagramasde.com/otros/The%20Circuit%20Desig...
Lucky enough to find a free link. I want to see if your skimming shows that it would've taught any of the types of things in your post or some of the stuff you're trying to learn. Trying to gauge it's value in accelerating the trial-and-error process.
"The "try it, make mistakes, learn" approach is almost inevitable, but the cost/time of the feedback loop can be pretty steep for a hobby (you can have 24-hr turnaround on boards if you've the $$$, or you can pay $5/board in 6-8 weeks, but the middle ground is tricky and messy."
That's exactly my problem. A lot of smart people don't have the money for that crap. So, it seems the experimenting is inevitable, yet it's worthwhile to try to determine exactly what experiments with what components teach the most lessons for minimum dollars. At the least, good references that tell you heuristics for avoiding the worst issues. The other commenter listed a few I had never heard of that involved "BOOM's." It's 2016 and we still don't have comprehensive, accessible guidance on reducing explosions? Really? Haha.
Board preparation, obviously, also is a breeze - once you've drilled holes for your vias, just place the board in a vice and off you go.
Also, added bonus when it comes to passive components - rather than having those pesky color bands (annoying for the chromatographically challenged among us), values are typically stamped on the components using numerals - so less chance of making a mistake.
Learning Verilog isn't like learning another programming language - it's an entirely different (though related) field of endeavor.
We have a mandatory course for all CS students at my university where we have to design a full DLX processor in VHDL and run it on a simulator. Just so we can understand how these things work.
So, the average CS graduate from the uni where I am should be able to do this.
And this is just a normal university, I’d expect that the universities with better reputation are doing this on a completely different level even.
Btw, you're the first person I've seen mention DLX in a while. Feel free to pass this along to any you still know teaching that or working with it as they might find it interesting. It's a mathematically-verified, DLX processor from Verisoft project that's languishing in obscurity (that I'm aware of) rather than being exploited (or cloned) for its benefits:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.217....
http://www.verisoft.de/PublicationPage.html
Minor modifications like crash-safe.org for security with a RISC-V decoder in front & ChipKill ECC might make one, badass CPU in embedded use. Probably good for learning & OSS HW tweaking, too.
It is usually called Software Engineering in Informatics or something similar.
In the universities where you have computing and EE degrees, you are free to mix and match computing and EE lectures for the optional credits that you need on top of the compulsory ones.
Personally I just did some stuff of digital design and ended up spending the rest in systems and graphics programming. But other others were focusing in EE lectures, for example.
He designs circuits and writes firmware code for a living.
[1] http://am.renesas.com/products/mix_sig/graphic/index.jsp
On the other hand, FPGAs are still complicated pieces of hardware, similar to what a CPU is for normal programming.
It's not like anybody could make an FPGA by themselves in their basement in any reasonable amount of time, with limited resources.
http://semiaccurate.com/2015/11/18/arm-charts-path-printed-p...
With this, a homebrew FPGA would become a reality. As well as homebrew ASICs in general.
Story of my life. I had an Amiga, got rid of it. Had an H-11, got rid of it. Had a Digicomp I and II, mom got rid of them. All worth a big pile now.
My basement is full of old computers I stuck down their as I upgraded. All worthless :-)
I have an unerring ability to get it backwards what will be a collectors' item and what won't.
I'm sometimes surprised by lack of options for a small, cheap GPU that could be readily integrated into a design like this. There's seemingly a big gap between the classic VDP chips like the TMS9918 and its successors (which AFAIK have all been out of production for ~20 years) and modern GPUs that come in monster BGA packages, call for super-fast external RAM and dedicated power supply circuitry on 6+-layer boards, and can't be bought through mortal-friendly channels anyhow. FTDI has the FT800 series, and I'm sure there are still suppliers of S-PPU (the SNES graphics hardware) clones if you know who to talk to in China, but other than that it seems like the options are:
1) Roll your own in an FPGA, like this project
2) Get a fast, preferably multicore microcontroller with suitable I/O and program it to do rendering in software (maybe a Propeller, GA144, or some XMOS chip?)
3) Buy your GPU attached to an ARM core (i.e. Allwinner, Rockchip, Freescale i.MX, TI OMAP/Sitara, etc.) and program it to speak some GPU-oriented protocol (which probably adds a considerable amount of latency, since you'd realistically need to use the Linux drivers)
Then NVidia bought the company.
http://codehackcreate.com/archives/30
"F18A stands for “FPGA TMS9918A” (hence the project’s title) and will be 100% hardware and pin compatible replacement for a TMS9918A VDP (video display processor)."
http://mmix.cs.hm.edu/index.html
There are books, courses, homework, and lots of free resources -- in particular, emulators.
Then find a project that interests you, and learn what you need to do for that. 68000 assembly? Forth? Graphics on a VGA card emulated in a VM running MS-DOS? All of these things are entirely do-able.
Or find a project that is already in development and contribute to it. The important bit is your own motivation.
Even simpler: Install Visual Studio 2015 Community (the current version) and run the "VS 2015 x86 Native Tools Command Prompt" or "VS 2015 x64 Native Tools Command Prompt" (under Windows 7 in the Start menu under "Visual Studio 2015" -> "Visual Studio Tools" -> "Windows Desktop Command Prompts").
Now simply run
ml
ml64
There's GNU as (gas), which I've used quite a bit, but wouldn't really recommend because it uses strange "AT&T" syntax rather than the syntax you'll find in the Intel manuals. gas is also meant more as part of the GCC pipeline than as a standalone assembler, so even though it can function as one, it's not necessarily nice as one.
I've been meaning to play around with the LLVM assembly language. It looks neat, with the bonus of being reasonably portable, but I haven't yet found the time.
HLA (High Level Assembly) by Randall Hyde seems like an interesting way to slowly lower yourself into assembly language programming, but that's not how I cut my teeth, so I can't speak to its effectiveness.
All AT & T syntax is, is
move src, dst
rather than intel's
move into dst, src
as far as I know, intel is the only company which did that, and to me, it is intuitive to move something somewhere, rather than to somewhere move something.
You only see it everywhere nowadays thanks to the rise of GNU/Linux and other open source UNIXes.
If you translate mov into =, the syntax makes much more sense than AT&T.
I mean
mov dst, src
is similar to
dst = src
I'd be a little bit more careful with such a statement: Under Windows (and formerly DOS) Intel syntax is the common one, while under GNU/Linux and OSX the AT&T one is used.
> If you translate mov into =, the syntax makes much more sense than AT&T.
Though I prefer the Intel syntax, I'd be careful with "makes sense" here: According to http://stackoverflow.com/a/4119217/497193 people who grew up with MIPS seem to prefer the AT&T syntax since it is much more similar to MIPS assembler.
Only UNIX based OSes follow AT&T, for obvious reasons.
No, intel is an exception, not the norm. Amstrad, Atari, Commodore 64, Amiga, Sun (both Motorola and (Ultra)SPARC) all use "move src, dst", $ or 0x... only intel diverges from the norm.
In Intel syntax instructions are not suffixed. In AT&T there is a suffix (q, d, w, b) depending on the operand size. For example (assuming 32 bit register) mov (Intel) gets movl (AT&T). Also the argument order is changed. Constants have to be prefixed by $. Hexadecimal values are prefixed with 0x instead of suffixed with h. Registers are prefixed with %. With this we already have
mov eax,1
mov ebx,0ffh
movl $1,%eax
movl $0xff,%ebx
mov edx, [ecx]
mov eax, [ebp-4]
mov eax, [ebp-4+edx*4]
lea eax, [eax*4+8]
lea eax, [eax*2+eax]
movl (%ecx), %edx
movl -4(%ebp), %eax
movl -4(%ebp, %edx, 4), %eax
leal 8(,%eax,4), %eax
leal (%eax,%eax,2), %eax
mov [ebx], 2
mov BYTE PTR [ebx], 2
mov WORD PTR [ebx], 2
mov DWORD PTR [ebx], 2movl -4(%ebp), %eax
is intuitive to me. On the Motorola MC68000 family, it would have been
move.l -4(sp), a0
so I can hit the ground running with AT & T syntax.
The first time I saw
mov eax, [ebp-4]
I wanted to take a hammer and beat the idiotic IBM PC tin-bucket into oblivion. Did the square brackets have any special meaning? Who the hell knows! What do they mean?!? Completely unintuitive.
With AT & T syntax, I can even hit the ground running reading SPARC assembler:
mov 5, %g31
moves five to global register 31. Perfectly logical and intuitive, and I didn't even have to know anything about SPARC assembler.
Then there is the deadbeefh instead of $deadbeef or 0xdeadbeef syntax. Everybody else either used $deadbeef or 0xdeadbeef, but not intel, oh no! intel just had to be different. Irritating to no end. Again, taking a hammer to the PC bucket was a temptation...
Only intel could come up with something which does not relate to anything.
This is wrong. You have to remember that the 8086 is (mostly) source code compatible to the 8080 (at least if you rename some registers - a simple search & replace) - though not binary compatoble. The assembler syntax for the Intel 8080 that Intel developed is ugly. But Zilog who developed the Z80 (which is binary compatible to the Intel 8080) devised a much better assembly language (as far as I know they had to use a different assembly language for legal reasons). For the 8086 Intel built on the ideas behind Zilog's assembly language. In Zilog assembler
(HL)
(IX+index)
(IY+index)
EDIT: Also the parameter order dst,src is the same as in Z80 assembler (but this order was already used in 8080 assembler so rather Zilog copied this order from 8080 assembler).
TLDR: The Intel syntax is related to Zilog Z80 assembly.
Documentation is readily available, along with source code to a number of classic games. There are several emulators and even a small community of people turning out new games for the platform.
The 2600 was/is quirky, and of course it's ancient history, but it does provide a path to learning some basics that still apply today. Most importantly, it's fun.
Start here as a resource - http://www.atariage.com/2600/programming/
These pale though in comparison to the two Amiga Rom Kernel Manuals and the Amiga Hardware Manual. [1] These were sold in the computer section of the shopping mall bookstore back in the day, and even today provide a detailed explanation of a multi-tasking operating system and simple graphics programming.
[Edit] Part of the reason why people continue to hack on it is because it is practical. The this-is-how-to-turn-it-on-and-use-the-mouse Introduction to the Amiga 500, it had schematics in the back; pinouts for all the ports; and pinouts and block diagrams for the important chips.
[1] https://computerarchive.org/files/comp/books/amiga/Amiga_Har...
Coursera has a course called the Hardware Software Interface [1] which covers the same material if you want lectures and forums and the other benefits of a MOOC.
"Say hello to x64 Assembly, part 1" https://news.ycombinator.com/item?id=8245581
(Incidentally, I did a fork of the early stuff just to see what it would look like with gas syntax - the standard for gcc. Now that there's more code in the parent repository, maybe it's time to revisit): https://github.com/e12e/asm/tree/gas-syntax/hello
Another quick intro to 64-bit assembly: https://cs.nyu.edu/courses/fall11/CSCI-GA.2130-001/x64-intro...
A book (I haven't read), but looks ok, from a quick glance at the examples: http://rayseyfarth.com/asm/
http://www.amazon.com/Introduction-Bit-Assembly-Programming-...
For a long time, the best resources were (arguably still are) for 32 bit x86 assembly -- but IMNHO it's rather unpleasant in terms of segmented memory, limited registers, and the C call abi is also a bit "clumsy" if you want to work in assembly as much as possible (again, this has to do with limited registers). That said, Randall Hyde has some great resources on 32 bit assembly:
http://www.plantation-productions.com/Webster/
An older resource, for 32bit assembly: http://www.drpaulcarter.com/pcasm/ I have an old print-out of this on my bookshelf - it's a pretty straight-forward introduction to how one might go about to combine C and assembly. It'd be great to see an updated version for 64bit though.
An operating system in assembler. 32bit version GPL, the 64bit version is as far as I can gather under a more restrictive, source-available license:
Then there's BareMetal Os (I couldn't find any License.txt): https://github.com/ReturnInfinity/BareMetal-OS
There's also a wiki on OS dev: http://wiki.osdev.org/X86-64
I would recommend going through the first tutorial listed above, to get a feel for things. Assembly can be a lot of fun - but I think you'll in general will have a hard time doing better than gcc/clang if speed is your goal. Still useful for stuff like boot loaders and such. If you want to play with OS/boot-loader development, it is easier now than ever before thanks to emulators like Qemu: http://wiki.qemu.org/Main_Page
I found host read timing to be significantly harder to
get right, and it's still not perfect. Host reads can't
be put in a queue and have to be processed immediately.
This interrupts the fetching process; if the host needs
to read from a totally different memory location then
the display engine is fetching, the SDRAM has to close,
refresh and reopen rows, which is a time consuming
process. So far, reads from the host cause temporary
distortions (glitches) in the display output. I plan to
mitigate these problems using either burst mode reads
and fast switching and/or inserting CPU wait states via
the XRDY signal.
In other words, instead of tackling the problem with 1988-era engineering, take advantage of the free parallelism and essentially infinite (from a 1988 perspective) memory that you get with an FPGA board today.
Hell, there's probably enough BRAM on that Spartan6 to implement an Amiga frame buffer.
Nowhere near enough. Spartan-6 LX25 has 936 kbit of block RAM; 800x600x16 requires a little under 8 Mbit without double-buffering.
Read glitches happen when two reads collide, and without any delay mechanism you need to choose which one to drop on the floor. What you do to solve this is implementing busy wait on external bus (/DTACK on amiga), you can also read ahead video output data in chunks (think filling cache line using SDRAM Burst mode) giving you more memory controller time in between.
This is why back in the day different graphic cards delivered different Doom1/2/quake1 fps, while intuitively there should be no difference games being software renderers.
here is a sweet little article By Michael Abrash about vga isa bus hardware optimizations http://www.drdobbs.com/ramblings-in-real-time/184410037
I'd love to hear what tricks you (author), or anyone else, has for making free time to explore side projects. I'm finding it harder and harder to contain work coding; it seems to consume all available time!
So, compare to the Pi, what information is present, anyone know?
I always wanted to do hardware work back then, but never quite had the right opportunity going through school.
So cool to see this, that a500 was how I learned so, so, much about computers that I love that it's still a tool for people to learn with.
Thanks for sharing your work! This is awesome.
Whole journej from building simm based 74 logic driven ram expansion to 50MHz turbo card:
http://amigaprj.blogspot.com/2013/05/amiga-fast-ram-expander...
http://amigaprj.blogspot.com/2013/06/amiga-500-ide-controlle...
http://amigaprj.blogspot.com/2014/09/8-mb-fast-ram-expander-...
http://amigaprj.blogspot.com/2015/04/scandoubler-ecs-for-a50...
http://amigaprj.blogspot.com/2015/06/amiga-500-68hc000-14-mh...
http://amigaprj.blogspot.com/2015/06/amiga-500-14-mhz-accele...
http://amigaprj.blogspot.com/2015/07/amiga-500-28-mhz-accele...
http://amigaprj.blogspot.com/2015/07/amiga-500-accelerator-c...
http://amigaprj.blogspot.com/2015/09/hc508-amiga-500-68000-5...