Retro Fix: Packard Bell Platinum Pro 755 (1996-1997)

The first Windows-based PC I was introduced to in the early-1990s was a Packard Bell Legend 660 or comparable. It had the Microsoft Entertainment Pack 2 bundle featuring Rodent's Revenge and Rattler Race, two games I grew very fond of and would later develop a few games and variants heavily inspired by that. In that era I'd often ride my bike to the local Radio Shack to top the scores on their demonstration computers.

Decades later, I still appreciate that creative age of desktop computing even if these systems are collectively referred to as "Packard Hell" by select groups. At some point in time I found a Packard Bell Platinum Pro 750/755 tower on the curb to giveaway. I brought it back and eventually set it up in another retro corner. Since I planned to use it as an intermediary machine for creating and archiving old floppy media, I swapped out the Iomega zip drive with a 5.25" drive instead, knowing I also have some external ZIP drives if ever needed (although zip disks were short-lived and notoriously prone to click-of-death failure). Read Full Article

Retro Exploration: MDT-870 Mobile Data Terminal (1986-1996)

I recently impulse bought an ElectroCom Communication Systems MDT-870 radio car terminal for $5 at a surplus sale. Never knew much about these sort of computers but learned a lot since, and yet remain largely in the dark about this particular model given the complete absence of any documentation or schematics online.

This model in particular was common in squad cars in the 1980s-1990s. Some metadata extracted from a ROM that I dumped when troubleshooting indicated "COPYRIGHT 1986-1996 ELECTROCOM AUTOMATION INC." and the particular ROM in this unit had a generation date of March 25, 1996. Based on this, the department may well have used it for the better part of a decade before phasing it out in favor of more contemporary solutions.

This exact model appears in an early scene of Terminator 2: Judgment Day, where T-1000 uses it within a police car to query the details of John Connor. Having now used the real device the movie depicts, other than the simulated sound effects in the film the actual on-screen display appears to have been produced and filmed on the actual MDT-870. Of course the one on the set was not wired to actual police databases, but the text on it was typed within one of its free-type interfaces.

Initial Power-up and Short Glimmer of Life

When these were actively used, they had a variety of hookups to police radios, databases and similar. The one I received was barebones aside from some of the wiring that itself appeared cut and severed at various points. It runs on 2A 12V DC power, typically wired to the vehicle's battery/alternator. After a little bit of review I traced the original positive/negative wires and reworked them into a simple AC-DC power converter adapter and spliced a new cord to go along with it, from a typical computer adapter.

I was able to power up the unit and heard some remarkably 80s-sounding beeps as it booted up. It initially read "SIGNOFF ACCEPTED" and then took me to some integrated applications. This included a MEMO WRITER, QUERY DRIVER STATUS, and some others that I can't recall.

Alas, this was a short-lived effort as after typing some keystrokes and photographing the images above, something fizzled out and I lost all display and signs of activity.

Hardware Analysis

Unfortunately, not a single trace of documentation, schematics or ROM dumps for this system exist online. I found very few references to it at all. There were sporadic mentions of it appearing in movies, a fan-made STL model of the device citing Robocop 1, and other users looking for any documentation in hopes of setting one up in their own personal vehicles for nostalgia or show. I found one post from more than 15 years ago where someone did have the full gauntlet of schematics, programming guides, service manuals and even hardware-based interface adapters for PC communication. Alas I wasn't sure how to even approach contacting that user at this point in time.

Disassembly was not too difficult. In fact there exists plastic doors on the back of the unit for direct access and swapping of the CDVR and ROAM ROMs. The entire unit promotes itself as "Proudly Made in the U.S.A." Several of the ICs including all ROMs, CPU (OKI M80C85A-2 x2) and Graphics Controller (Intel P8725) were pre-socketed using machine pin sockets. I know many advocate for such sockets, but when wanting to quickly remove and replace ICs when troubleshooting and testing, I still find the flat leaf-type DIP sockets much easier to work with and less prone to bent and broken pins. That said, I did eventually swap the three machine pin sockets for the ROMs with leaf style to make my own life easier as I was burning and testing all of those ROMs continuously.

