Using the TMS9901 as a timer

[+retroclouds]

Are there any details available on how to use the TMS9901 event timer.

 

In the game loop I used for Pitfall, I'm using the VDP for timing events. Ofcourse that kinda limits the interval to 50/60 times a second.

For some stuff that's surely not enough.

 

So if you need a high-resolution timer, would the TMS9901 be an option there? Are there any programs that use the TMS9901 as a timer?

[Stuart]

There are details on using the 9901 internal timer on Thiery's site (currently offline - you'll have to download a zip from one of the other threads).

[jens-eike]

Now we really need Thierry's site...

The problem I could imagine is the console interrupt routine. When the 9901 timer issues an interrupt, the console checks for VDP and cassette interrupt, then DSR interrupts (where an error in the RS232 card prevents further service), and when nothing is found, your interrupt routine gets it's turn. This way, you will lose a lot of time...

[sometimes99er]

I used Thierry Nouspikel's descriptions (believe it was 2 pages) to display minutes and seconds (working independently of NTSC/PAL version) in my early 2006 Sudoku wannabe game mockup. Tursi was quick to add specific 9901 support. Late 2007 saw me working on another Sudoku without timer for a much more slick implementation. A certain amount of randomly generated puzzles were rated, so a relatively big game possible with increasing difficulty with each puzzle occupying only two bytes - the seed for the random number generator. The generator however depended on a specific (the common) version of the console ROM, which I later decided to avoid. My new random number generators for games (and more) is however relatively untested (works fine for a few tasks).

[+retroclouds]

Now we really need Thierry's site...

The problem I could imagine is the console interrupt routine. When the 9901 timer issues an interrupt, the console checks for VDP and cassette interrupt, then DSR interrupts (where an error in the RS232 card prevents further service), and when nothing is found, your interrupt routine gets it's turn. This way, you will lose a lot of time...

Guess that kinda ruins it. It would require you to setup scratchpad memory in such way that the console ISR is in a runnable state (registers, etc. properly setup)

Edited December 14, 2014 by retroclouds

[Omega-TI]

In THIS MESSAGE from Tursi there is a real nice clock routine (tsr) that you might be abe to use. Sans an RTC his routine is the only way to go.

[sometimes99er]

Guess that kinda ruins it. It would require you to setup scratchpad memory in such way that the console ISR is in a runnable state (registers, etc. properly setup)

Well, some months ago I think tests showed it was down to "only" a few dozens of bytes being "corrupted" by the ISR. I decided to almost single-step through the Intern to be sure. As always, days later I was distracted by other ideas.

[Tursi]

I used Thierry Nouspikel's descriptions (believe it was 2 pages) to display minutes and seconds (working independently of NTSC/PAL version) in my early 2006 Sudoku wannabe game mockup. Tursi was quick to add specific 9901 support.

It was thanks to your straight-forward and clear code that I finally understood how that timer mode actually worked!

[+Vorticon]

I used Thierry Nouspikel's descriptions (believe it was 2 pages) to display minutes and seconds (working independently of NTSC/PAL version) in my early 2006 Sudoku wannabe game mockup. Tursi was quick to add specific 9901 support. Late 2007 saw me working on another Sudoku without timer for a much more slick implementation. A certain amount of randomly generated puzzles were rated, so a relatively big game possible with increasing difficulty with each puzzle occupying only two bytes - the seed for the random number generator. The generator however depended on a specific (the common) version of the console ROM, which I later decided to avoid. My new random number generators for games (and more) is however relatively untested (works fine for a few tasks).

 

Can you please post that Sudoku game of yours? I don't recall ever seeing it.

[sometimes99er]

Can you please post that Sudoku game of yours? I don't recall ever seeing it.

They were never in a playable state. I did revisit the last one a few times. Mostly worked on different aspects of the backbone and features. Here's some pictures from the prototypes.

 

 

[+Vorticon]

Ah yes, I remember seeing the demos. Maybe some day they'll get finished because they look amazing!

[apersson850]

I've used the TMS 9901 timer in assembly programs, but that's because I can switch in RAM instead of the console ROM. Thus I can load my own interrupt vectors, with the pointers I prefer. Once you can do that, it's simple.

[+retroclouds]

I've used the TMS 9901 timer in assembly programs, but that's because I can switch in RAM instead of the console ROM. Thus I can load my own interrupt vectors, with the pointers I prefer. Once you can do that, it's simple.

 

So do I understand correctly that you swapped the ROM's in the TI-99/4A console and replaced it with a "hacked" monitor OS stored in RAM ?

[Willsy]

I think he's shadowed the ROMs with RAM so that he can switch the ROMs out of memory and RAM appears there instead. As he says this is cool because you can access a lot of vectors that are normally located in ROM.

Edited December 28, 2014 by Willsy

[apersson850]

Willsy is right. I can use CRU bits to overlay the ROMs with RAM, as I like. I can actually swap in RAM everywhere, so that I get a contiguous 64 Kbyte RAM space, if I want to.

[TheMole]

Willsy is right. I can use CRU bits to overlay the ROMs with RAM, as I like. I can actually swap in RAM everywhere, so that I get a contiguous 64 Kbyte RAM space, if I want to.

 

This is a console modification, right? Not a pbox card?

[apersson850]

Yes, my own design of how to shadow all memory addresses with RAM on a 16-bit wide bus.

[+OLD CS1]

It would have to be internal to catch the decodes for the 8k memory divisions (>0000, >2000, >4000, etc.) at the decoder and suppress the enables for the ROMs et al. then suppress the wait-states. Best of all the RAM could be 16-bit. Sounds like a fun hack

[apersson850]

Yes, it's internal. I've described it before in this forum.

 

64 Kbyte RAM covering all addresses. Bank switchable by CRU bits in 8K chunks. Normally active where 32 Kbyte RAM expansion should reside, inactive where ROM or ports should be. Disabling addresses in 32 Kbyte RAM expansion area will let the normal 32 Kbyte RAM expansion in the box be accessed.

No write-through (writing to ROM doesn't go through to disabled RAM), since there are several memory-mapped addresses in the 99/4A. Otherwise write-through makes it easy to copy shadowed ROM, since you can read the ROM address and then write back to the same, and get a copy of the bytes in the shadowing RAM. But that would require special handling for different areas, so I didn't do that.

Wait-states are removed where not needed, so 32 Kbyte RAM expansion runs at full speed in my memory. By a dedicated CRU bit, VDP access can be decoded by hardware and the necessary wait be inserted, so even code addressing VDP without the NOP recommended by TI will execute correctly.