Jump to content
FarmerPotato

Geneve Clock Chip MM58274 source?

Recommended Posts

I'm looking for a source of clock chip MM58274. It was used in the Geneve 9640.   It has 4-bit registers, mapped with 4 address bits.

 

Here is the thread I found with some history:  

 

 

 

I looked for MM58274 on aliexpress, and it goes for $7. I looked at several sellers that use the same photo and price.

 

$7

image.png.2b54512babc7a49552af7783925f599b.png

 

I found this for $1 that is possibly fake. It doesn't have the Microchip logo, but has a sane date code. It could be a remark (laser on new markings because old ones are faded), a fake remark (dummy chip, usually with impossible date code), or else Microchip used another fab in '95.

 

$1 for real?

image.png.9ee52735733d1b51fb5ea0bbfc7e85d7.png

 

 

Mine in the Geneve 9640 has the logo and '87 date code.

 

Any opinions on whether that is real or fake? I can try one sample for $6 shipped, might be worth a try.

eBay is a mixed bag but there are a lot of photos there. One from '99 has the Microchip logo.

 

Or another source?

 

Share this post


Link to post
Share on other sites

I found an Intersil chip that is listed as a suitable substitute. My usual sources don't have any MM58274s in stock.

cdp68hc68t1e.pdf

 

Note: this chip is a functional equivalent, not a drop-in replacement.

Share this post


Link to post
Share on other sites
44 minutes ago, Ksarul said:

I found an Intersil chip that is listed as a suitable substitute. My usual sources don't have any MM58274s in stock.

cdp68hc68t1e.pdf 141.84 kB · 1 download

 

Note: this chip is a functional equivalent, not a drop-in replacement.

 

 

Octopart shows a bunch of those 

but mostly for $6-$12, except one Harris brand copy is at Rochester for $0.86

 


Hmm, SPI is sorta ok. It means I have to memory-map it through the FPGA. Maybe have the FPGA shadow it continuously every 0.05s.
But with that technique, I could use any $1 SPI chip and make it look compatible.

 

MC68HC68T1 is another that is similarly costly.
 

I might go for some legit-looking eBay 58274 chips and test them.

 

Thanks for locating that alternative!

 

Share this post


Link to post
Share on other sites

Hey, here is a copy of an Application Note for the 58274 under a friendly document name!

 

https://cdn.preterhuman.net/texts/computing/msx/Geneve_Clock_App_Notes_AN-365.pdf

 

There's a nice personal collection of documents there. Probably all in wht already but...

Holy crap, it's a mixture of TI-99/4A documents and MSX, including service manuals for the CX5M.

I am having a feast... Thanks, clock chip!

 

Share this post


Link to post
Share on other sites

I'm pissed. I had a few from last year when I found some and now I'm not sure where they are. I'll keep looking..

Share this post


Link to post
Share on other sites
18 minutes ago, GDMike said:

I'm pissed. I had a few from last year when I found some and now I'm not sure where they are. I'll keep looking..

The 58274? did you have a good source?

 

 

  • Like 1

Share this post


Link to post
Share on other sites

eBay suggested a Seiko/Epson 72423.

 

It looks similar: 16 registers, BCD, but the registers are in different addresses. No tenths of seconds. Not quite compatible.
These are still stocked by Mouser, for $8, but old ones are out there.

 

Modern Seiko-Epson RTCs are all I2C or SPI with the exception of:

 

RTC7301DG.  The RTC7301SF comes with a temperature sensor! Still around $7.

 

https://www5.epsondevice.com/en/products/rtc/rtc7301sf.html

 

Registers match 72423, ie offset from where MDOS looks.

Not cheap either. Except 72421 used.
 

 

Share this post


Link to post
Share on other sites

By coincidence I was looking a RTC chips a few weeks ago. Looking at some old boards, I arrived at the MM58174 as a chip that was period correct and has direct links to very first RTC chips to appear on the market in the 1970's (the OKI M5832).

For an 8 bit variant have a look at the MM58167.


A third choice could be an early serial chip, the NEC uPD4990. This can maybe be coerced to act like a CRU interface chip.

 

I think all are still available on eBay, but I have no direct buying experiences for any of the above.

 

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, FarmerPotato said:

The 58274? did you have a good source?

 

 

I'll go back over my order form and try to locate where I got them.

Share this post


Link to post
Share on other sites
3 hours ago, FarmerPotato said:

 

https://cdn.preterhuman.net/texts/computing/msx/Geneve_Clock_App_Notes_AN-365.pdf

 

There's a nice personal collection of documents there. Probably all in wht already but...