To actually get at the core ICs, you have to unscrew the back (and any brackets that may be attached) and carefully separate the two halves. The back half houses the small amber-lit Clinton Electronics 798P1NGLP picture tube and a simple speaker. Underneath this is the video sub-board and on the other side the main logic board. A ribbon cable transmits data from the logic board to the CRT board and ultimately into the display. The front half houses the membrane-based keyboard, LEDs, variable controls for adjusting Sound Volume, Light (Front LEDs) and Display Brightness. A side control also allows you to adjust the keyboard-based light brightness.

The system has two 80C85A CPUs (8085-based, the minor successor to 8080 and comparable to Z80 except with syntax I find to be much more cumbersome to decipher). The CRT is driven by the Intel 8275 (P8275) video controller. It has two banks of Sharp LH5168 CMOS SRAM and oneM81C55-5 CMOS SRAM a variety of other controllers and ICs. It also has a TMP82C55AP CMOS Programmable Peripheral InterfaceI noticed pin one of the uppermost CPU was bent underneath itself when inspecting the chips, but that didn't seem to have any impact.

ROM Summary and Dumps

There are three ROMs installed in the logic board, with only one of them providing a checksum value to compare clean ROM dumps. They are all programmed onto common 27CXX EPROM chips. Through trial and error, I made the following educated conclusions:

  • 502.87003.51 MDT870 CKSMC7B3 MDX-ROAM V2.2 (27C256) - This is the core ROM / OS. It is designed to interface with special frequencies/radios and other input/output devices for querying data, recording memos and otherwise communicating in a pre-mobile, pre-WWW era.
  • 501.64519.51 641.07910.00 V1.1 U4 CHRGEN (27C64)- This is the character generator. Mine wound up corrupt before I was even able to get a proper dump, so I am unaware of the precise layout of the original. However, after experimenting I was able to reconstruct a usable CGROM derived from the HD44780 controller after reversing and reordering them. If this chip is corrupt or removed from the set, the screen displays solid blocks as typical when no character generator exists.
  • 501.64520.51 641.07900.00 U16 V1.1 CDVR (27C64) - Originally I was unclear what CDVR stood for in this context. But it became clear as soon as I removed it from circuit that it is the CRT Driver. With it removed, the CRT cannot render anything but a high-pitch raster or several as if suffering vertical collapse.

I made ROM dumps of all three of these on my vintage EP-1 programmer. I verified the checksum of the ROAM firmware matched, but had no basis to compare the other two in the event they were corrupt. I later concluded the CHRGEN ROM had indeed corrupted for reasons unknown, whereby once I had fixed the display issues itself that chip would show mostly solid blocks and EPROMS I burned from the dump did the same. Trying the original in my more modern TL866-II programmer detected faulty pin(s), and comparing a dump made from it to any on either programmer always yielded errors. However, I'm confident the ROAM and CDVR dumps are functional and precise.

Below is a ZIP file containing the complete collection of ROM dumps I made in various formats (BIN, Intel Hex, Mitsubishi Hex and another format or two). It also includes my usable 2022-created character generator ROM, one variant with underlines and one without.

  • MDT-870 ROM Dumps .zip file (MDX-ROAM, CHRGEN [Corrupted], CDVR, CUSTOM CHRGEN 2022)

Character Generator Woes

After a lot of testing, trial and error I eventually wound up with a semi-bootable MDT-870 again. I believe there was one bad CPU, a few dry solder joints, at least one shorted/dislodged socket, and something astray in an SRAM chip (and am still not convinced the two SHARP chips are not damaged, this will take more testing).

The beep codes were back and the display was, well, showing something or other but basically all corruption.

I recognized even when typing that the glitches correlated to the keys typed, which is usually a sign of bad video RAM or a failed character generator. More testing of the original EPROM proved it to be a problem. I tried a fresh 2764 EPROM with the prior dump and experienced the same symptoms. Peaking into the ROM dump itself and I found almost entirely FFs or 00s, which definitely seemed peculiar compared to other ones I'm familiar with.

Typically character generators define the character sets using 8x8 (or 5x8 or 5x7 or some variant) where each single HEX value depicts one byte-row of character data. So FF would mean "fill in the entire row solid" and 00 would be "keep the entire row blank" but usually you'd see intermediary hex values, such as 3C to indicate "fill only the inner four bits) and this is how basic characters can be defined. Row-by-row. With this in mind, I created a dummy character generator filled with FFs but also randomly changed some values, as an experiment. This yielded the following:

