SoylentNews is people
SoylentNews
Back before computers (and cell phones!) regularly sported multi-GHz processors and GBs of memory, there was the 6502 microprocessor. It was the CPU that powered computers made by Apple, Acorn, Atari, BBC Micro, Commodore, and others. Though the 6502 was introduced in 1975, it is far from being a dead parrot!
Classic 8-Bit Computing The Atari Way:
In the classic gaming world, even before the NES arrived on the scene, there was no name more ubiquitous than Atari. Their famous 2600 console sold almost as many units as the Nintendo 64, but was released nearly 20 years prior. In many ways, despite making mistakes that led to the video game crash of the early 80s, Atari was the first to make a path in the video game industry. If you want to explore what the era of 8-bit computing was like in the Atari age, a new resource is compiling all kinds of Atari-based projects.
To get started, this Atari Projects page has instructions on how to install Altirra (a 6502 emulator) to your PC. That is really handy if you don't happen to have a 40-year old computer lying around. Read on for lots more!
Altirra was programmed by Avery Lee to emulate the Atari 400, 800, XL, and XE computers as well as the XEGS game system. It was first released in 2009 and has been consistently updated since. Version 3.0 was released in December of 2017. According to the website, "Altirra is designed with emulation quality in mind, sometimes over speed and polish. It's designed as a system emulator and debugger instead of a games machine, so there is some setup involved". Altirra is licensed under the GNU General Public License (GPL), version 2.
From there, go back to Atari Projects for some code to run on it. Also available on that site are links to still other sites which have downloadable Atari programs.
Then, for those who are curious about the 6502 processor itself, take a look at Visual Transistor-level Simulation of the 6502 CPU. There you can find an emulator of the 6502 processor that runs in your browser! It depicts all activity on the chip when each instruction is executed. Starting from high-resolution photographs of the silicon die and its substrate, they created an exact model of its circuits. They state:
This model is very accurate and can run classic 6502 programs, including Atari games. By rendering our polygons with colors corresponding to their 'high' or 'low' logic state, we can show, visually, exactly how the chip operates: how it reads data and instructions from memory, how its registers and internal busses operate, and how toggling a single input pin (the 'clock') on and off drives the entire chip to step through a program and get things done.
Now you can really say "I see what you did there."
If that's whetted your appetite, check out http://www.6502.org/ for lots more.
(Score: 2) by RS3 on Monday May 04 2020, @02:06PM
Yes, agreed.
I guess I've always wondered what ultimately is the most efficient: MMIO or separate I/O. It seems that for multi-thread and multi-core CPUs, you could bog down the RAM bus with very slow I/O stuff. But I'd have to think it through... If all I/O had some kind of Command Queuing spec, it wouldn't matter- as long as IRQ is in effect. If it's polled I/O, then you're bogged down. Too much to think about on a Monday morning! Wish I did this kind of stuff full-time...
> Holding a C pointer to your device's register base is pretty handy.
Yes, absolutely. From my modest programming experience, it seems it might open things up to where programmers get into more trouble with array bounds, pointer errors in general. Again, I have to think about it, but maybe mistakes will happen no matter what.
I guess one of my "worries" with programming is that a wayward program could clobber some I/O somewhere and maybe even cause disk trashing. But I guess some random / errant I/O clobbering is not likely to trash a disk- more likely some other internal error.
A couple of years ago one of the servers I admin went down. Some kind of MB failure. All I know is the RAID 1 was badly badly trashed. Fortunately I had a standby system ready to go, and recent backups. Point is: some kind of MB failure was able to trash the filesystem.