DS2250T with a DS5000 8051 variant.

[syzygy]

I recently picked up several of these…because, you know, I don’t have enough projects.


These are from 1991 and the CPU is a DS 5000 variant of the 8051. Packaged with 8K of RAM (as program and data memory) and an RTC, all made non-volatile by that battery. The CPU can run at 12 MHz. All of this on one small board – almost a complete micro.





The carrier board is not made by DS and I am only just beginning to trace it out and see exactly what it is for. It’s easy enough to see the crystal and caps and the reset circuit. I also see the pull-up resistor packs connected to the bit switches. Not sure what the two empty sockets are for. One seems to be for a buffer and is attached to the four LEDS.




I have only just begun to follow the traces and I am starting with the 20 pin connector marked as MODEM.

The DS500 looks pretty interesting and appears to have a ROM monitor built in to allow uploading programs.

This is going to take some time.

I have attached a few data sheets if anyone is interested.

 

[gertk]

Ha, I gave away a few years boxes full of DS2244 modules I bought many many years ago on a HAM swap meet.
I still have a few of those. The DS5000 on those is very nice. It relies totally on the battery though since program is stored in SRAM.
Benefit of that is that you can reprogram them endlessly. The DS2244 also had a modem onboard and a DTMF decoder as well as an RTC.



These modules were probably used for remote monitoring/control purposes (over a telephone line). The batteries were all OK still after so many years. Probably due to the extreme low power demands of the RTC (in deep sleep) and the Sony SRAM.

To program the board you need to pull up/down one line which gets the CPU into serial monitor mode. There you can send a few commands to up/download the firmware and to set the division between program and data memory. I must have the original DOS software for this somewhere... It was kindly send to me by someone at Dallas along with a datasheet which stated 'confidential' or such

 

[gertk]

 

[syzygy]

Ha, I gave away a few years boxes full of DS2244 modules I bought many many years ago on a HAM swap meet.
I still have a few of those. The DS5000 on those is very nice. It relies totally on the battery though since program is stored in SRAM.
Benefit of that is that you can reprogram them endlessly. The DS2244 also had a modem onboard and a DTMF decoder as well as an RTC.

View attachment 1311250View attachment 1311251

These modules were probably used for remote monitoring/control purposes (over a telephone line). The batteries were all OK still after so many years. Probably due to the extreme low power demands of the RTC (in deep sleep) and the Sony SRAM.

To program the board you need to pull up/down one line which gets the CPU into serial monitor mode. There you can send a few commands to up/download the firmware and to set the division between program and data memory. I must have the original DOS software for this somewhere... It was kindly send to me by someone at Dallas along with a datasheet which stated 'confidential' or such

Yeah, I *think* the 2244T (which you have/had) is a later variation on the STIK theme that DS had and is listed in the 1992 DS data book, but not the 1989 data book.

Edited to add: I am *hoping* that the 2250T STIKs, along with the carrier board, will be a complete micro, needing only a power supply and a "base" computer with a serial port for programming (e.g., a PC running some terminal software). While not terribly powerful by modern 8051 standards, it is somewhat retro (35+ years ago) and with nothing else needed to play.

 

[gertk]

Edited to add: I am *hoping* that the 2250T STIKs, along with the carrier board, will be a complete micro, needing only a power supply and a "base" computer with a serial port for programming (e.g., a PC running some terminal software).

Probably will work as it is, since the bootloader/monitor is fixed inside the DS5000 and you have SRAM, 8 kB it seems.
From the bootloader you can set the partitioning with the W command.

 

[Bruce Tomlin]

I have one of these from a place I used to work back in the late 90s. It has a date code of 95 something, so the battery is probably dead. But looking up this image found me a copy of the PDF documentation, and it still has a floppy and an RS-232 to RJ-11 cable in the box. It looks like it's intended to plug into a socket ICE-style, so for just hacking around it shouldn't matter that the code memory has no battery power.

 

[syzygy]