That confirmed to me that the display problem was indeed just a wonky character generator. And, after some additional experimenting with patterns and characters I concluded the CGROM for this set is a pure data dump of constructed characters, it contained no additional logic or coding. This was fortunate as if it intermixed coding and byte data as some do it'd be vastly more difficult to guess the structure going forward.

I then went on a roundabout manner of creating some new character generator that'd at least satisfy the need to see what text is showing up on the screen. As a foundation I used the binary data constructs of the HD44780 and pasted them into a new binary file, repeating the entire set multiple times until padded at 01FF to match the original ROM size. When I tested this new ROM in the machine, I could tell we were headed down the right path.

Seen above was the initial run of a new character dump. I was in some input screen that allowed me to free type. The characters in the middle were me starting with ABC...890. You can see firstly how they are all inverted. This is because the CRT itself is mounted upside down then reflected off a tilted mirror to project through the front of the terminal. The other problem is that one letter gets skipped with each one I press. So A=B, B=D, C=F and so on. This was an immediate clue that the layout of the original CGROM repeated each character twice, AABBCC...889900. Eventually I realized that the most-significant bit (leftmost in a row of 8) determined whether the character would have an underline or not. If padded with "FF" there'd be an underline, otherwise there wouldn't be. This likely explains the need for replicated lines/characters. To my knowledge, lowercase characters were never displayable or included.

To resolve the reflected issue, I passed the binary format into a reverse line script. I then pass that into a binary-to-hex script. This could then be sit out into another binary file to appear the correct orientation when viewed through the terminal's mirrored screen. It was then a matter of comparing keystrokes with what the screen depicted, and swapping around the ordering to ultimately end up with a version depicting all characters successfully. You can see below how the mirror affects the display, both on the raw CRT and when viewed from the front with the redone character set.

It Lives Again, But How To Initialize?

Through the various iterations of it working, not-working then working again, any and all previously preserved data seems to have been wiped clean. Some of that likely happened while I was making contact with various pin-outs of the numerous memory-related ICs.

Before I had a proper character display again, I actually wound up with a different start screen. It would throw the error "NO HOME CHANNEL IN LIST" and then enter an empty typing screen. Periodically it would then interrupt with the error: "CHECK CONNECTIONS TO RADIO" Still, being able to type was interesting itself, at least it was something!

But after the final cleaning of the keyboard and another loss of power, then some more IC tinkering, the new screen is different once more. I'm not stuck at the "INITIALIZE MDT" screen and no characters have any affect.

It is evident based on the text data extracted from the ROM dump (see below) that the ROM has some internal way to define channels and so on. Somewhere in the code lies the string: PRESS "C" TO ENTER RAD. CHANNELS and related ones as well including ENTER RADIO CHANNELS and PRESS "X" TO EXIT. What I'm not sure of is how to achieve this, or if that by itself also requires interfacing with an external system.

If I make any further progress on this, I'll update this post. One interesting discovery worth checking into more thoroughly is the Open Hardware Driver for CRTs. This seems like a promising approach to easily hacking this or similar sets to display typical video output on its crisp amber display. "The driver circuit takes a 0-3.3V analog signal for deflecting the beam along the X and Y axis. The amplifier has enough bandwidth to handle NTSC video, so displaying video along with vector letters and shapes is also a possibility with this circuit."

Extracted Strings from ROM Dump Metadata

As part of the main ROM dump (502.87003.51 MDT870 CKSMC7B3 MDX-ROAM V2.2) I parsed through identified strings. They are included below, as well as their relative memory location at least as laid out in a decompiled Z80-derived version of the 8085 source. The fact that I was unable to find any references to the applications I had initially observed, may indicate that those along with the radio codes and data were still cached in some form of non-volatile memory but ultimately wiped out.

  • 0005: Generated 3/25/96
  • 04D5: WARM
  • 156F: MD:4
  • 1699: <FORM>
  • 24BD: @ZXCVBNM,.
  • 24CD: 1234567890
  • 2EF7: 99RESET
  • 2F2F: SET ?
  • 2F99: TX LEVEL ADJUST (R49) TEST 2
  • 3249: (FOR CHANNELS 1-9)
  • 3267: (FOR CHANNELS 10-16)
  • 327E: XMIT TIME IS MINUTES (03-25)
  • 32A4: PRESS "X" TO EXIT
  • 333C: MDT-870
  • 334E: FIRMWARE SERIES 20 V1.2
  • 336E: REV. DATE 3/25/96
  • 5405: <ERROR>
  • 5415: <PASS>
  • 5420: <TEST>
  • 64F8: LED TABLE

