+FarmerPotato Posted October 8, 2020 Share Posted October 8, 2020 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 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? 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? Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted October 8, 2020 Share Posted October 8, 2020 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. Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted October 8, 2020 Author Share Posted October 8, 2020 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! Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted October 8, 2020 Author Share Posted October 8, 2020 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! Quote Link to comment Share on other sites More sharing options...
GDMike Posted October 8, 2020 Share Posted October 8, 2020 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.. Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted October 8, 2020 Author Share Posted October 8, 2020 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? 1 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted October 8, 2020 Author Share Posted October 8, 2020 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. Quote Link to comment Share on other sites More sharing options...
pnr Posted October 8, 2020 Share Posted October 8, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted October 8, 2020 Share Posted October 8, 2020 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. Quote Link to comment Share on other sites More sharing options...
GDMike Posted October 8, 2020 Share Posted October 8, 2020 (edited) 1 hour ago, FarmerPotato said: The 58274? did you have a good source? 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. Edited October 8, 2020 by GDMike Quote Link to comment Share on other sites More sharing options...
GDMike Posted October 8, 2020 Share Posted October 8, 2020 Ahh .16 pin dip. Vs 24 here's 16 pinout https://h5.aliexpress.com/item/32994744927.html Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted October 8, 2020 Share Posted October 8, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted October 8, 2020 Share Posted October 8, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted November 9, 2020 Author Share Posted November 9, 2020 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! 1 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted November 9, 2020 Share Posted November 9, 2020 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? 1 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted November 9, 2020 Author Share Posted November 9, 2020 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.) 1 Quote Link to comment Share on other sites More sharing options...
+dhe Posted November 9, 2020 Share Posted November 9, 2020 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. 2 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted November 10, 2020 Author Share Posted November 10, 2020 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 Quote Link to comment Share on other sites More sharing options...
+9640News Posted November 10, 2020 Share Posted November 10, 2020 No, I don't know the answer myself. Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted November 10, 2020 Author Share Posted November 10, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
+9640News Posted November 10, 2020 Share Posted November 10, 2020 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 3 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted November 10, 2020 Share Posted November 10, 2020 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? Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted November 10, 2020 Author Share Posted November 10, 2020 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 1 Quote Link to comment Share on other sites More sharing options...
+9640News Posted November 10, 2020 Share Posted November 10, 2020 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 2 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted November 10, 2020 Share Posted November 10, 2020 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.