That looks like a DS5000TK Evaluation kit - See the Dallas 1992 data book. Came with a floppy that you might be able to find somewhere if you don't already have that. edit: you wrote that you did have the floppy.

Here they call it a DS500TK Programming adapter.

 

[Bruce Tomlin]

Yes, it's in the original box (minus paperwork) and I put it where I can image the disk when I get around to doing something with that computer. (I used it last a few weeks ago to image some MC68HC16 related disks)

 

[wrm]

Aaah yes I worked with a DS5000 based system about thirty years ago. It was the first POS system in the country, developed for a large supermarket chain. Every time you power up the DS5000 it generates a random key and encrypts both the address and the data lines with that key, then you connect via serial and download the code, set the magic bit, and the system is secure. In addition to this it has a kill input which we had wired to an LDR, all of this potted with clear compound inside a metal box, with the option of running a fine wire maze that would also kill the code when broken... yea it was a bit of an overkill.

 

[Bruce Tomlin]

Aaah yes I worked with a DS5000 based system about thirty years ago. It was the first POS system in the country, developed for a large supermarket chain. Every time you power up the DS5000 it generates a random key and encrypts both the address and the data lines with that key, then you connect via serial and download the code, set the magic bit, and the system is secure. In addition to this it has a kill input which we had wired to an LDR, all of this potted with clear compound inside a metal box, with the option of running a fine wire maze that would also kill the code when broken... yea it was a bit of an overkill.

I was working on pay-at-the-pump stuff from 97 to 00, mostly on the code that talked to the actual gas pumps, but I got to see a lot of the related payment and POS stuff. That DS5000TK was just one of the random chip demo things that a place ends up with from chip manufacturers wanting you to use their chips.

Yeah, that encrypted RAM was kinda 80s spy movie crap, a bit much for just a cash register. But it's what you want if you're making a PIN pad, keys in battery-backed anti-tamper RAM, then you can be sure nobody has stolen your uber secret 3DES (lol) key. It's why there wasn't PIN theft in the US, apparently unlike Europe, as everything was encrypted starting with a potted PIN pad. The bad guys here had to make fake keypads to fit over the real keypads.

Putting the code into that same encrypted RAM seems a bit excessive, but this was in the 90s, long before everybody had Flash in their chip. Even though it added some security, it probably was the cheapest way to make a chip be re-programmable in the days of OTP EPROM. Flash in an MCU seemed to happen so suddenly in the late '00s, at least ten years after Flash had already been out. Someone might have had a patent on Flash in a microcontroller which nobody wanted to pay and just waited it out. Or maybe it was just tricky getting it to work with the same silicon process as the rest of the CPU. (which was apparently a problem with DRAM)

 

[syzygy]

So, I started tracing out the 20 pin connector labelled MODEM on the Arbitron HCV38 carrier board.


Qualifier: I could have mistakes, follow at your own risk.

This is enough to power up the board and try to get to an "It's Alive" moment. But for now, I want to think some more about it. Note the capacitor pair on the +5 in line.



The disk cap is no problem but I can't identify the value on the square one....I am assuming that is a capacitor. Additionally, using two different values of caps on a power line like this is for additional, or enhanced filtering - right?

A general question is what those two bit switches with the resistors as pull-ups are for. I have not traced them all out, but it is pretty easy to see that those are likely all GPIO lines on the DS5000. Given the relatively few number of GPIO on the 20 pin connector, after accounting for TX and RX, I am starting to get a vague pictire of what the board was designed to do. Tell me if this makes sense....Those bit switches are meant to be configured and read by the DS5000 and then do something with the GPIO coming out of the 20 pin connector. For example, setting an "On" time on one switch and an "Off" time on the other. I mean that could at least be a possibility.

Of course you can easily modify them to get at the GPIO for other applications. I have yet to find any reference to the Arbitron HCV38, although that company has been around for a while.

Any thoughts?

 

[Bruce Tomlin]

The base boards look like they were made to be generic enough that the SIMM boards could be used in simple projects.

