rcgldr

I've since confirmed what I suspected, that 2 x AA 2400 mah NIMH batteries don't work, not enough voltage to keep the 6301 running. The original battery holder specifies 2 UM-3 AA batteries, which would be non-rechargeable zinc-chloride batteries, 1.5 volts (or a bit more when new), versus rechargeable AA's which are 1.2 to 1.4 volts each. The 3 x AA 2400 mah NIMH pack is working, but avoid charging over 4.2 volts, since that is what the board outputs to an empty battery holder.

I did a crude test with a 3 x AA 2400mah NIMH pack at 3.97 volts. After about an hour it was up to 4.00 volts, so the circuit board is recharging the batteries. I then used an offline discharger / charger to get an idea of the mah charged, running it at it's minimum of 100 ma discharge / charge. At close to 4 volts, my guess is the circuit board outputs about 12 or so ma (could be more). I recall a comment that the circuit board draws about 1.3 ma. That would translate into about 2.5 hours per day to break even. However, the 4 volts is close to the unloaded 4.2 volts from the circuit board. At lower voltages it may generate more current. It came with a 2 x AA pack, but I don't recall what type of batteries it used, and 2 rechargeable batteries would normally have 2.6 to 3.0 volts, but doesn't seem like enough to power the 6301. Maybe special batteries were used? If the recharge rate is too low, an option would use 2 packs, charging one offline, and swapping packs when the Atari is on. Still there's the issue of running the 6301 and circuit board 24/7, so I have the battery pack unplugged most of the time.

I'm not sure how much of a recharge occurs. I measured 4.2 volts from the circuit board, but I don't have a way to measure the current. Nimh batteries self-discharge even with zero load. A single cell li-po battery has the right voltage range, 3.8 v (low charge) to 4.2 v (max charge), and virtually no self discharge. I would need to buy connectors to create a cable for this. An alternative would be using two packs, charging one externally, and swapping packs while the ST is on. Then again, I'm concerned about the 6301 running 24/7 over an extended period of time, so most of the time, I leave the battery pack disconnected.