Bally Arcade: New Life with SD Card Solution from BackBit

I received my BackBit with Bally adapter this week and it is excellent, as the first solution that allows loading and managing applications direct from Micro SD. The previous longstanding solution (UltiMulti) had a fixed number of programs and you'd have to toggle a variety of dipswitches to load any given one. There are still benefits to the UltiMulti and Lil White RAM, in particular for BASIC programs. BackBit is for ROM/binary image loading so can't natively load PRG/WAV format files.

A Note About +5V Requirements

For the Bally adapter, the important point to keep in mind is that it requires the external +5V feed, done through the light gun port. This is equivalent to the way Lil White RAM gets its power or the original BASIC adapter. Read Full Article

The Deceitful "Bait-and-Switch" Tactics of Auto Dealership Prize Giveaways

I receive unsolicited prize giveaways in the mail all the time, mostly from regional auto dealerships trying to promote their inventory and overstock. The tactics used to entice the recipient into reading and reacting to the send-out can be both entertaining and aggressive. The goal of these mailings is naturally to maximize consumer response and get as many people as possible through the doors to sell them vehicles. For this reason, everybody wins!

Some dealership promotions come enclosed in very important looking "NextDay Verified Fast-Tracked Mail" envelopes designed to mimic actual overnight services while still being sent regular media mail (complete with handwritten jargon about there being crucial documents inside.) Others come with a generic key that must be checked against a lock box at the dealership.  Almost all of them include some variant of a scratch-off or pull-tab ticket with some fantastic prizes on the table.

Although they are all the same in the end (the "prize" you get to claim is rarely ever worth the trip), I have found some to be far more deceptive and misleading than others. As such, I'll classify these mailers into two categories...

The 'Honestly Hopeless' Prize Giveaways

If you receive a flyer for any sort of event within 25-100 miles of your address and it includes any gambling-inspired game for you to "play-to-win", rest assured you will be a "winner" every time. The majority of marketing flyers that I receive, as sensational as they are, have still been honest in their identification of what you've won, the fine-print and the abysmal yet accurate odds of winning any of the non-trivial prizes.

By that, I mean that at least 99,997 of 100,000 send-outs will contain the same identical winning ticket and its value is typically not worth the money in gas to claim. Assuming they send out 100,000 flyers and are true to their word, only three of those 100,000 stand to win anything beyond a couple dollars in cash or a restrictive gift card.

In these more honest flyers, you scratch off the play area or otherwise reveal that you have a winning ticket, such as by matching three like symbols in a row. Comparing the ticket results to the prize legend will inevitably reveal that you have won $2 or something of similar monetary value. To claim it, you must visit the dealership during the aforementioned promotion.

Here is a rundown of what happened the last time I went to claim my $2 prize from these sort of giveaways, and what you should expect:

  1. I arrive at the dealership to a hoard of salespeople roaming about. Immediately I walk past the crowd and into the tent.
  2. I show a staff member my winning ticket and advise them I am there to collect the prize (all $2 of it).
  3. The salesperson says he will go get the cash but it could take awhile and suggests I look around the lot while waiting. I respectfully decline and tell him I'll just wait right there.
  4. Minutes pass and eventually he comes back with a crisp $2 bill. I thank him and start to leave.
  5. "But before you go, " he remarks, "we are having a $500 giveaway tomorrow and it is free to enter, interested?"
  6. "Hmm, OK?" - Now I'm on the hook. He tells me he just needs to take down my information so I can be reached if I win.
  7. I am now put through a fairly rigorous survey that asks everything about my current vehicle, what kinds of vehicles I may be interested in, what my financial abilities are for loans, how much I could afford a month and so on.
  8. After repeatedly insisting that I am unwilling to put anything toward a new vehicle at this time, despite how low of a figure he goes down to and how much he talks about them having the perfect vehicle for me, he finally concedes and ends the survey.
  9. I leave (and no, I did not win the prize).

All told, it took around 15 minutes to claim my $2 prize and over a half hour until I was finally out of there after entering the large cash giveaway (which, like most free things a person signs up for, probably also resulted in more marketing materials coming my way). If you live less than a mile away from one of these dealerships and don't stick around past receiving your small monetary prize, and have some time to kill, you can almost break even.

