Hacker News Reader

As someone who was also there and did that, I want to partially refute the refutation of that assumption. There were many many pure basic games that you typed in and you could learn from. But it became more and more common to use assembly language via data blocks to get the best from that beasty hardware and it started to get more common that you would get listing that were pure hex codes and you'd enter the program with a special tool ( which also you typed in from a printed listing ) which would also include a checksum to make sure type each line correctly.

But still, I learnt a lot by modding basic games I typed in from books, then later learnt a lot of assembly as I tried to mod those assembly language programs I typed in with hex codes. You'd print the whole program out using a good ol dotmatix printer ( took a while.... not because there was that much code, just printers were slow... ) and then puzzle over the assembly trying to work it all out and drawing lines trying to work out all the jump sequences etc. Later my Dad and I had a lot of fun hacking tape based games so we could put them on our awesomely huge (doubly huge if you cut a notch and flipped them over) and speedy 5/14 inch discs.

As someone who was also there and did that, I want to reconcile your positions. When you have a look at the archival issues of Your Commodore magazine[0], you'll find both meaningful BASIC code that you can learn from as well as DATA instructions that were mostly useless for us at that time.

[0] https://archive.org/details/your-commodore-magazine

> I have typed in many programs and there's not a lot to learn because most of them consisted of many pages of DATA lines and a small loop that loaded those machine instructions

That varies a bit by platform. Most 8-bit machines had relatively poor BASICs and no assembler, so BASIC code could be a mess of line-number targeted GOTO/GOSUB statements and anything that needed to be faster than the higher-level language interpreter could manage needed to be pre-assembled and just pushed into the relevant RAM locations by a BASIC loop as you describe.

I had the luxury of learning on Acorn machines, initially an Electron then a BBC Master Series. Their variant of basic had useful features which implementations on other 8-bit devices lacked: long variable names (IIRC the C64's BASIC allowed long names but only used the first to characters so PersonName and PermitCount would clobber each other, BBC basic respected up to 40 characters of a name), named procedures and functions, and a built-in multi-pass assembler. This made BASIC code (if written using those features obviously, some magazines had content targeted at multiple architectures and stuck to the lowest common feature-set) easier to read, understand, and modify, and made it possible to see any machine code logic so you had a hope of pulling it apart usefully too. I learned a lot starting from nuggets in type-in demos and using them as starting points to experiment/read a little deeper, not just about those specific machines but reading around computer architecture more generally. I don't think I'd have the same level of competence or knowledge that I have now were it not for that start.

I remember in Polish computer magazines, they had a validation program. It was a shorter program that you typed in once and ran. Then, when typing in the long "game" code from the magazine, the screen displayed two-letter checksums for each line of codde. The two-letter checksum was also put in the code listing in the magazine, so that you could quickly compare them to find the line that was typed wrong.

As someone who was there and did that I want to refute that assumption :) I have typed in many programs and there's not a lot to learn because most of them consisted of many pages of DATA lines and a small loop that loaded those machine instructions into the home computer's memory and started the program by a USR directive

On the Beeb most listings were BASIC with all the logic there and DATA statements just for in-game assets such as sprites or room descriptions in a text adventure. All the Osbourne books are online now , check them out https://www.raspberrypi-spy.co.uk/2016/02/usborne-releases-1... many happy memories inside!

