Look at this! I finally succeeded in running C code on my shitty TI-83 calculator with a Z80 CPU. This is a huge improvement as I made whole games for that thing with assembly before! 😁😍

TIL that TI has no goddamn chill

Texas Instruments released the TI-83+ calculator model in 1996. The Z80 was not at all stock and has the following features:

- 3 access levels (priveleged kernel, kernel, user)
- Locking Flash (R/O when locked for most pages, some pages protected and unreadable as well, only unlockable from protected Flash pages by reading a certain order of bits then setting a port)
- Locking hardware ports (lock state always the same as flash)
- Customizable execution whitelist range (via locked ports)
- Configurable hardware (Flash/RAM size changeable in software via locked ports, max RAM is 8MB which is fucking mental compared to the 64k in the thing)
- Userland virtualization (always-on)
- Reset on violation of security model
- Multithreading
- Software-overclockable CPU
- Hardware MD5 and cert handling

TI made a calculator in 1996 with security features PCs wouldn't see until like 2010 what the *actual* fuck

I could bitch about XSLT again, as that was certainly painful, but that’s less about learning a skill and more about understanding someone else’s mental diarrhea, so let me pick something else.

My most painful learning experience was probably pointers, but not pointers in the usual sense of `char *ptr` in C and how they’re totally confusing at first. I mean, it was that too, but in addition it was how I had absolutely none of the background needed to understand them, not having any learning material (nor guidance), nor even a typical compiler to tell me what i was doing wrong — and on top of all of that, only being able to run code on a device that would crash/halt/freak out whenever i made a mistake. It was an absolute nightmare.

Here’s the story:

Someone gave me the game RACE for my TI-83 calculator, but it turned out to be an unlocked version, which means I could edit it and see the code. I discovered this later on by accident while trying to play it during class, and when I looked at it, all I saw was incomprehensible garbage. I closed it, and the game no longer worked. Looking back I must have changed something, but then I thought it was just magic. It took me a long time to get curious enough to look at it again.

But in the meantime, I ended up played with these “programs” a little, and made some really simple ones, and later some somewhat complex ones. So the next time I opened RACE again I kind of understood what it was doing.

Moving on, I spent a year learning TI-Basic, and eventually reached the limit of what it could do. Along the way, I learned that all of the really amazing games/utilities that were incredibly fast, had greyscale graphics, lowercase text, no runtime indicator, etc. were written in “Assembly,” so naturally I wanted to use that, too.

I had no idea what it was, but it was the obvious next step for me, so I started teaching myself. It was z80 Assembly, and there was practically no documents, resources, nothing helpful online.

I found the specs, and a few terrible docs and other sources, but with only one year of programming experience, I didn’t really understand what they were telling me. This was before stackoverflow, etc., too, so what little help I found was mostly from forum posts, IRC (mostly got ignored or made fun of), and reading other people’s source when I could find it. And usually that was less than clear.

And here’s where we dive into the specifics. Starting with so little experience, and in TI-Basic of all things, meant I had zero understanding of pointers, memory and addresses, the stack, heap, data structures, interrupts, clocks, etc. I had mastered everything TI-Basic offered, which astoundingly included arrays and matrices (six of each), but it hid everything else except basic logic and flow control. (No, there weren’t even functions; it has labels and goto.) It has 27 numeric variables (A-Z and theta, can store either float or complex numbers), 8 Lists (numeric arrays), 6 matricies (2d numeric arrays), 10 strings, and a few other things like “equations” and literal bitmap pictures.

Soo… I went from knowing only that to learning pointers. And pointer math. And data structures. And pointers to pointers, and the stack, and function calls, and all that goodness. And remember, I was learning and writing all of this in plain Assembly, in notepad (or on paper at school), not in C or C++ with a teacher, a textbook, SO, and an intelligent compiler with its incredibly helpful type checking and warnings. Just raw trial and error. I learned what I could from whatever cryptic sources I could find (and understand) online, and applied it.

But actually using what I learned? If a pointer was wrong, it resulted in unexpected behavior, memory corruption, freezes, etc. I didn’t have a debugger, an emulator, etc. I had notepad, the barebones compiler, and my calculator.

Also, iterating meant changing my code, recompiling, factory resetting my calculator (removing the battery for 30+ sec) because bugs usually froze it or corrupted something, then transferring the new program over, and finally running it. It was soo slowwwww. But I made steady progress.

Painful learning experience? Check.
Pointer hell? Absolutely.

Tl;Dr - It started as an escape, carried on as fun, then as a way to be lazy, and finally as a way of life. Coding has defined and shaped my entire life from the age of nine.

When I was nine I was playing a game on my ZX spectrum and accidentally knocked the keyboard as I reached over to adjust my TV. Incredibly parts of it actually made a little sense to me and got my curiosity. I spent hours reading through that code, afraid to turn the Spectrum off in case I couldn't get back to it. Weeks later I got hold of a book of example code to copy out to do various things like making patterns on the screen. I was amazed by it. You told it what to do, and it did it! (don't you miss the days when coding worked like that?) I was bitten by the coding bug (excuse the pun) and I'd got it bad! I spent many late nights on that thing, escaping from a difficult home life. People (especially adults) were confusing, and in my experience unpredictable. When you did things wrong they shouted at you and threatened to take you away, or ignored you completely. Code never did that. If you did something wrong, it quietly let you know and often told you exactly what was wrong. It wasn't because of shifting expectations or a change of mood or anything like that. It was just clean logic, simple cause and effect.

