BMOW title
Floppy Emu banner

Falling into an Email Blacklist with DreamHost

naught-list

A blacklist can be a powerful tool for identifying spam email senders, but if you find yourself unfairly blacklisted, it’s maddening. Since sometime last September, roughly 30% of all my outbound customer-related emails have been rejected by the destination email server. Most of these are order confirmations or shipment notifications, and when they go missing, I get lots of frustrated inquiries from customers wondering why they never heard anything after placing an order. The rejections from the destination email server typically look like this:

<xxxxxx@provisoire.fr>: host mail.provisoire.fr[50.87.141.14] said:
550-“JunkMail rejected – pdx1-shared-relay1.dreamhost.com
[66.33.200.130]:40663 550-is in an RBL on rbl.unified-contact.com, see
Blocked – see 550 http://psbl.surriel.com/listing?ip=66.33.200.130″ (in
reply to RCPT TO command)
Reporting-MTA: dns; pdx1-shared-relay1.dreamhost.com
X-Postfix-Queue-ID: D4C0A30000327
X-Postfix-Sender: rfc822; steve@bigmessowires.com
Arrival-Date: Mon, 9 Jan 2017 14:07:03 -0800 (PST)

The exact message varies, but it usually mentions being on a realtime blacklist, or simply says my email was suspended, blocked, or refused. Other mail hosts such as Yahoo and Outlook.com take a passive-aggressive approach, and just drop the connection when I try to send email to one of their customers:

<xxxxxxxxx@yahoo.com>: delivery temporarily suspended: lost connection with
mta6.am0.yahoodns.net[66.196.118.34] while sending RCPT TO
Reporting-MTA: dns; pdx1-shared-relay2.dreamhost.com
X-Postfix-Queue-ID: B795D38088EC2
X-Postfix-Sender: rfc822; steve@bigmessowires.com
Arrival-Date: Wed, 4 Jan 2017 15:51:07 -0800 (PST)

I haven’t tested it thoroughly enough to be certain, but I believe the problem only occurs for auto-generated emails from the BMOW store, and not for customer support emails that I compose manually – even though both are sent through mail.bigmessowires.com to the same destination email server.

 
Identifying a Spammer

So how did I get on these blacklists? It turns out it has nothing to do with the content of my own emails, but is entirely due to my web and email hosting provider, DreamHost. They offer cheap and convenient hosting, which doubtless attracts a few people using their servers for evil purposes, sending spam. This causes the DreamHost email relay server to be placed on multiple blacklists, affecting all the other DreamHost customers who share that relay. While I only started to notice the problem last fall, this forum discussion reveals it’s been happening since at least 2013.

I’ve contacted DreamHost customer support several times about this issue. At first, they said the problem was resolved, and they had confirmed with all major blacklist providers that the block on the affected relay had been removed. And the situation did seem to improve temporarily, though it was never completely resolved. When the blocks grew more frequent again, I contacted DreamHost a second time on December 8 and received this reply:

The IP that’s showing up as blocked is actually a load balancer used for
sending mail, and it is used by hundreds of individual users. …
Over the last week, we have experienced a surge of compromised customer
SMTP users that were being used to send out malicious emails. Although we
monitor outgoing mail traffic closely and were able to stop these
compromised domains quickly, enough email managed to get through to cause
several blocklist providers to block a percentage of our email servers.
Many providers have already delisted the IP, but some holdouts do remain,
with whom we are actively working to fully resolve the block. If these
rejection notices continue for more than about 48 hours, please don’t
hesitate to let us know.

Sorry, we’re working on it, everything will be back to normal soon. But unfortunately it didn’t go back to normal, and a few weeks later I contacted them a third time. I received a detailed technical reply that focused primarily on a specific provider named 1&1. Apparently 1&1 doesn’t like the way DreamHost mail servers identify themselves when communicating – an issue related to reverse lookups involving a load balancer – so the DreamHost servers get blacklisted regardless of the content of the email. It wasn’t clear if a solution to this identification problem was imminent, or even possible. Customer support also mentioned that it can take up to a month to be removed from a blacklist:

some blacklist providers (Mostly European providers such as UCEProtect,
Backscatter, and LashBack), provide a paid “express” delisting, while
imposing an unreasonable long wait for manual or automated delisting (In
the case of LashBack, they autodelist after a month). As this amounts to
extortion, it is Dreamhost policy not to utilize paid delisting services
(they provide no added benefit to customers, encourage “bad behavior”,
and are generally a sign of an overzealous mail system administrator).