But I am curious why it says ARBITRON on the board. The ratings people? (now owned by Nielsen) Not that I wouldn't expect them to have a use for something like this, it could be useful to have battery backed RAM to store a few days of TV watching data. And everything being in RAM means they can easily erase and reload it for the next deployment.

 

[syzygy]

Good Questions.
It definitely says that on the board.


For years, Arbitron was a part of Control Data Corporation (CDC) and in 1992, it became a part of Ceridian Corporation before the company was split in 2001 (from here) .They certainly made plenty of Gizmos. The seller said that the DS2250Ts were new but the carrier boards were not. They arrived in sealed bags. The unused, but usable, edge connectors suggest that it was a component board/part.

 

[syzygy]

Did a bit more work with the board.

I like to use these cable break out boards. A little bush league I suppose, but it is convenient and helps me avoid mistakes.

I brought *PSEN out to pin 20 of the cable (after carefully checking that it was n/c as I thought). Grounding *PSEN is necessary to get to the Serial Bootstrap Loader. Seems that this board was meant to be used with a DS5000 that was programmed elsewhere or they would have brought the line out to the connector.

Using a terminal program on a PC, I got to the "It's Alive" status.


As a quick test, I first got the CRC of the *8K RAM. Then, I filled the RAM with bytes of 'A0' and powered off. Upon powering up again, I saw that the CRC is maintained, suggesting that there is enough battery power to keep the contents of RAM after power down.

I also investigated the 4 LEDs in the upper right of the board. These are attached to resistor pack to GND. I could lite them with 5V but they are very dim. They appear to be designed to be operate from an external cable that attach to the nearby socket. They do not appear to go to any GPIO. I suspect that they are meant to be powered by 12V externally.

So far, so good.

 

[syzygy]

Took a closer look at the two bit switches and connected resistors.
One is for P0 and one is for P2.

Using the 'G' command of the monitor/loader, which reads and displays the ports (all 4, whether you like it or not) and "P" which writes a value to a port, I was able to make sure these work as expected.


I got a little ahead of myself and generated a code file to read the RTC (DEMODS5T) that appears in a data sheet. I used SBASM3 and had to make some changes. It did not work, it was doing something in response to the "R" and "W" but not working as desired.

I am going to take a step back and spend some more time understanding MCON with the goal of correctly setting the Program/Data space partition and writing a first program to flash an LED using one of the P1 port bits off of the 20 pin connector.

Edit: to be a little clearer, I did not have to use the "P" command. The changes shown were made by flipping bits on the switch.

 

[syzygy]

Found the time to do a little more on this project. Had to understand MCON and I think I have it correct now. As far as I can remember, I have *never* encountered "timed access" to a register before.

So we have a bit (MCON.1 / PAA) that has to be set before you can write the partition bits in MCON. This offers some protection against adverse effects from runaway code /power failure-induced resets and that sort of thing. Makes sense. In the serial bootstrap loader, you can play around with MCON easily. You can also modify the partition in software if you like.

So, I managed a simple blink program but with a routine to set the partition from code. Once set I didn't need to this because it stays set aside from the aforementioned possibilities. I attached the .asm and .lis files for the code as several attempts (including saving it as a CSS) within the posting screws up the spacing.

So...progress

 

[Bruce Tomlin]

As far as I can remember, I have *never* encountered "timed access" to a register before.

68HC11 has that, there are registers that you have to access with in the first 64 or so clocks of reset, and other registers that can be only written once after reset. There is a test mode that bypasses most of those restrictions, but you aren't supposed to use it as the normal operating mode.

I would not be surprised if this was made to be so picky as a reaction to how stupid easy it was to hit test mode on 6800 and 6809.
At a place I worked many years ago, I had a bug that jumped into data and hit the 6809 test opcode. That was how we found out that our hardware watchdog was missing !R/W from its PAL equations, years after the hardware was designed. For more fun, in the most recent version of the hardware, !R/W had been removed from the PAL inputs because it wasn't being used.