PhilC wrote: 26 Jul 2019 17:55 Never had one until today. I can always try one of your v1 5 boosters on it?
REMINDER - Stay logged in for at least 2 hours a week to get whitelisted.
Also it helps build a picture where our "good traffic" is coming from for detection scripts.
:o)
Also it helps build a picture where our "good traffic" is coming from for detection scripts.
:o)
Flashy Clock - Yet another DEV board
-
PhilC
- Moderator

- Posts: 7468
- Joined: 23 Mar 2018 20:22
Re: Flashy Clock - Yet another DEV board
If it ain't broke, test it to Destruction.
-
exxos
- Site Admin

- Posts: 28476
- Joined: 16 Aug 2017 23:19
- Location: UK
Re: Flashy Clock - Yet another DEV board
I think I tried it in the V2.2.. was probably last year when Peter was working on the TOS104 mods for the 010.. So probably mentioned on the forum at some point.PhilC wrote: 26 Jul 2019 17:55 Never had one until today. I can always try one of your c1 5 boosters on it?
-
PhilC
- Moderator

- Posts: 7468
- Joined: 23 Mar 2018 20:22
Re: Flashy Clock - Yet another DEV board
12mhz seems to be the fastest I can find in DIL64 and 20mhz in PGA.
If it ain't broke, test it to Destruction.
-
PaulJ
- Posts: 1568
- Joined: 08 Apr 2018 01:14
- Location: USA
Re: Flashy Clock - Yet another DEV board
I've been working on a C app to deal with clock functionality that at this point parrots Exxos's stos app clock selections. Been some what of a pain in the arse. I'm on my 3rd C development system. Tried Lattice which I had been using but getting into supervisor mode had issues and the debugger was nothing to brag about. Went to MWC which used to be my goto C development system but it also had issues. So just out of desperation I gave Pure-C a try and it works much better for me that the other two and the debugger is pretty good.
The clock chip DS12885S and its data sheet are some what unfriendly. Two eight bit registers aligned on word boundaries. You write the first register with register number you want to access and then write or read it from the second address. When you read the data sheet they don't discuss the two registers and basically go on as if all registers are all memory mapped. At first I set up the second register to access register 10 that contained UIP bit which tells you when the chip is not in a update cycle or won't be for another 250 USEC's so you can inhibit updates when you make changes. I ASSUMED since there was no description that once you selected the 2nd register via the first that it would remain selected until you changed it. WRONG.. It appears there is a hardware cycle where you must write the register you want and access the second register. Thats it. If you attempt to deviate the chip locks up and the lockup survives a repower or reset. Had to take the battery out and wait to clear the hang. I can now reliably access the chip and were getting along fine.
Just when things were going good the lights on the Eiffel remain on and its dead to the world!!. Had to pull the one of the remake board. This is the second time the pic has croaked. I believe there's a design issue or this one board has some sorta gremlin. Guess I have to take some time and burn a new pic.
So I'm finally to the point where I can move forward. Now that I can reliably read and write the registers it just a matter of manipulating the bits. So we are making progress.
The clock chip DS12885S and its data sheet are some what unfriendly. Two eight bit registers aligned on word boundaries. You write the first register with register number you want to access and then write or read it from the second address. When you read the data sheet they don't discuss the two registers and basically go on as if all registers are all memory mapped. At first I set up the second register to access register 10 that contained UIP bit which tells you when the chip is not in a update cycle or won't be for another 250 USEC's so you can inhibit updates when you make changes. I ASSUMED since there was no description that once you selected the 2nd register via the first that it would remain selected until you changed it. WRONG.. It appears there is a hardware cycle where you must write the register you want and access the second register. Thats it. If you attempt to deviate the chip locks up and the lockup survives a repower or reset. Had to take the battery out and wait to clear the hang. I can now reliably access the chip and were getting along fine.
Just when things were going good the lights on the Eiffel remain on and its dead to the world!!. Had to pull the one of the remake board. This is the second time the pic has croaked. I believe there's a design issue or this one board has some sorta gremlin. Guess I have to take some time and burn a new pic.
So I'm finally to the point where I can move forward. Now that I can reliably read and write the registers it just a matter of manipulating the bits. So we are making progress.
-
exxos
- Site Admin