It seems unlikely that 1&1 is the only remaining problem, since my emails to domains like Yahoo and Outlook.com are also being rejected. As far as I’m aware, these are unaffiliated with 1&1.

 
Getting Past the Block

Monkey-Fix-it-300x285

DreamHost’s responses have all been apologetic, giving the impression that service should be back to normal soon. Maybe I should just be patient and wait, but it’s been three more weeks since that last customer support response, and the situation hasn’t improved. The 2013 forum discussion complaining of this same problem proves it’s not a one-time occurrence. And I received no reply to my most recent CS inquiry asking for a status update or work-around suggestions.

Maybe I should move bigmessowires.com to a Virtual Private Server with a unique IP, instead of relying on shared hosting. I’d consider that if I were confident it would fix the problem, but that’s exactly what the 2013 forum poster tried and complained didn’t work. It’s unclear to me whether that was his fault or DreamHost’s. Even if I knew it would solve the email problem, I’m a little reluctant to jump to a VPS due to the extra server admin hassles it would involve. I really like the convenience of shared hosting, where I focus entirely on the content and leave the server administration to someone else.

Perhaps it’s time to migrate the whole site to another hosting provider, but I don’t think so. I expect most other shared hosting providers will have similar issues, and possibly worse service. During the 13 years I’ve been with DreamHost, their customer support has been excellent. This email blacklist problem is the first time I’ve felt let down by their service.

The best option I’ve come up with is to move BMOW’s email functions to a more “trusted” provider, while leaving the web site and store with DreamHost. That would mean monkeying with DNS entries to relocate mail.bigmessowires.com and a few others, or else simply using a different domain like bmowmail.com for all email. Zoho looks like it might fit my needs, and it would be free for my level of usage. I need to dig into the technical details to confirm it would do what I think it does, and would actually solve the blacklist problem.

If you’ve ever dealt with an email blacklist dilemma, or have any other suggestions on how I might resolve this one, please leave your feedback in the comments. Thanks!

Read 10 comments and join the conversation 

Laser-Cut Case Experiments

case-examples-800

While I continue experimenting with 3D-printed case designs for Floppy Emu, I’ve also been working on revisions to the existing laser-cut case design. These new laser-cut cases retain the same overall mechanical “box” as the original, but use a variety of materials, engraving, and opening cuts to give them new styles. Maybe one of these will become the new standard case, or an optional alternative. I’m interested to hear from readers about their opinions on these, so please leave a note in the comments below.

First, let’s review the existing case design that’s included in the Floppy Emu “deluxe bundle”. It’s transparent acrylic, and is great if you want to showcase the Emu’s inner chips and circuits. It looks like something an electronics fan would use with an Arduino or Raspberry Pi. The opening for the SD card is rounded, so you can reach in with your thumb and index finger to extract the micro SD card. The overall style is pretty spiffy, if I do say so myself.

clear-angle-800

clear-tilt-800

clear-front-800

One drawback of the clear acrylic case is that it’s practically invisible. It’s 100% transparent, like looking through glass, so the etchings on the case appear superimposed on the contents inside, creating a visual mash-up that’s sometimes hard on the eyes. It’s not a huge problem, but maybe a modestly-tinted acrylic case would be better than full transparent. This one is about 25% gray tinted, which is fairly subtle. The tint is obvious when it’s placed side-by-side with the clear case, but less noticeable when viewed by itself. The opening for the SD card on the tinted case is also slightly different, with a more squared-off look.

clear-vs-tinted-800

tinted-angle-800

tinted-tilt-800

tinted-front-800

The clear and tinted cases both have a gloss finish, giving them a sort of future-tech look. Unfortunately the gloss finish also makes fingerprints stand out clearly, which is a bit annoying. But even if you don’t mind a few fingerprints, not everyone loves the see-through look. If you enjoy showing off the geeky internals, it’s great, but some people prefer a functional case that looks more like a standard peripheral than a science exhibit. To that end, I made two more case designs using matte acrylic that’s mostly or completely opaque.

The first of these is built from a “matte clear” material, which really isn’t clear at all. It’s like frosted glass, and you can vaguely see a blur of color through it, but no details. If hiding the internals is what you’re after, this will do it. The matte material has a very pleasing texture, and doesn’t show fingerprints at all, so the case always looks clean. This case uses the same squared-off opening for the SD card.