Holy crap, it's a mixture of TI-99/4A documents and MSX, including service manuals for the CX5M.

I am having a feast... Thanks, clock chip!

 

I wonder where this mishmash came from.  I see files in there that I put together for distribution, such as the HFDC schematics, that are not in their associated ZIP file.  I also see at least one file of mine that I do not recall ever releasing, although I suppose it could have been scraped from an email.  Interesting.

  • Like 1

Share this post


Link to post
Share on other sites

If you could use it let me know, I also have like, 200 ea 32768 crystals..lol also new.

I can throw it all in an envelope out to ya.

 

 

  • Like 1

Share this post


Link to post
Share on other sites
On 10/8/2020 at 4:49 PM, GDMike said:

Oh..I just found out they were MM58167AN

5 for$25 from here.

https://www.ebay.com/usr/myparts1111

 

I found my 5. They are 58167. Not sure the difference.

 

 

I learned a lot from reading about those. They are different though.

 

Here's what I learned:

 


The MM58167 has several interesting features that the '274 does not. However, it's not register-compatible AND it has no years (why?)

 

The BQ4802 isn't register compatible, but has some good features. It's great in the IDE card!

 

I made this comparison of the 3 chips:

 

Features

                     274C      167      BQ4802
                    =====     =====     ======
'274 Compatible      Yes       No        No
Registers            16x4     32x8       16x8
Resolution (s)       0.1      0.001      1
Years               0-99       No       0-9999
Leap Day             Yes       No        ?
Periodic Interrupt  0.1-60s   0.1-1M    31us+
Alarm                No        Yes       Yes
Wake-on Alarm        No        Yes       Yes
Reset Output         No        No        Yes
Watchdog             No        No        Yes
NVRAM                No       Yes      External
Packages            DIP16     DIP24     SOIC28
                    PCC20     PCC28    
Availability       NOS $7    NOS $5     TI new $15, 3.3V is $6

Register Correspondence to '274: 274 has 4-bit regs, 167/4802 have 8-bit regs

D0=LSBit D7=MSBit

274                167               BQ4802
===                ===               ======
00     control     complicated       0E complicated
00-D3  rollover    14  D0 (LSBit)    n/a (set lock bit before reading)
01     tenths      01  D7:4          n/a
02-03  seconds     02  D6:4, D3:0    00 D6:4, D3:0
04-05  minutes     03  D6:4, D3:0    02 D6:4, D3:0
06-07  hours       04  D5:4, D3:0    04 D5:4, D3:0
08-09  days        06  D5:4, D3:0    06 D5:4, D3:0
0A-0B  months      07    D4, D3:0    09   D4, D3:0
0C-0D  years       n/a               0A D7:4, D3:0
0E     weekday     05  D2:0          08   D4, D3:0         
0F     setting
                                     0F D7:4, D3:0 century

Considering that, I have to go with the MM58274 for MDOS compatibility, with an option to add-on the '167 for wake-on-alarm.

 

I really like the prospect of a wake-on-alarm, to start up the computer.  The 9901 already has an adequate periodic interrupt.  


It would be wasteful to include both chips, but, the '167 add-on could function just as an alarm or millisecond
timer.   An alarm-set or timer-start subroutine would synchronize the '167 to match official time from '274. Including both chips would be like paying at least $12 for an RTC.

 

Still, the '167 PCB location could be left unpopulated. Though a DIP-24 is pretty big (PCC28 socket is about half).  

 

Summary

 

Geneve 2020 decision:

 

If there were no need for compatibility, I would go with Shift838's module that implements the BQ4802.

 

Unfortunately, MDOS uses direct read/write for everything except "set date/time from string" XOP. An XOP can be patched
in my BIOS, but not direct read/write (esp control bits) without more FPGA magic than it's worth. 

 

As usual, it's been really fun learning about old chips.

 

Further reading

 

Other NatSemi chips:

 

http://bitsavers.trailing-edge.com/components/national/_dataBooks/1993_Real_Time_Clock_Handbook.pdf

 

Has application notes for '274 and '167
DS8573 is a lot like the '167, but maybe compatible to PC/XT.
NS32FX211 is new for 1993, seems compatible with '174
 

Read about how 32.768MHz is scaled down to 10 Hz!

 

  • Like 1

Share this post


Link to post
Share on other sites

Even with direct reads and writes, since your Geneve 2020 is in FPGA could you not just intercept I/O to the clock chip's address(es) and make use of whatever you want behind the scenes?

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, OLD CS1 said:

Even with direct reads and writes, since your Geneve 2020 is in FPGA could you not just intercept I/O to the clock chip's address(es) and make use of whatever you want behind the scenes?

