DSR Help

[Shift838]

I'm working on a new card and I want to implement a Real Time Clock that would be compatible with the below RTC's.  This would be for on the clock functions, no printer buffers or anyting.

 

• CorComp Triple-Tech
• Fred Kaal's IDE Date/Time clock calls, set, etc
• Maybe MBX Clock as well.

 

I have been reading the DSR Specifications for the TI-99 and since I have never done this before I think I may need some tutoring.

 

I know Fred put's his DSR's on a SRAM but when the battery goes out you need to reload, not a big deal, but that would mean I would have to work out a program to write DSR to the SRAM as well.  I was thinking of putting it on a EPROM.

 

Any takers to help me out?

 

Edited December 5, 2023 by Shift838

[+FarmerPotato]

If you have SRAM in the DSR, your program only has  to enable the card then copy it to >4000.  I can imagine a bit to enable writing else protect.

If you want to write to Flash in-system, it's a 6-byte command stream to unlock it.   The catch is: you have to maintain CE during the bytes.  I think you can just tie CE low and gate your chip enable to OE. 

[apersson850]

I made a real time clock back in the days when there was none commercially available. But I was mainly interested in reading it from Pascal programs, so the DSR I actually did was to allow interrupt handling on the clock. I wrote a DSR which could display the clock on the screen all the time when the p-system was running. Access to the clock itself was by a unit I included i the *SYSTEM.LIBRARY in the p-system, so that didn't require any DSR at all.

I have the DSR in SRAM too, so it must be loaded again when necessary.

[+FALCOR4]

8 hours ago, FarmerPotato said:

If you have SRAM in the DSR, your program only has  to enable the card then copy it to >4000.  I can imagine a bit to enable writing else protect.

If you want to write to Flash in-system, it's a 6-byte command stream to unlock it.   The catch is: you have to maintain CE during the bytes.  I think you can just tie CE low and gate your chip enable to OE. 

If using SRAM that has the possibility of being corrupted (ex: low battery voltage) then don't forget a switch to disable the DSR space or you may risk a constant cycle of lockups upon powerup.

[speccery]

I don't think this is what you're looking for, but anyway, for what it's worth: I've been contemplating with the idea of making a simple FlashGROM type cartridge, with only a microcontroller implementing GROM capability and a separate regular SRAM chip connected to the cartridge port (probably also with latch to support paging of SRAM if larger than 8K, and a little glue logic to choose whether writes from TMS9900 go to SRAM or the address latch). I've advanced my grommy2 project lately, and this idea of MCU+SRAM came to mind. Looking at documentation on TI Tech Pages, it appears that GROMs can contain power up routines. Such a routine could copy initialisation data from GROM space to SRAM, making the SRAM work like ROM. Although I've been thinking about this idea in the context of a very simple cartridge, there's nothings stopping using the same idea to init a DSR RAM from GROM. A single GPL instruction MOVE >1000,G@>8000,@>4000 would copy 4K of code from GROM address >8000 to the DSR RAM (provided the DSR memory was enabled with the right CRU settings).

[Shift838]

I should clarify, this is not a cartridge board but an expansion board for the PEB.

[Gary from OPA]

17 hours ago, Shift838 said:

 

Any takers to help me out?

 

if you have questions, or need help, let me know, i am more then willing to walk you thru some of tough parts if you get stuck.