frosted-angle2-800

frosted-tilt-800

frosted-front-800

The final case is built from a matte white material, and is my attempt to create something that looks more like a miniature Apple disk drive, using Apple’s “Snow White” design cues. It has a series of parallel grooves on the top plate, like the Apple IIc and IIGS and the Apple 3.5 inch external drive. The front opening even has a fake status LED and disk eject hole engraved in it, to make it resemble the front face of a real external floppy drive. The squared-off opening for the SD card is intended to give the feeling of the drive door from a 5 1/4 inch drive. This matte white case does a pretty good job of matching the style of the 3D-printed cases I posted last time, but is much faster and cheaper to make.

snow-white-angle-800

snow-white-rev-angle-800

snow-white-front-800

The major drawback of the matte white case is that the engraved areas are difficult to see. It’s white engraving on a slightly different shade of white background. You can see from the photos how subtle the grooves and other engraved details are. Depending on the angle of the light, they may be slightly more or less visible, but they never really stand out. The title photo displaying all four cases was actually photoshopped to make the top grooves stand out better, but the other images of the matte white case were not retouched. Overall I think it’s still a direction worth pursuing, but I definitely wish there were a way to give those engraved areas more contrast.

An alternative that just occurred to me is to actually cut the grooves and fake front details all the way through the material, instead of engraving them. This would certainly make them visible, but then you’d be able to see through to the Emu board inside. That’s not really accurate – you can’t see the Apple IIc logic board through the grooves in its case, for example, because there’s a second layer of plastic under each groove. Hmmm.

Read 7 comments and join the conversation 

3D Printed Floppy Emu Case Experiment

3demuprint

My clear acrylic laser-cut case design for Floppy Emu looks sharp, but doesn’t match the visual style of classic Apple II or Macintosh systems. It’s also a bit tedious to assemble. A few people have suggested a Floppy Emu case that looks more like a retro 3.5 or 5.25 inch Apple drive, with Apple design details and a beige/white color. In that spirit, my friend Allan recently did some experiments with a 3D printed white case for the Floppy Emu, and the results look promising.

3D printing has the advantage of making any shape possible, instead of being constrained to interlocking 2D pieces with laser cutting. This enables the case to be built as just two pieces, rather than the six pieces needed for the laser-cut version. It also enables the button plungers to be built directly into the top plate, so they can’t fall out, making the whole thing easy to assemble. If you’ve struggled with the button plungers in the laser cut case, then you’ll appreciate this.

With 3D printing, it’s also possible to approach the appearance of a retro computer accessory. The case can be matte white, instead of glossy acrylic. 3D grooves and other small details can be modeled directly into the case, instead of being limited to 2D etching. Nobody will confuse it with a 1984 Apple peripheral, but at least it will be a lot closer.

I’ve mostly avoided 3D printing until now, because I’ve found it to be slow, expensive, and imprecise. Each one of these test prints required many hours of printer time and baby-sitting. The large time sink wouldn’t an issue if I used a commercial 3D printing service instead of home printing, but initial estimates are that a 3D printed case would cost perhaps 3x as much to manufacture as the current laser-cut case design. Maybe that would still be OK if the improved appearance and ease of assembly made it worth the extra cost to customers, but it’s a lot to ask.

Imprecision has been my biggest concern with 3D printing. Using my own budget printer, it seems half the prints I make come out badly deformed. Even the “good” prints always have a smooshed corner or deformed detail or other minor problem. It’s not terrible if you’re making a prototype for self-use, but I’m not sure it would be acceptable if making hundreds of them for sale to customers. Allan’s first case experiments showed some of the same types of deformities, although he was able to improve it somewhat in later iterations by making adjustments to his printer settings. Here’s an example of what I’m talking about:

20161130_114925_resized copy

Note how some of the grooves at left aren’t clean and even, and there’s a diagonal texturing across the whole surface that’s visible in some areas but not others. It’s hard to see in the photo, but the text and icons also have a slightly uneven appearance.

What surprised me was a test print made in Allan’s friend’s high-end 3D printer: it’s much more professional-looking, with very consistent print appearance across the whole case. That’s the print you see in the title photo above. I don’t know exactly what model of printer it was, or the cost, but I’ll try to find out. Here’s a close-up of the case from the better 3D printer, for comparison (click the image to see a high-resolution version).