Well, that's possible, but it's messy. I'm reluctant to make a big ball of glue in the FPGA. I am striving not to use FPGA for anything if I have a real chip. Since memory-mapping is in the Geneve gate array, it seems fair, but I'm actually taking many fixed memory map locations OUT of my FPGA in favor of just putting mode bits onto the bus.

 

It's not the computer that's is in the FPGA--its all original chips wherever possible. It's not an FPGA repro.

 

The only tricky problem with the plain '276 is the fact that 99105 always transfers 16 bits, read or write, while the Geneve's 9995 does single byte transfers. 


(I am rolling my own LS612, and DRAM controller, since the Geneve does that, too.)

 

  • Like 1

Share this post


Link to post
Share on other sites

What is Geneve compatibility?

 

I mean, yes, you want to run MDOS, but, so what if you have you have to make a 200 byte addition to MDOS, to use a much better clock chip?

 

Lou Phillips, had to do that with the Geneve. Everyone wanted a TI compatibility layer + more (primarily a DOS like environment).

 

We are gifted in that MDOS source is freely available, primarily thanks to Beery.

  • Like 2

Share this post


Link to post
Share on other sites

 I'm looking at the MDOS source code and I see some funny stuff going on. First, the memory map should be:

 

F130-F13F Control registers of the MM58274C clock
F130      Status. Bit flag >0800 Data changed
F131      unused by MDOS? Tenths of seconds. READ ONLY
F132      Unit seconds
F133      Tens seconds
F134      Unit minutes
F135      Tens minutes
F136      Unit hours
F137      Tens hours
F138      Units days
F139      Tens days
F13A      Unit months
F13B      Ten month
F13C      Unit years
F13D      Tens years
F13E      unused by MDOS. Day of week
F13F      Clock settings register

Geneve2020 reference wiki:  https://gitlab.com/FarmerPotato/geneve2020/-/wikis/X.-Appendix-Reference-Tables

 

MDOS source from which I derive those addresses:

 

File:HDS2.MDOS.HD.EQUATES   Page: 7 Date: 10-30-04  Time: 01:41:46

* Real Time Clock on the Geneve (in native 9640 mode only)
CNTREG EQU  >F130
UNSEC  EQU  CNTREG+2
TENSEC EQU  UNSEC+1
UNMIN  EQU  TENSEC+1
TENMIN EQU  UNMIN+1
UNHR   EQU  TENMIN+1
TENHR  EQU  UNHR+1
UNDAY  EQU  TENHR+1
TENDAY EQU  UNDAY+1
UNMON  EQU  TENDAY+1
TENMON EQU  UNMON+1
UNYR   EQU  TENMON+1
TENYR  EQU  UNYR+1
CKSTRG EQU  CNTREG+>F    CLOCK SETTING REGISTER

 

 

 

 

I see code in TMTOCM that reads these one byte at a time, tens first, then units.

 


 

File:HDS2.MDOS.HD.TIME   Page: 4 Date: 10-30-04  Time: 01:41:46

TMTOCM LI   R2,>FFFD          flag for which time read
TIM008 INC  R2
       JEQ  TIM010
       LI   R1,COMBUF
       MOV  R1,R8
       LI   R4,6
       MOVB @CNTREG,R3        reset data change flip flop
       LI   R3,UNSEC+1
TIM007 MOVB *R3,*R1+             tens,units,tens,units, etc.
       DEC  R3
       MOVB *R3,*R1+
       AI   R3,3
       DEC  R4
       JNE  TIM007
       MOVB @CNTREG,R3
       SLA  R3,5
       JOC  TIM008            TIME HAS CHANGED
* IT WAS READ, BUT IS IT POSSIBLE?
DT0003 MOVB *R8+,R7           CHECK FOR CHARS LESS THAN OR = TO 9
       ANDI R7,>0F00
       CI   R7,>0900
       JH   DT0002
       CI   R8,COMBUF+12
       JNE  DT0003
TIM010 RT                     R2 IS NOT 0

This DEC, add 3, DEC pattern is used to read addresses in the order TENSEC, UNSEC, TENMIN, UNMIN etc

The memory map goes units, tens, units, tens, but we read tens, units, tens,units--up to 6 pairs, e.g. 20-11-09 17:36:00.

 

If the seconds ticks up during the read, the JOC TIM008 catches that and it tries again.

 

So far, so good.

 

When I compare how MDOS writes the clock registers, I am alarmed by seeing it use different addresses for reads or writes.

Here's the code:

 

File:HDS2.MDOS.HD.TIME   Page: 7 Date: 10-30-04  Time: 01:41:46