The 'Deceptively Hopeful' Prize Giveaways

Some promotional flyers I receive are much more misleading about the alleged prize won. With these types of marketing materials, all indications are that you have won a significant prize and that you are one out of 100,000 to get so lucky. I will give a detailed rundown of a recent flyer that I received and acted upon.


This flyer came with a pull-tab game not unlike those you'd see in the corner of a tavern. As you can see, this prize giveaway is so extreme that it has to be "QR CODE PROTECTED," whatever that actually means (it's a 40 character string that I suspect is identical on everyone's card). The prize legend seems pretty straight-forward, as depicted below.

  • YELLOW: $50,000 Cash - 1:100,000 ($50,000 Retail Value)
  • GREEN: 55" 4K TV - 1:100,000 ($1,500 Retail Value)
  • PURPLE: Apple iPad Pro - 1:100,000 ($1,000 Retail Value)
  • BLUE: $25 Gift Card - 99,997:100,000 ($25 Retail Value)

Simple math confirms that everybody is a winner. There is a 99.997% chance of winning the $25 gift card, which means that this is the prize all but three people of 100,000 will win. It is identical to the $2 odds in the previously described giveaway. The remaining three, with a 0.001% chance each, will supposedly win either the cash prize, iPad or 4K television.

With that in mind, imagine my delight when I pull the tabs and see this:

Four green jokers in one game! Yes! Surely this means I won the 4K TV, right?! It seemed pretty apparent from the legend that this was the case, at least.

So excited was I about this win (OK, there might be a hint of sarcasm there), that I got in touch with a friend to share the great news. "Well what do you know? I got the same matching green jokers in game 1! In fact, our cards are identical for both games."

"How could this be," I thought. Only one person in 100,000 was supposed to win the 4K television, and the odds of that happening were astronomically low. I skimmed over the the fine print. Did it require us to purchase a car before claiming the prize? "NO PURCHASE NECESSARY TO ENTER OR WIN. PURCHASE DOES NOT INCREASE CHANCES OF WINNING." Apparently not.

I dialed up the number on the front and entered my confirmation code as it instructed me to do. Rather than getting any confirmation about my prize, the automated machine instead began asking a series of questions relating to the purchase of a new vehicle, special loan rates etc. I hung up. There was one other line in the small-print that caught my attention: "Bring invitation to event location to compare your confirmation code to prize board to determine your prize."

Unfortunately, it would be nearly a 100 mile round trip, completely out of my way from anything, to get my prize. Still, the 4K TV would more than make up for the loss of gas and time (again, maybe a trace of sarcasm here). So, after printing off some relevant state statute codes on prize giveaways, off I went.

Here is a rundown of what happened when I went to claim my 4K television that the prize legend suggested I had won.

  1. I arrive at the dealership, park and walk in. For an event that professed "overwhelming response" and imposed a strict "1 vehicle per family" rule in their marketing, they sure had a lot of cars for sale, and not many visitors.
  2. I go up to the counter and tell the employee or manager that the legend indicates I won a 4K TV with the green jokers and would like to claim the prize.
  3. He says "give me a minute and we'll see what you've won." So I wait patiently, while pointing out once again that all indications from the flyer is that four green jokers would win a television.
  4. Before confirming my prize for me, I was told to take a seat at a table and wait. Eventually he came over and began giving me the same sort of survey that all the others give about my current vehicle, what I'm looking for, etc. I again advised him I was not looking for any vehicle nor would I be purchasing one, but I was there to claim the prize.
  5. Following is an excerpt of our conversations about my anticipated prize:

    ME: Looking at the legend, you can see four greens equals win–55" HD TV right?

    DEALER: Well, all green can win this, can win this, can win this... All the color codes, sometimes they're all yellow, sometimes they're all purple, sometimes they're all green... You can win any of these prizes, not just that.

    ME: I mean, do you see the misleading part here then?

    DEALER: ...I can kind of understand that, but I see these every day and they're all like that. They can tell you you've won the world–if you ever get one of these again, there's only one way to determine what you win...

    ME: You know there's legislature against misleading giveaways–

    DEALER: Well, this was sent to the state attorney's office before it was sent to you, and they had to OK it.

  6. After more than five more minutes of back-and-forth, he asked if I was looking to buy a new car. After telling him "no," we finally get up and go to the "prize board" to compare the code.
  7. My code shockingly did not match any of the big listed prizes, including that for the TV. Instead it fell under the "All Other Numbers" section for the $25 gift card.
  8. After more standing around waiting for him to walk to the opposite end of the building, eventually he brought back my $25 gift card. (These $25 gift cards actually cost $10 to purchase and have some pretty rigid use-cases.)

