[kjs3]

This is completely wrong, and it's obvious the author is the one who is "cringeworthy". I most certainly "coded your code straight into a computer" back in those days. The Commodore PET and Apple 6502 computers had built in BASIC, in ROM, and assembler environments were easy to find if you had a floppy. The Apple at least had any number of other languages like Pascal and Forth. And the idea that the 68000 was easier if you knew 6502 is laughable.

[Theodores]

Commodore PET and Apple machines were for people who had rich daddies and lived in America. For those of us in the Rest of The World getting access to a computer was not as simple as that. We had to wait for things like the VIC-20 to come along, the PET was unseen outside of a magazine cover. There was no sea of surplus computers, particularly ones with floppy disks. Pen and paper was how things got done. You, not knowing that, shows how little you know.

True, you could program in almost any language you wanted on almost any platform. However Forth was a novelty and of the few people I knew that had Pascal, none of them actually used it - the box sat there, on the shelf. Much like today you could choose to program in Forth if you really wanted to (or Cobol) but you didn't, simple as. The 'killer apps' of the time - games - were generally written in assembler as in assembler you could do things not possible with one of your 'other languages'.

As for your quip about 68000 not being easier if you knew 6502, do you just arrogantly dismiss everything out of hand? No evidence given?

Shortly after the hey-day of things being done in assembler, I was the only person in a very large university class to get 100% for some 68000 based assembly assignment. This was my first go at 68000 and I completed my work in less than one hour. Sure 'introductory 68000' might be easy, complete 'hello world' stuff for a genius like you, however none of the hundred or so that were on that course could churn out the assignment like I could, straight off the bat. They struggled for weeks on it and most of the class cribbed answers from each other, they were that bad. The difference I had was solid 6502 experience, I took to 68000 like a duck to water, everyone else was still struggling to get their heads around what to me was a simple task.

Sure my reminiscences from aeons ago are totally anecdotal but I went on to do lots of stuff in 68000 and, without that first bit of 6502 experience, I would have struggled.

[kjs3]

<i>As for your quip about 68000 not being easier if you knew 6502, do you just arrogantly dismiss everything out of hand? No evidence given?</i>

Well, 8-bit, accumulator-based, limited addressing modes, numerous quirky features required for good performance (e.g. zero page) vs. 32-bit, register-based, numerous, generally orthogonal addressing modes, privilege separation, etc. So other than 'programmed in assembly', not much similar between the two. I know when I jumped from processors like the 6502 to the 68000, I had to forget more about the 6502 to really get the 68000 than I kept. Maybe you could take your own advice and describe the architectural similarities of one processor that made you so much more prepared to understand the other? You know, give some evidence.

As to the rest of your snotty, self-indulgent, anti-American rant...it's a real shame you didn't get to play with the cool toys that existed at the time. That doesn't mean they didn't exist and we didn't use them. We'll get right on that pity party for you.

[jonjacky]

No, he's right. The PET and Apple were second generation 6502 machines - intended to be personal computers. The first 6502 products were evaluation kits like the KIM-1, which only had a keypad and seven segment LEDs for entering and viewing code in hex. Even this was quite an advance over the previous generation like the Altair where you had to enter code by flipping switches. This page has a picture, explains the process and shows some handwritten source code:

http://blog.jgc.org/2013/04/how-i-coded-in-1985.html

(Despite the title, this was more typical of 1976 or so.) It seems awkward, but it was quite workable for embedded controllers, which was the original application that the microprocessor manufacturers had in mind.

[vidarh]

That may be true, but the timeline was short: The 6502 was introduced in 1975. The KIM-1 arrived in 1976, and the PET in 1977. There was really only a year where the 6502 was a realistic options without there being "proper" computers based on it.

That said, while I never wrote assembly opcodes by hand, I did know the hex values for most of the 6502 opcodes at some point. And I did later debug M68k assembler by annotating dot matrix printouts until '92 or '93 or so - I used to bring them to school with me so I could work on my compiler projects during recess.

The things you do when you don't have portable computers or network access.

[jonjacky]

I see that the original Apple I (not II) provided something similar, except with a full keyboard and video instead of keypad and LEDs. See the screenshot on this page:

http://apple2history.org/history/ah02/

[kjs3]

That's fair, although I had a pretty early AIM-65 (roughly contemporary to the KIM-1) that had FORTH in ROM. So yes, there was a time in the 6502 history where ASM was pretty much the only option, but lots of other options came along quickly.

P.S. - The Altair had a floppy option pretty much from introduction ('76 or '77, at least) as well as a cassette tape setup, so while you often bootstrapped with the front panel (unless you added a bootstrap ROM someplace; many did), you didn't have to load all your software that way. I had friends who even had paper tape readers on their Altairs, which were pretty cool.

[Zardoz84]

Apple I and ][ Had a machine code monitor on ROM, and on some version had a mini-assembler. Search for Woz's monitor (and take a looks to the assembly code, it's very interesting)

But I agree that Theodores's post there is something wrong. Only Sinclair's ZX81/82 abuse of the Z80 to generate the screen. Zx Spectrum's had an ULA chip that handles the screen generation and other stuff, like the cassette interface.