- Posts: 28476
- Joined: 16 Aug 2017 23:19
- Location: UK
Re: Flashy Clock - Yet another DEV board
Yeah you have to set the address each time. I noted that on the forum or in the code somewhere.. I thought you could just set a address and just read from it all the time but it screws up.
Reading and writing to the chip is a bit confusing because of its multiplexed bus. Its annoying as you just can't set the address with the CPU and read it like normal. I considered ditching the chip because of that originally .
Not sure why you need supervisor mode though ? Just normal deek and doke to the rtc address is all that's needed. I'm using hisoft basic BTW not stos ... But peek becomes speek for supervisor peek, I don't think I use it anywhere in that code. I think in had to use it a couple of times in GB6 though somewhere.
In any case, you should be almost able to copy my code right over to asm. It doesn't really do much other than variables and peek and poke type stuff. Granted its not programmed in the best of ways, but it gets the job done at least.
Reading and writing to the chip is a bit confusing because of its multiplexed bus. Its annoying as you just can't set the address with the CPU and read it like normal. I considered ditching the chip because of that originally .
Not sure why you need supervisor mode though ? Just normal deek and doke to the rtc address is all that's needed. I'm using hisoft basic BTW not stos ... But peek becomes speek for supervisor peek, I don't think I use it anywhere in that code. I think in had to use it a couple of times in GB6 though somewhere.
In any case, you should be almost able to copy my code right over to asm. It doesn't really do much other than variables and peek and poke type stuff. Granted its not programmed in the best of ways, but it gets the job done at least.
-
exxos
- Site Admin

- Posts: 28476
- Joined: 16 Aug 2017 23:19
- Location: UK
-
PaulJ
- Posts: 1568
- Joined: 08 Apr 2018 01:14
- Location: USA
Re: Flashy Clock - Yet another DEV board
Interesting read... I have to say I have encountered a lot of the same issues. Its been my experience over the years that the data sheets in general suck. If there's a short coming it the device, designers tend to gloss over those parts in the data sheet. A lot of the chip designers are satisfied when the device does what they intended no matter how ugly it is to use the chip.
I spent some time looking at your basic program and have gleened a lot on how you have accessed the chip. Pretty painful in basic it appears where using C lends itself to a memory mapped env. It looks like you had to jump through some hoops even using strings for a lot of the situations. Really have never used basic or stos so I assumed it was a stos app since you speak highly of it.
I spent some time looking at your basic program and have gleened a lot on how you have accessed the chip. Pretty painful in basic it appears where using C lends itself to a memory mapped env. It looks like you had to jump through some hoops even using strings for a lot of the situations. Really have never used basic or stos so I assumed it was a stos app since you speak highly of it.
-
exxos
- Site Admin

- Posts: 28476
- Joined: 16 Aug 2017 23:19
- Location: UK
Re: Flashy Clock - Yet another DEV board
Yes your right, datasheets do generally suck. In my more PIC and amp days, there would be millions of pages of all specs, other than what voltage the thing is supposed to run on. Really is amazing omissions and typos in those things.PaulJ wrote: 28 Jul 2019 16:50 Interesting read... I have to say I have encountered a lot of the same issues. Its been my experience over the years that the data sheets in general suck. If there's a short coming it the device, designers tend to gloss over those parts in the data sheet. A lot of the chip designers are satisfied when the device does what they intended no matter how ugly it is to use the chip.
I did do some stuff in STOS.. but later went for hisoft basic to get more a "gem app". STOS had really nice bit functions to change a bit easily in a variable.. hisoft had nothing. I had to bodge up my own routines to do it. Converting to a string to use MID$ to swap bits was the quickest way I could think of doing it.. but then I had to convert it back to a number again.. So it got pretty messy very quick. I would assume there would be better bit manipulations in assembly ?PaulJ wrote: 28 Jul 2019 16:50 I spent some time looking at your basic program and have gleened a lot on how you have accessed the chip. Pretty painful in basic it appears where using C lends itself to a memory mapped env. It looks like you had to jump through some hoops even using strings for a lot of the situations. Really have never used basic or stos so I assumed it was a stos app since you speak highly of it.
-
PaulJ
- Posts: 1568
- Joined: 08 Apr 2018 01:14
- Location: USA
Re: Flashy Clock - Yet another DEV board
When I worked at Motorola we were going to use a star core for our Set Top Box until the data sheet and irata arrived. Thing was the size of a NYC phone book mostly consisting of issues. Nothing a software engineer and 20 years of time couldn't work around.exxos wrote: 28 Jul 2019 16:56 Yes your right, datasheets do generally suck. In my more PIC and amp days, there would be millions of pages of all specs, other than what voltage the thing is supposed to run on. Really is amazing omissions and typos in those things.
No matter what tool one uses there is always something another tool is better at. Still believe when God sits down to create an app he uses C and VI!! :) :) :)PaulJ wrote: 28 Jul 2019 16:50 I did do some stuff in STOS.. but later went for hisoft basic to get more a "gem app". STOS had really nice bit functions to change a bit easily in a variable.. hisoft had nothing. I had to bodge up my own routines to do it. Converting to a string to use MID$ to swap bits was the quickest way I could think of doing it.. but then I had to convert it back to a number again.. So it got pretty messy very quick. I would assume there would be better bit manipulations in assembly ?
-
Icky
- Site Admin

- Posts: 4381
- Joined: 03 Sep 2017 10:57
- Location: UK
Re: Flashy Clock - Yet another DEV board
Received some of these in the post today
Looking nice and tiny over the CPU socket
On top of the previous board for comparison
Looking nice and tiny over the CPU socket
On top of the previous board for comparison
You do not have the required permissions to view the files attached to this post.
Who is online
Users browsing this forum: ClaudeBot and 3 guests