no-software internal RTC

Current solutions and designs.
User avatar
rubber_jonnie
Posts: 435
Joined: Thu Aug 17, 2017 7:40 pm
Location: Essex
Contact:

Re: no-software internal RTC

Post by rubber_jonnie » Sun Jan 14, 2018 1:27 pm

exxos wrote:
Sun Jan 14, 2018 12:53 pm
rubber_jonnie wrote:
Sun Jan 14, 2018 12:37 pm
It's slightly annoying that I did have a picture of a battery back up mod for the ST keyboard, but I don't seem to be able to find it right now :(
Peters site has the diagram of it. I have seen it done on keyboards I have had in the past, but mostly was just leaked batteries so got binned.
I meant an actual photo, rather than a diagram, it did give a good indication of what needed to be built, and it was quite small.

Just playing with my STE just now, and I think the CosmosEx can do clock setting from the Pi, may give that a try, though not immediately helpful since the CosmosEx is not available :(

I can see why something transparent is appealing though, as you don't need to be plugging in carts, doing very difficult internal soldering, or messing around with various bits of software.

Not only did I need Troed's Y2K corrector, but I also had to find a version of the ForgetMeClock software that had been modified to allow setting of dates past 1999, and then I had to use the Areal clock accessory to put the time on screen!

It's frustrating that I'm no programmer, as I'd love to get involved at TOS level.
Collector of old Atari things:
800XL + Ape Warp mod, 2x 1010 cassette, 1050 + Happy mod, 65XE (128k) & XC12, SIO2SD, 2600jr, 7800 and Lynx II
Atari 520ST (1Meg) + Gotek, 1040STFM + Vortex ATOnce + Gotek, 1040STF long button floppy, 4160 STE with Gotek and ROM switcher, 4160STE with 32Mhz booster, ROM switcher and CosmosEx, not to mention various bare ST boards for testing including a PAK 68/2 :)
Plus the rest..
Amiga stuff, Mac stuff, Sinclair stuff etc...
www.electronicnothingness.co.uk

Petari
Posts: 453
Joined: Tue Nov 28, 2017 1:32 pm

Re: no-software internal RTC

Post by Petari » Sun Jan 14, 2018 1:47 pm

Since RP5C15 has 6 bits for year, it means that it could count years up to 2043 - calculating by start year=1980 , and 6 bits can be 0-63 . That means that chip self is actually OK for this century too ( well, for first 43% of :D ) , but TOS handles it not properly. Probably just displaying part - but that needs some accurate tracing of whole thing. May happen soon, and that would be nice TOS patch :D
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

User avatar
rubber_jonnie
Posts: 435
Joined: Thu Aug 17, 2017 7:40 pm
Location: Essex
Contact:

Re: no-software internal RTC

Post by rubber_jonnie » Wed Feb 21, 2018 5:10 pm

Chris, just how easy would it be to make a on piece RTC board based on our re-engineered FGMCII? I know we have the two piece model, which is most excellent as a plug in cart, and we have the smaller board that can be fitted internally if you wish.

But what about a one piece board as per the original? Would it be any cheaper to make it a single board?
Collector of old Atari things:
800XL + Ape Warp mod, 2x 1010 cassette, 1050 + Happy mod, 65XE (128k) & XC12, SIO2SD, 2600jr, 7800 and Lynx II
Atari 520ST (1Meg) + Gotek, 1040STFM + Vortex ATOnce + Gotek, 1040STF long button floppy, 4160 STE with Gotek and ROM switcher, 4160STE with 32Mhz booster, ROM switcher and CosmosEx, not to mention various bare ST boards for testing including a PAK 68/2 :)
Plus the rest..
Amiga stuff, Mac stuff, Sinclair stuff etc...
www.electronicnothingness.co.uk

User avatar
exxos
Site Admin
Posts: 2887
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: no-software internal RTC

Post by exxos » Wed Feb 21, 2018 10:58 pm

rubber_jonnie wrote:
Wed Feb 21, 2018 5:10 pm
Chris, just how easy would it be to make a on piece RTC board based on our re-engineered FGMCII? I know we have the two piece model, which is most excellent as a plug in cart, and we have the smaller board that can be fitted internally if you wish.

But what about a one piece board as per the original? Would it be any cheaper to make it a single board?
I did design it originally.. But, Basically if I did a direct clone as well, I would have had to stock 2 lots of the RTC IC's, and at like £12 a go, I didn't want to invest in like 10 kits of internal and external. So I went for just doing the PCB and re-using the RTC internal kits on the cart pcb. From my point of view it was a good move as the RTC stuff just doesn't seem popular.

