MAME, MESS, and Other Fun

If anyone wants to try it out, I just committed my CPU core and driver for the Manchester Small-Scale Experimental Machine (SSEM), or “Baby”, to the MESS SVN depot.  It currently runs all known SSEM programs bundled with David Sharp’s SSEM simulator, available here.

I am not entirely happy with the fact that it is compatible with all of the programs, though.  Certain programs in particular, i.e. “nightmare.snp”, would not run on the SSEM had it ever been extended to the full 8192 words of storage space of which it was theoretically capable (per some SSEM history sites), as they pad out the unused 8 address bits with pretty patterns.

And now, a pretty picture:

The controls are as follows:
Up / Down: Move the selected store line up/down
Button 1: Halt / un-halt the SSEM
1-8, Q-I, A-K, Z-,: Toggle bits 0-31 of the currently-selected store line

I just had a really weird thing happen to me.

My primary central media PC in my apartment, as of March of last year, had four 1TB drives in it.  Three of the drives were arranged in a RAID5 configuration, the fourth drive was standalone due to the on-board RAID controller not supporting a large enough single volume to encompass all four drives.

There was a brief power outage in August of last year.  When I powered the computer back up, I was greeted with an unfriendly POST message from my RAID controller informing me that three 1TB hard drives were connected and one unknown hard drive.  Oops.  It was at this point that I was grateful that I had selected a RAID5 configuration, and all the more grateful that I had never gotten around to putting any data on the loose drive.  I was able to put the computer to work rebuilding the parity data over the next couple of days, and everything was fine save for that one drive.

After reading about the various issues with 1.5TB and 1TB Seagate drives, just for kicks I decided to look up the model numbers of the drives, so I fired up the “Intel(R) Matrix Storage Manager”.  It then informed me that it had detected a new non-RAID drive, and asked me if I would like to reinitialize the drive so that its parameters could be read.  Sure enough, the drive seemed to have leapt back to life.  After rebooting the media server, the drive is still there.  I really have no idea what would have caused it to leap back to life like that, but I know I am sure as hell not going to be putting any important data onto it anytime soon.

Incidentally, all four drives appear to be ST31000340AS, firmware revision SD15, which is the firmware and model number affected by the bricking problems that have been raging across the Internet lately.  Hmm.

I recently purchased a Commodore 64 off of Craigslist. One of the interesting things that came with it was a Video Byte II cartridge - a still, black-and-white frame grabber that plugs into the User Port.

Fascinated, I cracked open the case and found it to be rather devoid of parts - only four ICS: An LM324N (quad op-amp), a CD4066BCN (quad bilateral switch), and two 555 timers.  This was even more impressive, since it uses no ASICs, FPGAs, or anything else traditionally associated with video capturing.  In addition to the ICs, there were some transistors, resistors and capacitors, of course.  After completing a partial schematic of the device based on PCB scans, I decided to try a different tack: reverse-engineering the software itself by using VICE.

It turned out to be a very simple loop utilizing CIA #2’s ability to time the duration that CNT2 is held high on the User Port by decrementing Timer B each time Timer A underflows. The loop reads pixels in column-by-column by performing a dummy read off of CIA #2 Data Port B, which in turn causes a pulse on the /PC2 handshaking line. This triggers the Video Byte 2 to pull CNT2 high for a duration corresponding to the brightness level of the upcoming pixel. The loop then checks the value in Timer B; 0xDC is Dark Gray, 0xDA is Medium Gray, 0xD8 is Light Gray, and 0xD6 is White.

Simple. Elegant.

My changes to VICE’s source tree are available on request; my implementation is currently highly deficient in that it simply reads in raw pixel data from an image in a hard-coded path with a hard-coded name. However, the actual CIA-related changes and functionality should be there. For what it’s worth, VICE did not actually have proper support for the Timer B mode that is used by the Video Byte. Mode 0×60 should decrement Timer B when Timer A underflows only if the CNT line (attached to the User Port) is held high; by contrast, VICE treats it the same as mode 0×40, which always decrements Timer B when Timer A underflows.

And now, pictures:

“Look upon my works, ye mighty, and despair!”

I’m writing this blog post shortly before I completely reformat my laptop specifically to offer a warning to those of you who think that you’re somehow “protected” against passively-installed viruses, trojans, spyware and/or malware being installed on your computer just by visiting a website because you’re using Mozilla Firefox: You’re not.  I’m using Firefox 3.0.4, the latest version, and now I have to reformat my laptop to get rid of the absolute infestation that I’m dealing with.

I was searching for a fairly amusing series of images last night via Google.  I clicked on one of the top links that Google came up with and was immediately greeted with three popups and my hard drive being hit constantly, bogging down my laptop to the point where it took five minutes to bring up the Task Manager so that I could forcibly terminate Firefox.  Within minutes I saw several command-line windows pop open to run some sort of batch file, I saw five or six processes in the Task Manager with names such as “2jdj23rk.exe”, and since last night I’ve had fairly continual popups springing open with IE.

My best efforts with HijackThis, Super Anti Spyware, Spybot Search & Destroy, and AVG Anti-Virus have not restored the status quo, so right now I am backing up all of my important files so that I can reformat and reinstall.