SETIT  MOVB @CBHFF,@CNTREG    TEST, STOP CLK, INT SET, INT STOP
       CLR  @CKSTRG           NO INTERRUPTS
       MOVB @CBH05,@CNTREG    NORMAL, STOP CLK, CLK SET, INT STOP
       MOVB @CBH01,@CKSTRG    24 hour mode, leap year
       LI   R3,COMBUF
       LI   R8,UNSEC+2
       LI   R10,6

SETIT is going to write 12 bytes of time digits, from R3, COMBUF. 

 

The loop begins with R8, UNSEC+2, that is F132+2 = F134. Since the first byte in COMBUF is tens seconds, I find it odd to see F134, when TENSEC is F133.

 

LOOPDT MOVB *R3+,*R8          assume cpu ram
       DECT R8
       MOVB *R3+,*R8
CBH28  EQU  $+1
       AI   R8,6              >0228, >0006
       DEC  R10
       JNE  LOOPDT

So the LOOPDT writes a byte to F134, then F132. Then it adds 6 to get F13A.

The result is R8  writes bytes at addresses F100 + 4,2,8,6,12,10,16,14,20,18,24,22

Starting at F134 it then progresses by -2,+6,-2,+6 ...

Except, the corresponding read addresses start at F133 and progress by -1,+3,-1,+3

 

I don't get why this is. Is it a bug in the Geneve gate array? Or intended?

read   write
F132  F132
F133  F134
F134  F136
F135  F138
F136  F13A
F137  F13C
F138  F13E  addresses for Days units, but F13E is also CKSTRG
F139  F140
F13A  F142
F13B  F144
F13C  F146
F13D  F148

This means that regardless of whether your data bus is 8 or 16 bits, in a MOVB to F132, the lower byte would be irrelevant.

A helpful side effect for me.. Also I can't find any documentation that those addresses were reserved.

 

HOWEVER,   back at the top of SETIT, it does a

SETIT  MOVB @CBHFF,@CNTREG    TEST, STOP CLK, INT SET, INT STOP
       CLR  @CKSTRG           NO INTERRUPTS
       MOVB @CBH05,@CNTREG    NORMAL, STOP CLK, CLK SET, INT STOP
       MOVB @CBH01,@CKSTRG    24 hour mode, leap year

CNTREG is >F130
CKSTRG is >F13F

 

The TMS9995 would take this as CLR @>F13E.. which is the above address where it wrote the Days units. Huh?

 

FYI. CKSTRG has two meanings here -

With F in CNTREG, then CKSTRG is the interrupt control register (which we want to clear).

With 5 in CNTREG, then CKSTRG is the clock setting register (which we want to set to 1).

 

Fine. But how does writing to F13F sometimes mean CNTREG and sometimes UNDAYS?

 

Is there still a bug here? Hardware or software?

 

That's where I'm stuck.

@InsaneMultitasker , @BeeryMiller

Do you know the answer to this?

 

 

 

For completeness here is the rest of SETIT

 