So yes, a possibly a RTC pcb could be produced like the original.. Though It wouldn't be much smaller than it is now (unless the through-port was removed) and I got it as small as I could already.

I also opted for 4 layers to have a solid 5V and 0V between the "in and out" side of the cart pcb. I couldn't actually route it on 2 layers either and I had a few attempts at it, just wasn't happy with how it was ending up. The original cart is pretty clever with the routing for just 2 layers, but I wasn't to happy with the thin tracks across the board anyway. I was thinking of expansion stuff added after the cart should have a solid power rail (Why I opted for 100uF ceramic also). But in doing that, doubled the PCB costs, but I want to make something "solid" as didn't want to risk voltage drops and grounding issues on anything connected on the through-port.

With all that in mind, PCB wise it wouldn't have made much difference to have the RTC IC built on the PCB or not. So it was down to costs really with the thought of me selling the kits. Though , as you know, nobody was really interested in the cart and doing small runs of basically 3 just isn't cost effective. Would need to do a run of more like 100 to get the price per pcb down to something sane, but again, I don't think they would sell anyway. Even if I just produced the PCB's on their own its still a huge outlay/risk on my part.

Ultimately the falcon RTC boards will be used as optional add ons for my boosters.. Its not a external solution, but I think overall people want a neat internal solution.. I don't think people are that impressed with the small RTC board I (we) did already. So IMO I think its just a dead end project. If loads of people wanted a simple external cart pcb, then I could produce it yes, but for me, I think investing the time & cash into other projects is a better choice.
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.

User avatar
rubber_jonnie
Posts: 435
Joined: Thu Aug 17, 2017 7:40 pm
Location: Essex
Contact:

Re: no-software internal RTC

Post by rubber_jonnie » Thu Feb 22, 2018 9:16 am

Yeah, understood. If nobody buys it, then it is a bit of a dead end.

Still I did enjoy working on it, which was part of the plan :)
Collector of old Atari things:
800XL + Ape Warp mod, 2x 1010 cassette, 1050 + Happy mod, 65XE (128k) & XC12, SIO2SD, 2600jr, 7800 and Lynx II
Atari 520ST (1Meg) + Gotek, 1040STFM + Vortex ATOnce + Gotek, 1040STF long button floppy, 4160 STE with Gotek and ROM switcher, 4160STE with 32Mhz booster, ROM switcher and CosmosEx, not to mention various bare ST boards for testing including a PAK 68/2 :)
Plus the rest..
Amiga stuff, Mac stuff, Sinclair stuff etc...
www.electronicnothingness.co.uk

tzok
Posts: 21
Joined: Sat Dec 30, 2017 2:27 pm

Re: no-software internal RTC

Post by tzok » Mon Jul 16, 2018 6:52 pm

I've done some research. Keyboard communicates with ST using a simple async serial protocol with baud rate of 7812 bps. Single bytes are being sent one by one with a pause of 4.5ms between each. Setting a clock is done by sending 0x1B followed by YY MM DD hh mm ss. Date is sent as hex, so for month January is 0x01, and December is 0x12, for day 01 is 0x01, and 31 i 0x31, same is for time. Only for year 1999 is 0x99, and 2018 is 0xB8. For unknown reason OMIKRON.Basic (DATE$) sends 0xC8 when setting 18.

After setting a date it is read by issuing a 0x1C byte. Same 0x1C request can be seen sent to KB after power on or reboot.

