The assembly code looked like poetry.
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 efficient.
> 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.