20161130_130251 copy

A question to readers: would a 3D printed “retro-style” Floppy Emu case interest you? What features do you think would be most important? What do you think would be a fair price for something like this?

Read 13 comments and join the conversation 

Fruit + Electronics = Piano

The human body is electrically conductive. A piece of fruit will also conduct electricity, as will basically anything else that’s organic. We can leverage this fact to create a fun little afternoon project: a digital fruit piano. No soldering is necessary, and the whole thing takes less than an hour, even for a total beginner like my 9-year-old daughter. What sound does a banana make? Let’s fine out.

While humans and fruit do conduct electricity, they’re pretty bad at it. Both typically have an electrical resistance that’s in the 1-megaohm range, depending on how moist your skin or nectarine is. This design uses your body and the fruit as part of the circuit, flowing current through the human-fruit “wire”, but the high resistance means that the currents involved are tiny. The piano player isn’t going to feel a shock, or even feel anything at all. She’ll just lightly touch different bits of fruit to play a song, almost as if by magic.

This isn’t my original design. The idea of controlling a digital device by using the human body as part of the circuit has been around for quite a while, and the Makey Makey has popularized it with a nice little kit. If you like this type of project, definitely check out the Makey Makey! But if you’re lazy and cheap like me, you can build a similar device yourself with only an Arduino and some hookup wire, a few resistors, an audio speaker, and a selection of bananas, pears, and peaches.

 
How does it Work?

The basic concept is simple. Each piano key is a voltage divider circuit involving two resistors: one 1-megaohm resistor and one piece of fruit. Touching the fruit will change the resistance in the circuit, resulting in a change to the voltage at the junction between the two resistors. The Arduino can measure this changing voltage with an analog input, and use it to control an audio speaker.

To complete the circuit, one hand should be connected to the Arduino’s ground pin, while the other touches the fruit. Current will flow through one hand, up the arm, across the chest, down the other arm, and back to Arduino GND. For convenience’s sake I connected GND to a metal ruler, but a plain jumper wire also works fine. For the fruit connection, just stab a wire straight into the fruit. Soldering a banana works poorly…

banana piano

If the hand isn’t touching the fruit, then the whole fruit-hand-body section becomes an open circuit with infinite resistance. In this case, the circuit simplifies to just +5V connected through a 1 meg resistor to the analog input. Because the analog input draws virtually zero current by itself, there will be no current flowing in the circuit and no voltage drop across the 1 meg resistor (remember Ohm’s law V = iR, so when i = 0 then V = 0). The voltage measured at the analog input will still be +5V, and Arduino’s analogRead(A0) function will return 1023, the maximum possible value for its 10-bit resolution.

When the hand touches the fruit, the fruit-hand-body section forms an organic resistor of about 1 megaohm. Current will flow from +5V through the real 1 megaohm resistor, then through the fruit-hand-body 1 megaohm resistor and down to ground. The total resistance between +5V and GND is 2 megaohms, and with two equal value resistors, the voltage at the point midway between them will be half the total voltage drop. That means the Arduino’s analog input will see 2.5V, and the analogRead(A0) function will return a value around 512.

To make a piano, a simple Arduino program is needed to continuously poll each analog input, and play a tone if the analog value is below an appropriate threshold. I used a threshold of 800, but you’ll need to experiment to find the value that works best for you. The sample program uses tone frequencies corresponding to the notes CDEFGA of a C major scale, making it easy to bang out favorites like Mary Has a Little Lamb, Hot Cross Buns, and I Ate the G Key.

Each of the six fruits is connected to one of the six Arduino analog inputs A0 to A5. If you’re wiring this up at home, duplicate the pictured banana circuit six times, connecting the first to A0, the second to A1, and so on up to A5. Then connect your speaker’s black wire to GND and red wire to Arduino pin 8. Happy fruit playing!

void setup() {
}

void loop() {
  if (analogRead(A0) < 800)
  {
    tone(8, 523, 130);
    delay(80);
  }
  else if (analogRead(A1) < 800)
  {
    tone(8, 587, 130);
    delay(80);
  }
  else if (analogRead(A2) < 800)
  {
    tone(8, 659, 130);
    delay(80);
  }
  else if (analogRead(A3) < 800)
  {
    tone(8, 699, 130);
    delay(80);
  }
  else if (analogRead(A4) < 800)
  {
    tone(8, 784, 130);
    delay(80);
  }
  else if (analogRead(A5) < 800)
  {
    tone(8, 880, 130);
    delay(80);
  }
}
Be the first to comment! 