* now for leap yr calculation
* if the lsb of the 10 digit is 0, then program the leap yr bits
*      with the 2 lsb's of the  units digit
* if the lsb of the 10 digit is 1, then program the leap yr bits
*      with the [2 lsb's XOR bin (10)] of the units digit
       MOVB @COMBUF+11,R5
       MOVB @COMBUF+10,R4
       SRL  R4,9              test tens digit
       JNC  TIM0DT            use the 2 lsbs
       XOR  @CBH02,R5         change it
TIM0DT SLA  R5,2              now set leap year, start, etc
       ANDI R5,>0C00
       ORI  R5,>0100
       MOVB R5,@CKSTRG        set leap yr
       MOVB @CBH01,@CNTREG    start clock, no ints
       RT

 

Share this post


Link to post
Share on other sites
29 minutes ago, dhe said:

What is Geneve compatibility?

 

I mean, yes, you want to run MDOS, but, so what if you have you have to make a 200 byte addition to MDOS, to use a much better clock chip?

 

Lou Phillips, had to do that with the Geneve. Everyone wanted a TI compatibility layer + more (primarily a DOS like environment).

 

We are gifted in that MDOS source is freely available, primarily thanks to Beery.

 

I understand--but 100% binary compatible is a worthy goal, until it's out of reach. It might turn out to be out of reach...

 

The idea is that you could back up your Geneve 9640 disks, then boot them over on Geneve 2020.  

 

Patching a binary is no picnic. Whenever Tim builds a new one, like the 7.0 beta just now, it breaks all that. 

Compiling from source, it's a similar problem - if I need to make a source patch, I have to re-apply that whenever Tim edits the main branch.

(Of course, there will be no closed source here--anything I do will all be open source.)

 

If I have to patch MDOS, who knows how many applications also break? I think, with so little software for MDOS, I would hate to break something, because I won't have the ability to patch it.  The exception is that I can easily patch any XOP without changing MDOS, because the processor will execute my code first.

 

On clock chips, the BQ4802 has pros and cons.  If I were scuttling the idea of using a real vintage chip, I'd skip the 4802, and go with a much newer chip, and stick in on the FPGA SPI bus.

 

 

  • Like 1

Share this post


Link to post
Share on other sites
23 minutes ago, FarmerPotato said:

 

Patching a binary is no picnic. Whenever Tim builds a new one, like the 7.0 beta just now, it breaks all that. 

Compiling from source, it's a similar problem - if I need to make a source patch, I have to re-apply that whenever Tim edits the main branch.

(Of course, there will be no closed source here--anything I do will all be open source.)

 

 

 

It is not as bad to "re-apply" a patch as you may think.  GenASM has the capability for conditional assembly, sorta like setting a flag for "CLASSIC" or for "Geneve 2020".

 

Beery

  • Like 3

Share this post


Link to post
Share on other sites

Does MDOS/GeneveOS provide the interface to the hardware clock for software (asking as I know nothing about the Geneve OS?)  I would expect an operating system to abstract access to any underlying hardware.  For instance, the "CLOCK" DSR has a standard interface for software to query and set, and the DSR itself manages access to whatever chip is being used.

 

It would seem that if you wanted to use a superior or more readily available chip that changes could be made to GeneveOS to accommodate without sacrificing software compatibility provide the software is well-behaved and only uses the supplied interface.  Why should user software access the clock directly?

Share this post


Link to post
Share on other sites
4 minutes ago, OLD CS1 said:

Does MDOS/GeneveOS provide the interface to the hardware clock for software (asking as I know nothing about the Geneve OS?)  I would expect an operating system to abstract access to any underlying hardware.  For instance, the "CLOCK" DSR has a standard interface for software to query and set, and the DSR itself manages access to whatever chip is being used.

 

It would seem that if you wanted to use a superior or more readily available chip that changes could be made to GeneveOS to accommodate without sacrificing software compatibility provide the software is well-behaved and only uses the supplied interface.  Why should user software access the clock directly?

 

 

From a user program, these are XOP calls you are expected to use. However, there is nothing to stop you using direct access to the clock registers at >F130 to >F14E or whatever they really are.  The XOP don't cover access to features such as interrupts.

 

  
9. General Utility

  Decimal
	0  Validate Time
	1  Read Time
	2  Set Time
	3  Validate Date
	4  Read Date
	5  Set Date
	6  Julian Date
	7  Day of Week

Example

       LI   R0,7
       XOP  @NINE,0
       MOV  R1,@WEEKDA

...
NINE   DATA 9
WEEKDA DATA 0        day of the week 1=Sun 7=Sat

 

  • Like 1

Share this post


Link to post
Share on other sites

At the moment, I do not know of any programs that accesses the Geneve clock directly from the MDOS side of things.  There was one program, CLOCKM, that had an alarm, etc. written and distributed  when the Geneve first came out that still runs on the Geneve.  The source code was never released that I am aware.  If any program did access the clock directly, it would have been that program.

 

Now, once we move to the GPL side of things, I do not know how the Geneve clock is accessed as I have never coded anything to access the clock under the 4A emulation side of things.

 

Bruce Hellstrom wrote a memory viewer, BHDMV, that allows you to watch the memory on the real hardware for the clock registers.  I suspect MAME and the debugger on it as well will allow you to watch the clock registers.

 

Beery

 

  • Like 2

Share this post


Link to post
Share on other sites
12 hours ago, OLD CS1 said:

Does MDOS/GeneveOS provide the interface to the hardware clock for software (asking as I know nothing about the Geneve OS?)  I would expect an operating system to abstract access to any underlying hardware.  For instance, the "CLOCK" DSR has a standard interface for software to query and set, and the DSR itself manages access to whatever chip is being used.

 

It would seem that if you wanted to use a superior or more readily available chip that changes could be made to GeneveOS to accommodate without sacrificing software compatibility provide the software is well-behaved and only uses the supplied interface.  Why should user software access the clock directly?

 

Preventing direct access to hardware is one of the reasons why the privileged mode was invented for processors. This could be done on the TMS99105 since it has such a mode. You cannot restrict the address access, but you could use a CRU bit to guard the clock hardware, and the TMS99105 allows access to CRU addresses 1C00 and higher only in privileged mode.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...