About a year or so ago, I took my Atari stuff out of storage to see what worked. On the 520 ST, I noticed the empty battery holder, and it wasn't until after I started this thread that I realized it was for the clock (a clue was the board was named "time-saver"). I contacted someone that sold Atari stuff back in the 1980's but he didn't remember that board (and he doesn't have his ST anymore). I'm also using a Sony KV 1311CR tv as a monitor (it can handle 480p), with some special cable made for it. For me it's a novelty system now, and I was surprised it still works (it's 35 years old). I made some utilities for the ST and did some general programming on it until around 1990, when I bought my first PC (486 based). As for serious work with the 68000 family, from 1980 to 1987, I worked at a company that converted from an AMD 2901 based processor to the 68000 family for the multi-tasking, multi-console based systems they sold. The company was a Motorola development site, so they got early releases of the 68020, 68030 (just before I changed jobs) and later 68040 (after I had left the company).

On my 520 ST, there's an empty space on the main board between the monitor and midi connectors. I attached an image that shows a white 2 x AA pack holder (it's empty) there with plenty of space left over (3 size A cells could easily fit there). This is what the board originally looked like. Maybe something else went there on later boards. Recently I switched to a 3 x AA pack once I measured 4.2 volts output from the time saver circuit board. (I don't really use it though, see below). In the 1980's AA nicd had about 600 mah, up to 1000 mah later on. Size A nicd would have been 850 mah, now 1400 mah. Modern nimh AA are 2400+ mah. A prior post mentioned a current draw of 1.3 ma, with 3 x AA at 600 mah, that should be enough for 2 weeks on a full charge. The issue is time on versus time off. If the ST was on 2 hours a day on average, it would need to charge the pack at around 20 ma (taking losses into account), just to break even, and I don't know if the board outputs that much current. A pair of packs could be used, charging one of the packs offline, then swapping packs while the ST is on. I'm more concerned about the lifespan of a 6301 running 24/7 (my ST is 35 years old), so most of the time, I don't have the pack plugged in. I've occasionally used it, most recently with the nimh batteries, just to confirm it works. Nimh batteries self-discharge even with no load, and I don't know what percentage of time the ST would have to be on for a break even situation. A single cell li-po battery has a working voltage range of 3.85 (low charge) to 4.20 volts (full charge), which should be enough, and no self-discharge, but I'd be concerned about potential failure (heat) with a li-poll battery.

Then again, I'm wondering if that 6301 chip would still be running today if a battery pack had been used to keep it running for what is about 35 years now. It's easy to disconnect now with the Futaba plug (the original one used a 9 volt battery type connector, not as convenient).

This board replaces the 6301 in the keyboard, and the 6301 plugs into the board. The red and black wires go to a rechargeable battery pack. I use 3 x AA NIMH batteries (2400 mah). The board is called a "time-saver". I got this back in 1985 or 1986 when I got my 520 ST as part of a developer kit.

Intel had a utility to convert 8080 (any maybe Z80) source code to 8088/8086 code. Part of the reason that SAHF and LAHF instructions exist is for this conversion. This allowed a large library of CP/M based code to be converted over to initially CP/M 86, and for the PC, what was going to be either DRDOS/PCDOS/QDOS (it ended up being PCDOS). I'm an old guy that started programming back in 1968 in High School on IBM 1130 (assembly, Fortran, APL), and some Fortran IV for IBM 360. In 1969, assembly language for CDC 3150 and IBM 360. My first job was back in 1973, a multi-tasking multi-computer server / data base system using HP 2100 mini-computers (server code was assembly, offline code Fortran IV). Then through a series of mini computers, mostly working on operating systems. I started with the 68000 and assembly in 1980, where a 68000 based hardware was replacing old custom processors based on AMD 2901's. A few of the programmers at that company bought Atari STs when the 1 meg versions for $1000 came out (1987?). The group also bought Atari 400s for $20 ($70 with $50 rebate), around 1987, and I learned 6502 assembler. One guy made alarm systems based on Atari 400s, using the 20 pins of input for the joystick controllers connected to the sensors. Other processors, Z80, Z8 (unusual in that it had 128 registers). Worst instruction set was Data General Nova 1100, a "risc" machine with only 4 registers. Later I started work on embedded systems using ARM processors, working on operating systems again until the OS's became commonly available.

When did the usage of the term IKBD for the 6301 begin? I don't recall this, and it's not in the old books, like Atari ST internals. The Atari ST Internals book has example code for receiving data from the 6301 by hooking into the interrupt, but it uses the BIOS call to send data. I may have code for this archived somewhere. Turns out I probably got my 520 ST in 1985 (not 1986). So I started this thread because I didn't know if this date | year issue was specific to my old 520 ST or was also an issue for later systems (which apparently it is).

Looking at old code (from Jan 01, 1986), there is a workaround for the low year gap, at least for older models like the 520 ST (I don't know about later models). There is a BIOS call (trap #14) to send a message to the keyboard / clock / 6301 chip. To set the date|time, the message is 7 bytes long, $1B, followed by 6 BCD encoded bytes for year, month, day, hour, minute, second. This workaround allows all 100 years to be set: 00 to 99, representing 1980 -> 2079 by GemDos. Since 2000 was a leap year, the 6301 didn't need any special handling for 02/29/2000. The 6301 wraps around from 99|12|31 23:59:59 to 00|01|01 00:00:00. The BIOS call takes an address, and count-1, in this case 7-1 = 6. Trap #1 is still used to get the keyboard time, and needs the same workaround as posted above. There's no BIOS 6301 input call, since TOS defaults to ignoring 6301 responses, but code can hook into the interrupt vector and manually receive data from the 6301. However, the Gemdos call (trap 1) with the workaround posted earlier can be used to get the data|time from the keyboard for all 100 years. * * kbd (6301) output message * a0 = adr message * d0 = # bytes * kbdot: subq.l #1,d0 trap count is -1 move.l a0,-(a7) output kbd msg move.w d0,-(a7) move.w #25,-(a7) trap #14 addq.l #8,a7 rts * set date|time message * $1b, followed by 6 bcd bytes: * yy mm dd hh mm ss kbdmsg: db $1b,$20,$03,$10,$12,$34,$56

I already posted that the 6301 stores the year as 2 BCD digits in a byte, so $00 to $99. Year values that are a multiple of 4, including $00, are properly handled as leap years. Side note - If I boot my 520 ST, and then save desktop, the desktop.inf file ends up with date|time 11/20/1985 12:00:xx am (which was a Wednesday), apparently a default date|time chosen by the TOS on my 520 ST. That may be a way to determine the TOS version? The TOS on my 520ST is not pulling the date|time info from the keyboard clock. I need to use a date|time utility to get date|time from the keyboard (trap 14) and set GEMDOS date|time (trap 1).

Note that my workaround stores the proper year in the 6301. Years {1980 ... 1999 2000 ... 2047} end up stored as BCD {$80 ... $99 $00 ... $47).

Yes, just the socket. There are no components on the bottom of that board (just the pins to plug into the 6301 socket). The board replaces the 6301, then the 6301 is plugged into the board. The black and red wires go to the rechargeable battery pack. I did a web search but couldn't find it. This was on a 1986 Atari 520 ST as part of a developer kit. I don't if the "time-saver" board was made by Atari or by a third party. I did a web search for "atari st" battery clock, and found a description of the components that could be used, but no luck in finding the board.

Looks like the 3 x AA nimh battery pack is working. (I used a 4 cell back with one of the cells short circuited to make it a 3 cell pack.) Here is an image of the circuit board, which plugs into the 40 pin socket on the bottom of the keyboard, and in turn has it's own 40 pin socket for the 6301. This board was included on my 1986 520 ST.

The keyboard controller / clock is a 6301. When sending a set date|time message, the date|time is sent as 6 bytes of BCD data, each byte containing 2 BCD digits. The 6301 will ignore any byte with an invalid BCD digit {$A ... $F}, but will update the remaining bytes if valid. When getting a date|time message, the date|time is received as 6 bytes of BCD data. Both GEMDOS and BIOS set and get date|time using binary fields: date: bits 15->8 (7 bits) year-80, bits 8->5 (4 bits) month, bits 4->0 (5 bits) day of month, time: bits 15->11 (5 bits) hour, bits 10-5 (6 bits) minute, bits 4-0 (5 bits) second/2. For BIOS set keyboard date|time, it gets year field, adds 80, converts to BCD. Year values {00 ... 19} are mapped to {$80 ... $99}. Year values 20 ... 79} are mapped to {$A0 ... $F9}, which the 6301 will ignore. Year values {80 ... 127} are mapped to byte values {$00 ... $47} (bit 8 is dropped since it ends up in a byte), which the 6301 will accept. For BIOS get keyboard date|time, it maps BCD year to binary, subtracts 80, and puts the result into a 7 bit field. {$80 ... $99} get mapped to {00 ... 19}, values {$00 ... $47} get mapped to {48 ... 95}. I created a work around with my get|set date|time utility, which will work for years 1980 -> 2047. Example code: ; adjust before setting date|time, d4 = date ; year field = year - 80 cmp #$2800,d4 ;br if year field lt 20 bcs.s set0 add #$7800,d4 ;add 60 to year field set0: ... ; adjust after getting date|time, d4 = date cmpi.w #$6000,d4 ;br if year field lt 48 bcs.s get0 subi.w #$3800,d4 ;subtract 28 from year field get0: ...