The Vintage Computer Festival is Almost Here!

Vintage Computer Festival West XI is happening next weekend, August 6-7 at the Computer History Museum in Mountain View, California. I’m belatedly dusting off the hardware for my exhibit and preparing the demos and signage. Anybody have a trade show style backdrop they’d like to lend me? :-)

I’ll be exhibiting three of my hand-made computer creations, each of which has gone through some modifications for the show:

 

BMOW 1 – My original custom-made CPU and computer that kicked off this blog and my journey into hobby electronics. BMOW 1 is an 8-bit CPU, implemented with 7400-series TTL discrete logic and a few PALs. Built around this is peripheral hardware for I/O, sound, and video. The end result is a custom creation that’s vaguely similar to an Apple II in its performance and capabilities. And it’s all hand wire-wrapped, with thousands of individual wires.

New for VCF West, I’ve cut a porthole in the bottom of the case and added interior case lighting, to showcase the glorious mess of wires inside. I was nervous I’d break something while removing and replacing all the parts in the case, but BMOW survived and is still running strong.

 
68-katy-breadboard  68katy-pcb

68 Katy – A 68000-powered single-board Linux system that began life as “Linux on a breadboard”. It’s a super-minimal Linux system containing only a 68K family CPU, 512K ROM, and 512K RAM. I began with a 16 year old Linux distro and hacked it to support this hardware and its tiny memory size. The original version was literally built on a breadboard, though the current version is now a PCB with a serial port for I/O.

During testing for the VCF show, I found that 68 Katy was no longer running reliably. I’d previously overclocked the 8 MHz-rated 68008 CPU to 12 MHz. Restoring an 8 MHz oscillator seemed to fix the problems – for now.

 

Nibbler – Another custom-made CPU and computer with a 4-bit (nibble) architecture. Designed to be simple to build and easy to understand, Nibbler’s CPU core consists of just 13 discrete 7400-series logic chips – individual counters, registers, buffers, and gates. To complete the machine, it adds a few ROMs and an SRAM, as well as pushbuttons, an audio speaker, and a text display. With a 4-bit CPU and 4K of memory you might think Nibbler couldn’t do anything much more interesting than blink an LED, but it boasts some nice games and demos. Like BMOW 1, it’s all hand wire-wrapped.

Nibbler will see a significant change for the VCF show, time permitting. The original design uses a 4K ROM for storing the program – when you want to run a different program, you need to replace the ROM. I plan to substitute a 16K ROM with a DIP switch to control the highest two address lines, so I can select between four different stored programs without resorting to ROM swapping.

 
Antique and Custom Computers Galore

Beyond the BMOW stuff, the other exhibits planned for VCF West XI look great! They include Eric Schlaepfer’s MonSter 6502, Bill Buzbee’s Magic-1, vintage DEC and Data General systems, IBM mainframes, Amigas, TRS-80s, S-100 hardware, and much more. Check out the full list here.

The show hours are 9:30-6:00 on Saturday the 6th and 9:00-5:30 on Sunday the 7th. Do you plan to attend? Leave a comment below, and I’ll keep an eye out for you!

Read 1 comment and join the conversation 

ROM Disk Creation with ROM-inator II

ROM Disk

Good news, ROM-heads! The software needed for ROM-inator II programming is now available for Mac OSX as well as Windows, and I’m marking the occasion with this step-by-step guide for creating your own bootable ROM disk. Here’s what you’ll need in order to get started:

Hardware

Software and Files
You can find the latest versions of all of these in the Downloads section of the ROM-inator II project page.

  • ROM SIMM Programmer utility software
  • FC8 compression command-line software
  • ROM-inator II 512K base ROM file

Disk Image File

Lastly, you’ll also need a disk image file that defines the contents of your ROM disk. If you’ve previously used a Floppy Emu disk emulator or a Macintosh software emulator like Mini vMac, you’ve doubtless seen these kinds of disk image files before. For ROM-inator II, the disk image file should be in “raw” format, meaning it contains only the actual contents of the Macintosh disk with no extra headers or checksums. Files in this format typically have a .dsk suffix for their filename. If in doubt, confirm that the first two bytes of the file are 4C 4B (hex). You’ll find an example disk image at the ROM-inator II project page.

 
Prepare the Disk Image