So that's it. By adding the clause that the actual prize is determined by the prize board, and despite heavily suggesting that four greens equate to the 4K TV, it seems dealerships are able to scrape by the legal standards required to send these out. If you are curious about where dealerships purchase these sort of flyers, check out for one example, which sells a massive variety of scratch-off, pull-tab and other "game winning" flyers for dealerships in bulk for pennies a piece (with 10,000 minimum in most cases).

One should question, however, how unscrupulous a company might be when they rely on sensationalism and deception to get people through their doors in the first place (and when they justify said actions merely because the state attorney cleared them). If the flyer was this misleading, I would believe that any deals brokered with the same company would be equally suspect.  Others feel the same way, based on the steady stream of 1-star ratings this company received in the days and weeks immediately following this "promotion," totaling nearly half of all reviews received since their inception and dropping their overall rating substantially.

Read Full Article

SAMSUNG Remote Test Lab: Test Android Apps on Real Devices for Free

For the past couple of months, I've been working on a much-delayed update to my Android application Scribblify.  The original Android version was released back in early 2013 and hadn't been updated on Google Play since then. Although it paled in comparison to the iOS counterpart, the first Android version still received positive reviews and was downloaded 200,000 times. Having released a major 4.0 update to the iOS version earlier this year, it was time to bring the Android version up-to-speed.

One of the greater challenges experienced with Android development occurs when it comes time to test. I previously wrote about the increasingly fragmented iOS platform, but even with a handful of different iOS devices sporting different resolutions and technical specs, nothing quite compares to Android device dispersion. In my updated Android app, for instance, I support all Android devices from API Level 15 (Android 4.0.3) up. According to Google Play, this makes the app compatible with 9,098 Google-certified devices. This list encompasses at least four years of devices including phones, tablets, phablets and more. Understandably, with such a large range of devices comes an equally large range of technical specs.

So, when it comes time to test an Android app, the more devices available to experiment with the merrier. It is particularly worth testing against the multitude of different device resolutions and DPI specifications to ensure that all assets scale appropriately, as well as testing against various OS versions to ensure nothing breaks. Google provides the Android Virtual Device (AVD) Manager, available through Eclipse, Android Studio and as a standalone tool. AVD Manager allows you to create custom-tailored virtual devices spanning the entire core spectrum of Android units, provided you've installed the necessary packages via SDK Manager.  However, Android emulation via AVD is traditionally sluggish and will not always behave as expected. There are also more dedicated and responsive Android emulators for testing including Bluestacks, which I wrote a tutorial about previously (other popular Android emulators include Andy, Xamarin, and YouWave).

Testing on Physical Devices using SAMSUNG Remote Test Lab

For more assured Android app testing than software emulation can reasonably provide, it is always favorable to test on physical devices where available. Basic Google-certified tablets with the latest Android OS can now be purchased for as little as $30-$75 at many retailers and work wonderfully for testing.  Even some of the more high-end phones and tablets can be affordable when bought used online at sites like eBay. As long as the device is Google-certified and supports Google Play, it is ripe for app testing.

Still, there is another avenue for development testing against an assortment of popular and new Android-powered products–without having to deplete your life's savings while amassing a mountain of test devices. Cloud-based device testing is a growing way to test your app on physical Android units around the world. Popular players in this field include Keynote by Dynatrace, Sauce Labs and Remote TestKit. These and other related services are generally subscription-based but offer free trial periods.

Sometimes though, as the saying goes, the best things in life are free. One free cloud-based testing service that I've grown to love is the SAMSUNG Remote Test Lab. This completely free service, provided by SAMSUNG, allows you to interface with a couple dozen different phones and tablets of diverse specifications.

Getting Started

To get started, you will need to register a free account in the SAMSUNG Developer Portal. After registering and verifying your email address, you can make your way over to the Remote Test Lab landing page. The testing application has a few minimal technical requirements including JavaScript, Java Web Start and a browser from this decade. If any of the configuration is missing the page will alert you.