I get my first computer a year later: an IBM XT that had been discarded by a company and was fitted with a key on the side to turn it on. With the impressive noise it made it really was like starting an engine. Whole most kids would have played with the games, I spent my time playing with batch scripts and writing very simple text adventures. And discovering what "format c:" does. With some abuse and threatened violence I managed to get windows running on it. Windows 2.1 I think it was.

At 12 I got a Gateway 75 running Windows 95. Over the next few years I do covered many amazing games: ROTT, Doom, Hexen, and so on. Aside from the games themselves, I was fascinated by the way computers could be linked together to play together (this was still early days for the Web and computers networked in a home was very unusual). I also got into making levels for Doom, Heretic, and years later Duke Nukem 3D (pretty sure it was heretic; all I remember is the nightmare of trying to write levels entirely by code!). I enjoyed re-scripting some of the weapons and monsters to behave differently. About this time I also got into HTML (I still call this coding, but not programming), C, and java. I had trouble with C as none of the examples and tutorial code seemed to run properly under a Windows environment. Similar for my very short stint with assembly. At some point I got a TI-83 programmable calculator and started rewriting my old batch script games on it, including one "Gangster Lord" game that had the same mechanics as a lot of the Facebook games that appeared later (do things, earn money, spend money to buy stuff to do more things). Worried about upcoming exams, I also made a number of maths helper apps, including a quadratic equation solver that gave the steps, and a fake calculator reset to smuggle them into my exams. When the day came I panicked and did a proper reset for fear of being caught.

At 18 I was convinced I was going to be a professional coder as I started a degree in Computer Science. Three months later I dropped out after a bunch of lectures teaching what input and output devices were and realising we were only going to be taught Java and no C++. I started a job on the call centre of a big company, but was frustrated with many of the boring and repetitive tasks we had to do. So I put my previous knowledge to use, and quickly learned VBA to automate tasks. It wasn't long before I ended up promoted to Business Analyst where I worked on a great team building small systems in Office, SAS, and a few other tools.

I decided to retrain in psychology, so left the job I was in and started another degree. During my work and placements my skills came in use a number of times to simplify and automate tasks. I finished my degree, then took a job as a teaching assistant while I worked out what I wanted to do next and how to pay for it. Three years later I've ended up IT technican at the school, responsible for the website, teaching a number of Computing lessons each week, and unofficial co-coordinator for Computing as a subject. I also run a team of ten year old Digital Leaders who I am training in online safety and as technical experts; I am hoping to inspire them to a future in coding. In September I'll be starting teacher training with a view to becoming a Computing specialist teacher. Oh, and I'm currently doing a course in Android Development in my free time.

And this all started with an accidental knock on the keyboard of a ZX Spectrum.

I used to think I was so clever by viewing the source code of websites, and would just scroll through it for fun, but what really got me started in programming was the TI-83 calculator I got in grade 10.

You couldn't view the code of most programs on that calc without a computer connection, but I managed to get my hands on the source code of something simple and learned how to prompt for values and calculate things with them. Before I knew it, I was making little programs in BASIC that did formulas for me (Area/circumference of a circle, etc.). One of my professors caught me showing my calculator to another student in class, and assumed I was being a bad student. When I said I made a program as a shortcut for one of the formulas we were learning, she tried to call my bluff and said to write the whole program on the whiteboard for the class to see. 10 minutes of writing and more than one blank stare from my classmates later, the teacher just waved me off and continued the lesson. I was chuffed :-). I made these simple programs for all my math classes throughout high school.

Unfortunately, my first year of university I took a CS course, and my teacher was probably the worst I've ever had in my life. I decided it wasn't for me, and though I did maintain my general aptitude for tech (and was still the person who fixed everyone's printers and viruses), I took a different path, eventually getting an Arts degree in Anthropology.

Where I live, the market for this is more than stale. In fact, it's completely flat, so I thought I would take a course about programming with Arduinos for fun and see if I should return to school for a different certification. It was AWESOME! I made a wireless weather station with Xbees and sensors and built my own anemometer.

I got a job at a manufacturing company, and had the fortune to build a robot which eventually made it's way to the second season of Battlebots. The level of intelligence and enthusiasm I encountered really inspired me, and now here I am at 31, halfway through a BSc in Computer Science and working for a company that makes 3D printers.

It's been a long journey, but the adventure always starts anew tomorrow.

first real program was an 8x8 maze game on my ti-83+ calculator. wrote all as nested ifs, and if you took one wrong turn it'd run out of memory

for your next edition of "TI's constantly been smoking crack since the 80s and has no intention of ever stopping":

the TI-8x calculators have a hardware buffer and an OS-provided buffer for screen data, effectively being an "immediate" buffer in hardware, to be displayed next VBlank, and a "slower" buffer, being what's copied to the "immediate" buffer when the OS decides it's time to update the screen. All well and good, maybe a little weirdly done but all in all makes sense. (You can even define a third buffer in RAM if you need to triple-buffer your shit.)

The problem arises when you use TI-BASIC and try to draw to the screen:
If you do something like, say, draw a circle, you'll notice that it's visibly drawn to the screen one pixel at a time. However, looking through what bits of the SDK I can find, the OS' "draw circle" assembly routine *doesn't update the immediate buffer!*

This means that, in TI-BASIC, the "draw circle" routine doesn't use the ACTUAL circle-drawing routine the OS provides, but instead individually calculates and plots a pixel, then updates the hardware buffer (an ENTIRE 768 bytes are copied EVERY TIME) and waits for VBlank to pass before repeating for the next one. In other words, it's deliberately slow as fuck.

Why? All the drawing commands, outside of like 2 or 3, do this. Why would you deliberately slow down the process of drawing to the screen on a system that you KNEW would be popular for people to code on???