When using compression, the current model ROM-inator II SIMM can store a disk image as large as about 5.5 MB – the exact limit depends on the contents of the disk image and its compressibility. You can use your own pre-existing disk image, or start with this empty 5.5 MB disk image. If you’re using your own disk image, its size must be a multiple of 65536 bytes (64 KB).

I recommend Mini vMac for editing the contents of the disk image. It’s a cross-platform tool that emulates a Macintosh Plus, and you can quickly mount disk images by dragging them into the Mini vMac window. Once you’ve mounted a few different disk images, you can copy programs and data between images to configure your ROM disk image however you’d like it. If you’re unfamiliar with this process, check out this disk image setup tutorial for the original ROM-inator.

On Windows, another alternative is HFV Explorer to transfer data directly to/from the disk image, without a Mac emulation intermediary.

Don’t forget to include a System folder in your disk image! The Macintosh will need an operating system in order to boot. You can find installers for Systems 6 and 7 at Macintosh Garden – as well as all sorts of other vintage Mac software.

 
Compress the Disk Image

compress-data

Next, you’ll compress the disk image file so that it fits in the space available in ROM. The compression format is FC8, a custom format that I designed specifically for this purpose. The FC8 compressor is a command line program, so you’ll need to run it from a command prompt (Windows) or terminal (Mac). The ROM-inator II disk driver uses FC8’s block compression format, with 65536 byte blocks. To compress the disk image, type this at the command line:

fc8.exe -b:65536 mydisk.dsk mydisk.fc8

This will compress the disk image file mydisk.dsk, and create the compressed file mydisk.fc8. If the fc8 program or the disk images aren’t in the current directory, you’ll need to specify the path to those files on the command line.

Check the size of the resulting mydisk.fc8 file. For the current model ROM-inator II SIMM, the compressed file must be no larger than 3.5 MB (3670016 bytes). If it’s too big, remove some files from your disk image and try again. Note that simply deleting a file from the disk image may not help, because “deleting” normally just marks sectors as unused but doesn’t actually set their contents to zero. To truly delete the file and gain better compression density, you may need to create a new disk image from scratch and then copy all the files from the old disk image. It’s a minor hassle, but worth it for the improved compression density. For reference, the example disk image compresses to 63% of its original size, when using FC8 65536 byte blocks.

 
Create the ROM Contents File

You’ll need to concatenate the 512K base ROM file and the compressed disk image file, in order to create the final ROM contents file. The base ROM file contains the low-level code needed to operate your Macintosh, including the ROM disk driver that performs on-the-fly decompression of your disk image’s data. At the time of writing this file is named iisi+romdrv1.2.rom, but check the project page to get the latest version. The concatenation is performed on the command line, using the built-in programs copy (Windows) or cat (Mac OSX and Linux):

copy /b iisi+romdrv1.2.rom + mydisk.fc8 myrom.rom (Windows)

cat iisi+romdrv1.2.rom mydisk.fc8 > myrom.rom (Mac OSX and Linux)

This will concatenate the files iisi+romdrv1.2.rom and mydisk.fc8, and create the combined file myrom.rom. If the files aren’t in the current directory, you’ll need to specify the path to those files on the command line.

The resulting myrom.rom file should be 4 MB (4194304 bytes) or less, in order to fit the space available in the current model ROM-inator II SIMM.

 
Program the SIMM

simm-programmer-software

The final step is to program the ROM-inator II SIMM with your new ROM contents file. Connect your ROM SIMM Programmer to your PC or Mac’s USB port. Turn the programmer’s power switch to OFF, insert the ROM SIMM in the socket, then turn the switch to ON. Open the ROM SIMM programmer utility software.

From the software’s GUI, select myrom.rom as the file to write. Programming speed will be fastest when “verify after writing” is selected as the verification option. Ensure the SIMM capacity is set correctly (4 MB for the current model ROM-inator II SIMM), then press the Write to SIMM button.

After programming is complete, turn the programmer’s power switch to OFF, and then remove the ROM SIMM from the socket. Have fun with your new ROM disk!

Be the first to comment! 

Older Posts »