Best thing is - it was me against the machine. If anybody did something that moved more sprites than I did, or did better parallax, it was because they were better than I. No driver incompatibility to blame. I loved programming in 1984, it made me tolerate less shit and produce better code than people who were less fortunate to be born later.
I miss those days :(
The machine code was the easy part - what cost me so much time was reinventing on my own a parser without knowing anything about parsers theory and AST (I was 16 then).
Today, you type your function inside Google search and you get a rotating 3d plot rendered in real time in js inside the browser... lol.
I shared a similar experience regarding parsing also with your age, got a compiler development book at the local library, but the T diagrams of bootstrapping process and how to use automatons only made sense years later.
I ended up resorting to common sense and a very lousy parsing algorithm.
However my goal was pretty basic, doing syntax highlighting of Turbo Pascal code for printing.
Actually, at least on the 8 bit machines we had ROM firmware to blame.
I remember some ZX Spectrum issues depended on the actual model one had, which were un-officially documented on the ROM Disassembly books.
Heck, if I want to, I can even massively hack things, write kernel drivers for linux OR windows, do basically whatever I want. Some of them are harder than others, and some are more intended than others, and some require more time than others, but the world of hacking is still one of possibility. Pretty much the only locked down systems are smartphones, which sucks, but I just bought a raspberry Pi zero W for 10 dollars, which is incredible compared to the Basic Stamp 2 micro controller that cost $120 just a decade ago.
Literally the only difficult (at least IMO) thing for hacking whatever you want is analog circuits. I still massively struggle with that.
But for an older person, you make some great points.
My first computer was an ST in the late 90s! it was a bit of a franken model that my dad assembled, basically the best bits of various STs, I loved it. It was my favorite computer even in that era. I was of a similarly young age but didn't get beyond BASIC back then :), still I feel like I learnt a lot more than my friends with their more expensive windows boxes of the time.
I wish I took the programming further back then, I ended up rediscovering it later in life instead. I feel like I have some strange kind of false pseudo nostalgia for these machines though since I discovered them almost two decades later :P
But you didn't have an Amiga or ST in 1984, did you?
Do binaries still exist? Documentation? Source code?
A single board computer with the m68k is still small enough that you can comprehend the schematics and build it at home (e.g. http://www.kswichit.com/68k/68k.html ), and it's a very valuable learning experience.
"Apollo Core 68080 is the natural and modern evolution of latest 68000 processors. It's 100% code compatible, corrects bugs of 680x0 designs and adds on top most of the cool features which were invented the years after."
Actually, there are a number of offerings in the coldfire v2/v3/v4family with decent performance and external buses including PCI, 10/100 ethernet, USB, ATA, and CAN with DDR memory and parallel bus interface.
18.104.22.168 External Bus Interface
The bus interface controller transfers information between the ColdFire core or DMA and
memory, peripherals, or other devices on the external bus.
The Hitachi line, at least, seems to be explicitly EOL by Renesas. I'm not familiar enough with the other vendors to know who might have picked up their licenses.
One interesting avenue to explore might be the Sega Genesis. It's still being produced in Brazil, believe it or not -- and there must be some sort of 68000-compatible processor at the core of those.
Picked up 68k, 6809 and various databooks.
Not only were docs free, but the engineers there started up a good conversation. That I was a kid didn't matter much.
The assembly code looked like poetry.
He'd made a Atari ST extension called (I think) Quick ST. The ST had awfully slow text output due to many things such as the interleaved bitmaps and lack of hardware assist. His made it much faster. I wrote a competitor that was faster than his. A couple of month later he wrote a new version that obliterated mine.
I literally spent weeks trying to work out how he'd done it, went through the 68k reference manual, nothing.
Then one day it came to me in an actual dream - 12 year old me actually woke up and started typing. It was the 'move.p' instruction. From memory this instruction split a 16 bit word into 2 bytes but aligned on a word (16 bit) boundary. I added this and my code then beat his.
Bear in mind this was before the internet, so no to-and-fro with conversation, all I saw was what he did. It absolutely stood me in good stead for the rest of my career, each time now I see a programmer who writes something completely sloppy I ask them how it will scale. I really miss those days and wish somebody could bring this back for newer people to learn the basics.
These days I yell at people because they build Docker images that take up several Gigabytes...
I love that I don't have to use the vertical blank interval to do processing, but fuck me if we've not gone the other way, programming is lazy nowadays.
Three whole instructions worth of cache.
"Wha...?" you might say? Tha' heck good is that? The point was that the 3-instruction cache could cache tight loops, like the kind you would use for mem-to-mem copies, which is a terribly common thing to do. I put one in my Amiga 1000 (geez, did I hack that thing...) and got about a 10% overall system performance increase.
It was neat! More lovely details here: http://www.memphisamigagroup.net/diskmags/198803/68010-kit/M...
68K is so nice, and damn do I miss programming that low. The x86 always felt like I had offended someone from Greek myth and was being punished. A cruddy blaster not a lightsaber.
> 68000 was carefully considered. "AN excellent architecture chip, it has
proven to be a worthy competitor to the Intel-based architecture."
there wer four major concerns:
> 1) 16 bit data path would require more bus buffers, therefore a more
expensive system board.
> 2) more memory chips for a minimum configuration.
> 3) while it had a performance advantage, the 68000 was not as memory
> 4) Companion and support chips not as well covered as Intel.o
> He also felt the the 68000 didn't have as good software and support tools,
and the similar register model allowed the porting of 8080 tools
to the 8086/8088.
> "In summary the 8088 was selected because it allowed the lowest
cost implementation of an architecture that provided a migration path to a
larger address space and higher performance implementations. Because
it was a unique choice relative to competitive system implementations, IBM
could be viewed as a leader, rather than a follower. It had a feasible
software migration path that allowed access to the large base of existing
8080 software. The 8088 was a comfortable solution for IBM. Was it the
best processor architecture available at the time? Probably not, but history
seems to have been kind to the decision."
I don't remember where I read about it, but I remember reading about that IBM ditched the 68008 (8 data bit bus version, like the 8088) because some problem with it... availability of it, perhaps.
Sharing them with my friends through the cable that went into the headphone jacks. The fun of seeing somebody at my school I didn't really know getting a kick out of something I made.
By the time I got a TI-89 around 1999, I was in college and just didn't have the time to do anything substantive with programming it.
I'd dust it off, but mine is old enough to just have the I/O port, and don't know that I have any functioning computers with a parallel or serial port for the old TI Link.
Alternatively, a while ago I used Emscripten to build an emulator for the TI Voyage 200 (a late revision of the TI-92). There's some minor glitches, but it's mostly functional:
TI-GCC for my TI-89 was nice...a few years back I tried to dust-off my IMSA-issued 89, and...it didn’t turn on. Sad. Replaced all batteries. Nothing... Then the flex connector on my 83+ started flaking out (the LCD corruption issue plaguing these...).
In Portugal, TI wasn't that relevant, the dream of most students were having either a Casio FX-850 (later FX-880), or an HP-48.
Wrote some others too: https://www.macintoshrepository.org/3732-macracquetball
At the time, I was an Amiga fan, and I had this manual. I was totally blown away at how nearly identical the architecture of the M68000 was compared to that mainframe. Imagine my thinking that my Amiga 500 had the equivalent of a room-sized mainframe in that chip!
Motorola's PowerPC support hotline acknowledged the problem on the same day and published a new version of the manual by the end of the week or the next one. Of course they did, because that's how great they were.
"Scalar floating-point instructions operate on single 32-bit operands that
reside in the lower 32-bits of the GPRs. These instructions are considered a
proper subset of the SPE APU; this subset is referred to as the SPFPU now
called the EFPU Gary cares only that it have embedded in it somewhere."
(more recent e500 chips considered the scalar instructions to be in a separate APU)
Modern x86 is mostly insensitive to data alignment, since it fetches internally in cacheline-sized blocks (I believe it's 64 bytes) and a very wide barrel shifter is used to access the desired bytes. There's a tiny (single-digit cycles) extra time when the element straddles two cachelines (assuming both lines are in cache)
later on I got to do some work on a 68030 series micro. That was pretty nice also. All assembly based.
If in the USA:
Hack a TI-89 calculator. They are still 68K-based, are unfortunately inescapable bricks tied to mandated Maths curriculum, and have an active hacking community.
I re-learned M68K programming via the Palm Pilot, which has a fun SDK clearly inspired by the Classic Macintosh.
I would say that ARM programming can be as fun as 68K, so perhaps a Raspberry Pi to start. You can get closer to the glory days with ARM-M Arduino-like toys such as the Teensy.
I haven’t done any assembly-level Arduino programming, so I don’t know what that feels like versus 68K. Lots of microcontrollers grew upwards out of the then-popular 8051, which does not feel the same to me.
I got started on the Motorola 6809 CPU and the TRS-80 Color Computer. You could almost call it an 8-bit precursor to the M68K, it is limited but very nice design.