Wow, that brings back memories.
In 1979 I was 19 years old and had just started studying CS in community college. Through a lucky break I got a job at a consulting company and my first assignment was to write a 6502 macro assembler from scratch, in 6502 assembly language. At that point I had written less than 100 lines of 6502 code on my Apple ][, but I was fairly good with 8080 and IBM-370 assembly.
My mentor / manager outlined the basic model for the assembler and I wrote the entire thing myself, quickly getting it to the point where it could self-assemble, and adding features from there. I was making about $7 / hour when I started. However, I wrote a FORTRAN simulation of the hashing algorithm that I was asked to use, shared it with my manager, and got a raise to $8-something an hour.
I had macros, a very fancy listing format that showed all of the hex codes generated by the macros in neat rows, and a lot more. The entire thing fit on two tracks of the 8" floppy disks that we were using -- definitely less than 8000 bytes.
Damn, that sounds so cool. But sounds like a hard task for a beginning career.
The community around retro consoles based on the 6502 never ceases to amaze me.
The Xa project looks very promising.
For anyone interested, there is a transistor level simulator for the 6502 CPU called Visual6502: http://www.visual6502.org/JSSim/expert.html
A little while ago I "remixed" the visual6502 netlist simulation by adding a more responsive UI, an integrated assembler and some more visualization tools, fun little project :)
There's also a Z80 version:
And a contributed Ricoh 2A03 version:
(check "Help => About" for credits, there's a lot of 3rd party code in there)
At the beginning of the pandemic in 2020, I found this course:
My reasoning was I had more free time because my company switched to WFH, so I could study it.
And no, I still haven't finish it :p
Back in 1979 I worked at Aph in Pasadena, writing 6502 assembler for single board computers for clients. Aph's secret weapon was a set of macro assemblers written in BLISS on the PDP-11s. The 11s would assemble the code, link it, and then the binary was downloaded into a prom burner. The cross assemblers were written by Dan O'Dowd, later of Greenhills fame.
Having modern macro assemblers, linkers, and editors available made 6502 development fast & easy easy. (A debugger, too!)
Aph could have made a killer entry into the PC market with a 6502 machine, but it apparently never occurred to Aph, as we mistakenly thought a 6502 general purpose computer wasn't a worthy idea.
And so we missed becoming billionaires!
Be interesting how this contrasts with the cc65/ca65 tool suite, which is pretty complete I think in terms of assembling, linking, and libraries. (Discounting the actual C compiler part.)
Pretty good, I think! (Maintainer.)
What I liked best about it is the portability, the scoping, and the preprocessor, which I prefer in particular to how many other assemblers do macros, and that's why I ended up taking it over (though Andre still did a lot of the code in this release too). The linking is not something I personally use much but other people do, and the O65 binary object format it uses covers a lot of use cases.
ca65 is very complete but the linking phase is tedious. I prefere something more direct like acme which just spits the bytes.
I don't really get what are its selling points compared to other open-source 6502 cross-assemblers such as Merlin, ACME, dasm, cc65, sbasm and the countless others.
I have always used tass. Can someone ELI5 the different assemblers and their advantages?
There are so many 6502 assemblers. Here's a few: https://web.archive.org/web/20151021054219/http://hoop-la.ca...
There are so many, I don't even know which "tass" you are asking about. 64tass?
64tass looks really good as it supports 6502, 65C02, R65C02, W65C02, 65CE02, 65816, DTV, 65EL02, 4510. I use Merlin32 which supports 65816, but I pretty much stick to 6502. I do use xa from time to time. Others have mentioned ca65 which is popular and can support macros and lots of other things that make it incompatible with other assemblers.
Advantages for no 6502 assembler in particular because there are so many available!
* compatibility, ease of use, ease of install, ease of building from source, portability, size, speed, lack of dependencies, vintage, hack-ability, written in $MY_PROGRAMMING_LANGUAGE ...
anybody knows if there are builds for windows ? I didn't find anything recent...
I'm really curious why people would find this news worthy...
From the guidelines:
"On-Topic: Anything that good hackers would find interesting. That includes more than hacking and startups. If you had to reduce it to a sentence, the answer might be: anything that gratifies one's intellectual curiosity."
It's not really about being "newsworthy", but what tickles your grey matter's fancy.
I'll click on anything that says "6502," actually. As a former Commodore 64 owner and current Apple II emulation enthusiast, mentions of that little CPU are like Reese's Pieces to E.T.
There was a new version released 2 days ago...
> Version 2.4.0 (18 November 2023)
Thanks. Given I am using ca65 (not even cc65), do you mind anything I should take into consideration for trying yours. Other than for the old time sake.
Arguably when compiling/assembling is "free", outside of using precompiled code without source code, there's little reason for the linking phase. Ostensibly it was faster to link precompiled code than to constantly recompile it. But even back with Turbo Pascal, I think that was called into question. Especially as the CPUs went faster and faster, and memory expanded, but I/O dragged behind.
Now, I don't think anyone would blink at constantly rebuilding 100K lines of assembly. It takes seconds on modern hardware. We even see that in the C world with large utilities shipped as a ".h" file.
Yes, that the one.
I'll have to investigate the others you've mentioned.
As long as the license is open source proper, I am interested in tools that run in several platforms (i.e. ISO C better than POSIX, in turn better than Linux-specific) and have good syntax, documentation and error messages.