A few years back some really smart guys figured out how to make optical diodes. That means optical computers, that means really really fast computers. They said the problem was the the size of the diode was on the order 400nm as opposed to todays transistors being around 40nm or so. What did I think? Screw that! I'll take a 1 THz 6502 over all these bloated multi-core pipeliney chips any day of the week!
I hadn't heard about super fast optical transistors, but a few months ago I was reading about ultra fast transistors that operate at 600GHz.
The idea came to me, to write a x86 emulator in 6502 assembly. Run it on a 6502 CPU built using ultra fast transistors, and boom, you've got a faster x86, just it's an emulated x86, MMU and all!
Typical 6502 instructions take 2-8 cycles if I remember rightly, so as long as it takes under 200 6502 cycles to emulate one x86 instruction, you're beating a 4GHz x86 processor.
I'm sure there are practical problems that make it difficult or impossible in reality. But still fun to think about. :)
- 3 8bit registers vs. ~8 32bit or ~20 64bit registers. (so you're essentially working on memory at all times, and have to emulate all "longer" commands, such as addition, to do 4-8 carries manually)
- 64k of memory (which includes the emulator), so you need to add some banking mechanism.
- no support for integer multiplication/division or even float/SIMD in your instruction set.
But you probably can provide a fast implementation of the decimal addition instruction :-)
Love it! The 6502 was the first assembly I ever learned. I still remember a handful of opcodes from all the hand-assembling I did:
a9 44
20 ed fd
a9 41
20 ed fd
a9 56
20 ed fd
a9 49
20 ed fd
a9 44
20 ed fd
60
About a year ago, in a fit of nostalgia, I wrote an Apple ][ emulator in javascript [1]. My 6502 emulator isn't quite perfect yet, but it runs most things.
I had a Radio Shack Color Computer, which in itself was more than my parents could really afford at the time, so I never got the pricey-for-us EDATSM+ editor/assembler. But I could afford a 6809 book that included op-codes. Then it was a matter of a lot of notebook paper and Basic programs that did a lot of POKEs. Heh. I did a little basic music synth program that way.
There is a lot in that last sentence - I am worrying how we will find the time to fill in football, swimming, parties and gym for my eldest - yet for me the memories of my youth were acres of time to do what I wanted (even if I felt bored !)
We should encourage just using up the time on anything - drawing, coding, playing an instrument. Anything that builds capital for later life.
"Slow parenting (also called simplicity parenting and free range parenting) is a parenting style in which few activities are organised for children. Instead, they are allowed to explore the world at their own pace. It is a response to concerted cultivation and the widespread trend for parents to schedule activities and classes after school; to solve problems on behalf of the children, and to buy services from commercial suppliers rather than letting nature take its course."
Absolutely adore 6502. Started to learn it just a few weeks after being exposed to AppleSoft BASIC and realizing assembly was playing in the machine itself.
There was a holistic understanding of computing that came from the whole Apple II package: taking off the lid, looking at the chips, mapping that to the technical manual showing you the chips, their addresses, their wiring, their code, and being able to stick your hands in all of it. Even a kid could reason the whole machine's current state.
For a while in the late '90s and early '00s, I wondered if we'd lose that kind of education. Tablets worry me for this reason--all screen, no insides.
Thankfully "kids these days" (grownups too) have things like the Arduino so all hope of understanding computing from the inside out is not lost.
For those who do not know that: "the technical manual showing you the chips, their addresses, their wiring..." wasn't reverse engineered or smuggled out of Apple. It shipped with every Apple II. See http://archive.org/details/applerefjan78. Starts with fairly dull stuff (Basic commands, 6502 instruction set), so you may want to start reading from the end.
Woz talks about this a bit in his autobiography. About how lucky he was to have been around when you needed an understanding of the machine at a very low level, compared to growing up in a time where most of that was already abstracted away.
Ah, this is great. I first learned assembly programming to modify one of my favorite video games, Earthbound. To my surprise, the game was a cult classic, and extensive efforts had been made to develop tools to modify every aspect of the game.
As part of that effort, I learned 65816 assembly, a 16-bit descendant of the 6502. The day I modified the code to add a run button, thereby eliminating one of the most annoying aspects of the original game, I was ecstatic.
I checked back on the community, PK Hack, a few months ago. The level of development was amazing. Virtually the entire game was mapped, byte for byte. There's a sophisticated visual map editor, and a cross-platform data editor.
The coolest part was to see a tool I envisioned, for which I developed a lackluster proof of concept, come to full fledged fruition.
Earthbound, as it turns out is a rather uniquely developed game. The second game in the Mother series, which is enormously popular in Japan, ran into severe difficulties. Co-developed by HAL and Ape, the coding was rather schizophrenic from the outset. Eventually large parts were rewritten by Shigesato Itoi himself, as the legend goes. The end result is a spaghetti soup of code generated by some type of macro system, compiled from some variant of C, and written in assembly itself.
To manage this complexity, many of the events in the game used a text scripting language that abstracted away the underlying routines. This scripting was a series of in-line hex sequences, each its own set of instructions for how sprites, character entities, etc. were supposed to act when the code appeared, which we termed "control codes."
12-year-old me, supremely confident in his abilities and utterly lacking in all technical knowledge, suggested we build a scripting language on top of the control codes so that manual text editing would be eased. The result was a slapdash Visual Basic job that used a BASIC like syntax for simple substitutes for control codes. Of course at the time, I had no knowledge of parsers, DSLs, language design, or really basic computational knowledge. The result was a wreck.
But that wreck stuck in someone's mind. Years later, after obtaining his computer science degree, one of the hackers with whom I had worked implemented a full-fledged language on top of the control codes.
In retrospect, I don't remember the vast amounts of time I ostensibly wasted learning an obsolete game's design and building tools with which to modify it. I remember the heady moment when you suddenly knew how a data field worked, or after a whole night of hunting with a hex editor the data you wanted appeared, and the sheer giddy thrill of discovering new knowledge and seeing it implemented right there, like a physical mark on the world.
I recognize this has been a long and tangential exposition, so if you've read any of it thank you for indulging me. Another glimpse of that low level assembly, like the smell of home after a very long time away, brings back so many vivid memories.
I remember a similar sense of joy when i was tinkering with the battlefield 1942 Wake Island Demo, before there were any kind of indication of mod support.
The sheer joy to be able to change simple but undocumented variables to have a plane moving like a jet or having bombs which behaved rocketlike inspired me to learn programming to a deeper degree. Oh the pure joy of exploration and creation.
Later we had flying aircraft carriers which had its fighterplanes "docked" on the sides and would "fall" down towards the battlefield, the fighters had shields which had a blue glow once shot upon...
All scripted ontop of 1942...
Once in a while it would be worth a fortune to be young enough again, not used to thinking in terms of projects, roi, timelines and goals...
Once in a while it would be worth a fortune to be young enough again, not used to thinking in terms of projects, roi, timelines and goals...
I keep promising myself that when this project is finished, or when we hit this sales target, or when this sprint is over, then I'll get back to that off-the-wall idea... I truly believe that anyone of any age can get back to this place. But it takes leisure time, carefree brainstorming, full creative freedom, all of which seem in short supply lately.
But the sprints aren't ever really over anymore. I don't mind. My work fascinates and delights me, and I consider myself lucky to be able to earn a comfortable living (sometimes from my couch!) while having the financial backing to pursue a brand new business venture as well. By all external metrics, it's a good life.
But I can't help but feel that pure creativity, the type of coding that's more akin to art than science, is falling away from my life. So, it's time to change that.
I suppose I need a blog for side projects, unrelated to work in any way, shape, or form.
I need to get back to why I started coding: so it wouldn't take Ness so goddamn long to walk from Threed to Fourside, so I could animate my middle school teacher as a giant pile of puke and attack with my psi powers, and most importantly, engage deeply with a team not just to reiterate, or even to create, but to discover.
I wish there was something akin to a creative fellowship for hackers. Research grants, in academia or private R&D are too tied up in the work-a-day return schedule to provide the creative space for truly new ideas.
It reminds me of a line from FDR:
Happiness lies not in the mere possession of money; it lies in the joy of achievement, in the thrill of creative effort. The joy and moral stimulation of work no longer must be forgotten in the mad chase of evanescent profits.
`I don’t think you’ll ever have to write assembly language in your day job`
Doing C++ work I have had to do this a few times, maybe once a year to optimize a critical routine that the compiler wasn't able to pick up on. When it helped, it really helped.
The first time I was paid for a programming job was writing relocatable 6502 assembly to put into a string and call from Atari Basic.
What did it do? Computed the X-modem checksum of a block.
Why? Because when 1200 baud modems first came out, the BBS I was a member of couldn't compute the checksums fast enough (directly in Basic), so 1200 baud transfers weren't much faster than 300 baud. And if you just paid several hundred bucks for the new 1200bps modem, you wanted to get some benefit. :)
How much did I get paid? $20, which was about $0.50/byte. (Man, how I wish I got paid $0.50/byte for code I write now!!)
My first "serious" programming attempts were trying to use interrupts on a commodore 64 to play music in the background. It didn't work as I wanted - I was 10 - but I really learned a lot.
I disagree with the claim that learning x86 assembly is not useful. I occasionally use inline assembly in my day job. It's very rare, but it does happen. If you're doing C or C++, it helps to know a little bit of x86 assembly when debugging. There are also certain optimizations that you often need inline assembly for, such as using the built-in Intel instruction for CRC32 calculations.
I learned Z80 assembly when writing software for the TI-85. But if I were giving advice to someone interested in learning assembly now, I would suggest learning x86... it's more useful, and just as fun.