Date sequence is transmitted in one byte-stream starting with 0xFC (delay between request and response is about 1 ms. Unfortunately when set year was A0 (2000) or higher response is always 0x00, which reads as 2028 (or 1928?). So there is no chance to just set the IKBD clock after power on (and optionally reset). The communication has to be intercepted and response substituted.

Encoding of read stream is same as above. So we got:
ST TX: 0x1B 0xB8 0x07 0x16 0x19 0x47 0x00 0x1C -> set IKBD clock to 16.07.2018 19:47:00 and read it back
KB TX: 0xFC 0x00 0x07 0x16 0x19 0x47 0x00 -> clock is 16.07.28 19:47:00

So now I'm planning to try to add some MCU in-between KB_TX and ST_RX, which would also listen to ST_TX, and retransmit everything from KB_TX to ST_RX, until it captures 0x1C on ST_TX. If such happens, it would mask the response KB_TX transmission with prepared on its own, from its own RTC. It could also set the RTC, by intercepting the 0x1B sequence header.

User avatar
exxos
Site Admin
Posts: 2887
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: no-software internal RTC

Post by exxos » Mon Jul 16, 2018 6:56 pm

:bravo:

Have you talked to Jookie about this stuff ? He did a keyboard injector for cosmosex and may be able to give some more info on it all.
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.

tzok
Posts: 21
Joined: Sat Dec 30, 2017 2:27 pm

Re: no-software internal RTC

Post by tzok » Mon Jul 16, 2018 7:39 pm

I haven't talked with Jookie, but for now, I think I know everything I need to know. The only unknown is how will TOS react on a year value of 0xB8, which fits the scheme but the real IKBD would never return it.

User avatar
rubber_jonnie
Posts: 435
Joined: Thu Aug 17, 2017 7:40 pm
Location: Essex
Contact:

Re: no-software internal RTC

Post by rubber_jonnie » Tue Jul 17, 2018 8:21 am

Since I last responded on this thread I've become the proud owner of an IKBD clock board. It needs a bit of a clean up, but it would probably be a fun project for me to reverse engineer and document. I might even be able to make it a bit smaller than it currently is, which is about 1.5x the length of the IKBD chip, and about twice as wide.

There's a pic of it below (Not a great one) and it's condition is unknown, and as you can see from the pic, the battery holder has detached itself, but nothing I can't fix given a bit of time I think.
IKBD_Clock.JPG
IKBD_Clock.JPG (222.27 KiB) Viewed 195 times
Collector of old Atari things:
800XL + Ape Warp mod, 2x 1010 cassette, 1050 + Happy mod, 65XE (128k) & XC12, SIO2SD, 2600jr, 7800 and Lynx II
Atari 520ST (1Meg) + Gotek, 1040STFM + Vortex ATOnce + Gotek, 1040STF long button floppy, 4160 STE with Gotek and ROM switcher, 4160STE with 32Mhz booster, ROM switcher and CosmosEx, not to mention various bare ST boards for testing including a PAK 68/2 :)
Plus the rest..
Amiga stuff, Mac stuff, Sinclair stuff etc...
www.electronicnothingness.co.uk

Petari
Posts: 453
Joined: Tue Nov 28, 2017 1:32 pm

Re: no-software internal RTC

Post by Petari » Tue Jul 17, 2018 8:43 am

tzok wrote:
Mon Jul 16, 2018 6:52 pm
I've done some research. Keyboard communicates with ST using a simple async serial protocol with baud rate of 7812 bps. Single bytes are being sent one by one with a pause of 4.5ms between each. Setting a clock is done by sending 0x1B followed by YY MM DD hh mm ss. Date is sent as hex, so for month January is 0x01, and December is 0x12, for day 01 is 0x01, and 31 i 0x31, same is for time. Only for year 1999 is 0x99, and 2018 is 0xB8. For unknown reason OMIKRON.Basic (DATE$) sends 0xC8 when setting 18.

After setting a date it is read by issuing a 0x1C byte. Same 0x1C request can be seen sent to KB after power on or reboot.

Date sequence is transmitted in one byte-stream starting with 0xFC (delay between request and response is about 1 ms. Unfortunately when set year was A0 (2000) or higher response is always 0x00, which reads as 2028 (or 1928?). So there is no chance to just set the IKBD clock after power on (and optionally reset). The communication has to be intercepted and response substituted.

Encoding of read stream is same as above. So we got:
ST TX: 0x1B 0xB8 0x07 0x16 0x19 0x47 0x00 0x1C -> set IKBD clock to 16.07.2018 19:47:00 and read it back
KB TX: 0xFC 0x00 0x07 0x16 0x19 0x47 0x00 -> clock is 16.07.28 19:47:00

So now I'm planning to try to add some MCU in-between KB_TX and ST_RX, which would also listen to ST_TX, and retransmit everything from KB_TX to ST_RX, until it captures 0x1C on ST_TX. If such happens, it would mask the response KB_TX transmission with prepared on its own, from its own RTC. It could also set the RTC, by intercepting the 0x1B sequence header.
Well, I think that much better and simpler solution is to change code in TOS. If it is really necessary. I think that only displaying is what is not Y2K compliant.
And I think that there are problems in your calculations. Value 0 for year means 1980 - documented. So 1999 is 19, 2000 is 20 ($14), not something like $A0.
There are 5 bits for date, 4 bits for month and 7 bits for year. Same as in TOS header. Let see how today date would look in IKBD chip:
day: 17 = 10001 , month = 0111 , year = 2018-1980 = 38 = 0100110 . All together: 0100110011110001 . Hex: $4CF1 .
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

Post Reply