From this page, you can browse through the various devices or narrow down the results by category using the tabs across the top.  Most of the test devices are available in multiple different OS versions,making them ideal for testing against OS changes that may affect particular features of an app. The range is substantial, from the now archaic 2.3.3 through 5.1.1 at the time of this writing. When you have arrived at an attractive device that you wish to test against, select the appropriate parameters from the drop-down lists (OS Version, Device List [Location], Reserve Time).

The free testing system works using Credits. Every day that you login to the SAMSUNG developer portal, you will receive 20 additional credits towards testing. These credits accrue so if you sign-in three different days you will accumulate 60 credits. Each credit is good for 15 minutes of physical device testing, and you have to commit to 30 minute minimum sessions (you can also cancel device reservations early to receive unused credits back). In any case you are not likely to run out of testing time too quickly, considering each day of logging in buys you another five hours of testing time.

When you are ready to launch the test device, just hit the Start button.

Running the Hardware Simulator

After starting a device simulator from the SAMSUNG Test Lab, a Java applet will launch. Depending on your browser and OS configuration, you may be prompted a couple of times to open and run the script (say Open / Yes / Run where appropriate). If you are currently not signed in you will still be able to do a 5-minute Pre-Test, which is a good idea to ensure the selected device is functional and usable on the simulator.

When the device first launches, hit OK after reviewing the terms and then choose the device's language (a great way to test translations, but it is generally not changeable until you start a new session). Basically, SAMSUNG asks that you clean up any of your test files and data from the device before exiting so that they do not get cluttered with test content or interfere with other users. The devices are not reset after each session so it is relatively common to find remnants of past testers when connected, including their own signed-in accounts at times.

From here out, you can interact with the device's screen using your mouse to simulate touch. Some devices may support alternative touch simulators such as the use of a stylus. In my test cases, I did come across a couple devices that would not respond to mouse control due to various causes including a prior tester changing the unlock method (another reason why trying them without being signed-in first is a fine idea).

Uploading and Installing your App

The SAMSUNG simulator software uses right-click context menus to configure its setup and manage applications.

  • Right-click on the device's screen to adjust screen properties including device orientation, and to capture screenshots and video.
  • Right-click on the device's frame (chrome) to access test-related controls including app management and logs.

To easily upload, install and run your app to the device, do as follows:

  1. Right-click on the device's frame (i.e., on the SAMSUNG logo in the screenshot above).
  2. From the context menu, select Manage > Application to load the Application Manager.
  3. From the Application Manager view, click New and then double-click on your desired APK to upload it.
  4. With your uploaded app selected in the Application Manager list, click Install.
  5. Once installed, make sure the test device is unlocked and that your app is selected in Application Manager, then click Start.
    1. You can alternatively browse to the application directly on the device, once installed, to launch it.

    If all was successful, your app should then launch and you will be able to interact with it as if using a real device. If the device does not have working WiFi connectivity, simply right-click on the frame and select Manage > Reset WiFi. You can switch the orientation to landscape by right-clicking the screen and selecting Orientation > Landscape.

    Advanced Tools

    The test device environment supports device logging akin to LogCat in Eclipse / ADB. To view the logs, you can right-click the device frame and select Test > Logs. All of the logs will then appear in a new window and can be filtered by log level and/or string. You can also clear the log or save the data to a file just as you could from Eclipse. In addition, the SAMSUNG devices support remote debugging by selecting Test > Remote Debug Bridge and then connecting to it from your local ADB shell (this is the same manner described in my BlueStacks tutorial).

    When you have completed your tests, you can uninstall your app(s) from the Application Manager by selecting it and clicking Uninstall. To exit the emulator, right-click the frame and select Exit. Finally, it is a polite gesture to then cancel the reservation in the SAMSUNG Test Lab site (under "My Reservations") so that the device can be used by other parties before the entire duration is up.

    This free service is tailored to SAMSUNG devices and does not have nearly the number of available devices as some of the paid services mentioned previously. Even so, it offers a wide-enough spectrum of test devices to rather adequately test most of the problem areas of device. Another very promising and free cloud testing service on the horizon is Google's Cloud Test Lab, which promises to offer virtual access to many devices as well as advanced automated tests. This service is not yet available publicly but is certainly worth keeping tabs on.