For more 80's microcomputer BASIC nostalgia, there's also INPUT magazine (https://en.wikipedia.org/wiki/Input_(magazine)). I spent hours and hours as a kid poring through those magazines. Archive.org has the entire series as PDFS - https://archive.org/details/inputmagazine. They were really good at explaining core programming concepts and the illustrations were also amazing.

BBC BASIC had a built-in inline assembler, which I think also made things easier for people typing in at home. Even if the program dropped to assembly language for speed, the instructions were still human-readable rather than DATA statements full of raw hex.

You could actually do that right now in a better way.

Most of the assembly and other DATA/POKE stuff is less than relevant nowadays as hardware has improved and a lot of magic is already done in firmware.

The form of "type it in, verify and run; explain mistakes and correct solution" is still didactically valid.

I'm pretty sure there are programming language interpreters out there with simplicity of BASIC, including BASIC itself.

On MS-DOS, you had a variety of commands built in and extensibility via BASIC too. (or more) Programs could be written as batch files. On Unix-like, the primary interface was via shell, csh, ksh or later POSIX. A set of built in commands. If you wanted something more advanced, programming languages and interpreters were easily available, typically pre-installed.

It was the main interface, magic words. We have regressed to pictures now and most extensibility has been hidden, removed and made very indirect.

Hardware doesn't come with programming manuals anymore as it is deemed too complex (yeah right) and expensive. It is be great if your GPU came with a description and software to write and execute shaders, for example. PC with instructions how to programmatically reboot it, start it or access sensors. How to access EFI services. What the machine code looks like. Etc.

"Hardware doesn't come with programming manuals anymore as it is deemed too complex (yeah right) and expensive."

It doesn't come with manuals because it is considered a trade secret. Commodore had to lay the hardware bare because it wasn't fast enough to program in a high level language nor did the high level languages fully support their hardware, whereas the hardware of today is so fast that nobody thinks anything of it programming it through a driver or a shared object library in a high level language. It's still wrong not to lay the hardware registers and their functionality bare (yes NVIDIA, have you forgotten your SGI roots?)

Rarely it is the case that showing relevant performance characteristics and APIs really exposes anything. AMD is perfectly fine with exposing the programming manual and most of setup code - it is not where the real important secrets lie...

It takes time to produce useful documentation though.

I remember that Amiga programming manuals had to be additionally bought from Commodore.

But they were available, and most of us used the optical character recognition scanned version on the LSD doc disk.

25 years later I bought the real thing.

The hardware reference manual was published by Addison-Wesley. Gave me a little nostalgia ping when I noticed the Stroustrup C++ book I bought recently was also published by them.

I would also guess that RIAA/MPAA are somewhat responsible with the secrecy to enforce the DRM.

I've read a discussion in a forum where an AMD employee when questioned if it was possible to have a GPU's FW without DRM (or something like that) his answer was that would probably be a commercial suicide (OK, I'm little tired right now and I'm not recalling all the details of the conversation but I can try to dig it up... ^__^;)

Hasn't that changed in recent years? I've seen manuals for recent AMD GPU instruction sets.

One of the advantages of the TI-994A was that the (Extended) Basic community didn't use (couldn't?) the prevalent PEEK,POKE commands on the Commodore 64.

The code was out in the open and decipherable. Great way to learn in that particular environment.

Wow - your comment tripped a memory in me. I learned on a TI and made heavy use of CALL CHAR to redefine the bit pattern for characters to draw on screen. I had a hard time switching to Commodore Basic because it wasn't clear to me how to accomplish similar things there.

Atari with their player-missile graphics made immediate sense to me though.

This depends on the teen. In my peer group, at the time, a few of us being nudged by a mentor or two, went right after the machine code.

One of the things that mentor emphasized was writing a dissassembler soon after becoming familiar with a given CPU.

However, that woild be post fact. Some teens got closed computers, like Atari machines. By todays standards, they are wide open. Back then, they were mysterious, but capable with spiffy graphics and sound chips. The key thing was how users were nudged toward or away from the guts of it all.

Other teens got, say an Apple 2. On that one, you got schematics, a commented ROM listing, and the whole machine was open, software driven. It screamed, "hack me!" The whole damn computer was a clever hack!

Again, my per group were Apple people, and were writing ML based off the snippets found in the ROM, along with great tutorials found in the grocery store magazines. (Where I got my first dissassembler, BTW. Thank you COMPUTE!)

This stuff varied extremely widely. One town would have that spark of learning, a particular school, or club maybe. Another one, nothing. Just gaming, the usual.

Circling back, yeah. Those DATA statements were known to be programs. Lots of us hand disassembled them and either wrote them down (I have a couple in some papers somewhere, I am sure), and my preference was to add REM statements with assembly code in them for later. Oh how I would have loved BBC Basic!

The Apple was cool, had a monitor and mini assembler, disassembler. Wrote a lot with it. Still a mess compared to what I understand the BBC had. I want to go and run one.

Other machines varied, as did people and what books and or other resources were available to them.

It depends on the system though; C64 had a very limited basic so without asm you could not do very much. Other systems, like the MSX, had pretty advanced basic and many of the programs you would type in were mostly or only BASIC.

However, because I was young and still had memory in my brain, by typing in those poke data parts, patterns stuck in my memory. When I bought my first asm book, I finally understood what those patterns of opcodes meant. I never programmed in assembly instructions on the z80; I always used direct opcodes, still do. It is faster for me.

This is true but partially. Maybe I have memories starting 1-2 years earlier when more than half the games were coming in BASIC listings and you could find some quite complicated and interesting ones among them.

The more advanced I had found was a football (soccer) simulator that was working like a text adventure game, showing you the development of the game by writing the words of the sportcaster in regular time intervals. Being able to understand it and modify it, was a milestone on my growth as future programmer.

In my experience there were plenty of both types of listings around (that is, both open BASIC listings and more inscrutable ML in DATA lines). My systems (PET and C64) had a built in disassembler, so it want necessarily that hard to comprehend the code anyway. And a lot of the DATA were just sprites and other graphics.

Anyway, I learned a few things from those listings early on.

And as importantly, people traded tapes, floppies, etc. "If you were an avid gamer, you became a good programmer almost by necessity" is pretty ludicrous.