Tutankham for the TI-99/4A

[+retroclouds]

Speaking of music, are you going to include renditions of the arcade music?

 

To be honest, I have no clue about music and sound effects. For Pitfall it wasn't too much of a problem as I basically recycled the colecovision sound effects.

For Tutankham I could do the same, but this time I want to do it differently and give the game an own touch. I will certainly need help as far as music is concerned.

Possibly someone willing to do the sound effects and music.

[matthew180]

The way Tutankham is designed -and from what I understand about the F18A- it should not be too hard to add smooth scrolling,

 

You only need to do the unlock sequence for the F18A, and the scrolling is done via a single VDP register update. You would just need to divide your time between tile-level scrolling by 8 and update the horizontal scroll reg accordingly.

 

Could also use the F18A for doing multicolored enemy sprites.

 

Assemble and run the attached program on and F18A enabled 99/4A. :-)

 

The thing is I'd first need a good solution for emulating 64K (8x8) boards on the TI-99/4A as there isn't emulator support for the F18A yet and don't want to burn EPROMS for each test-cycle.

 

Get a Dallas (Maxim) NV SRAM chip to use instead of the EPROM for testing. They are a little pricey ($13 each I think), but worth it for development work. They are and SRAM with the same pinout as and EPROM, but have a built in battery that lasts 10-years from the last time the device had power applied.

 

http://www.maxim-ic.com/app-notes/index.mvp/id/4006

 

http://www.maxim-ic.com/datasheet/index.mvp/id/2648

 

http://www.mouser.com/ProductDetail/Maxim-Integrated-Products/DS1230AB-120+/?qs=sGAEpiMZZMvaNBfR%2fsmQG1WKblw65Y6Dd2%2f8IXDOp88%3d

 

http://www.digikey.com/product-detail/en/DS1230AB-70%2B/DS1230AB-70%2B-ND/1130311

 

But I only see a 256K-bit and 1024K-bit, no 512K-bit :-(

ecm3_with_sprite.zip

[+arcadeshopper]

You only need to do the unlock sequence for the F18A, and the scrolling is done via a single VDP register update. You would just need to divide your time between tile-level scrolling by 8 and update the horizontal scroll reg accordingly.

 

 

 

Assemble and run the attached program on and F18A enabled 99/4A. :-)

 

 

 

Get a Dallas (Maxim) NV SRAM chip to use instead of the EPROM for testing. They are a little pricey ($13 each I think), but worth it for development work. They are and SRAM with the same pinout as and EPROM, but have a built in battery that lasts 10-years from the last time the device had power applied.

 

http://www.maxim-ic.com/app-notes/index.mvp/id/4006

 

http://www.maxim-ic.com/datasheet/index.mvp/id/2648

 

http://www.mouser.com/ProductDetail/Maxim-Integrated-Products/DS1230AB-120+/?qs=sGAEpiMZZMvaNBfR%2fsmQG1WKblw65Y6Dd2%2f8IXDOp88%3d

 

http://www.digikey.com/product-detail/en/DS1230AB-70%2B/DS1230AB-70%2B-ND/1130311

 

But I only see a 256K-bit and 1024K-bit, no 512K-bit :-(

 

is it programmed like an eeprom?

[+OLD CS1]

I am (patiently) awaiting Tutankham release. And how is your Time Pilot going?

[matthew180]

is it programmed like an eeprom?

Yes. My EPROM programmer actually has the Dallas part number in its database, but it should program just fine as any EPROM of the proper size. It has been a while though, so you might want to check the datasheet to be sure. They are tall though, due to the battery, and will not fit in a cartridge with the top part of the case on.

[Asmusr]

Yes. My EPROM programmer actually has the Dallas part number in its database, but it should program just fine as any EPROM of the proper size. It has been a while though, so you might want to check the datasheet to be sure. They are tall though, due to the battery, and will not fit in a cartridge with the top part of the case on.

 

What would the the advantage be compared to an EEPROM?

[matthew180]

From the data sheet:

 

* 10 years minimum data retention in the absence of external power

* Data is automatically protected during power loss

* Replaces 32k x 8 volatile static RAM, EEPROM or Flash memory

* Unlimited write cycles

* Low-power CMOS

* Read and write access times of 70ns

* Lithium energy source is electrically disconnected to retain freshness until power is applied for the first time

 

Lots of options since these can be written-to during normal system operation. So you could save data between program loads or power cycles, replace the system ROMs, etc. They are faster than EEPROMs too and don't wear out over time.

 

More from the datasheet:

 

"The DS1230 256k Nonvolatile SRAMs are 262,144-bit, fully static, nonvolatile SRAMs organized as 32,768 words by 8 bits. Each NV SRAM has a self-contained lithium energy source and control circuitry which constantly monitors VCC for an out-of-tolerance condition. When such a condition occurs, the lithium energy source is automatically switched on and write protection is unconditionally enabled to prevent data corruption. DIP-package DS1230 devices can be used in place of existing 32k x 8 static RAMs directly conforming to the popular byte wide 28-pin DIP standard. The DIP devices also match the pinout of 28256 EEPROMs, allowing direct substitution while enhancing performance. DS1230 devices in the Low Profile Module package are specifically designed for surface-mount applications. There is no limit on the number of write cycles that can be executed and no additional support circuitry is required for microprocessor interfacing."

 

Now that I think about it, you could turn a 64K multi-cart board into a RAM/ROM board with one of these...

Edited April 4, 2014 by matthew180

[Asmusr]

Wouldn't it write to the RAM when you switch banks, overwriting the cartridge header?

[+Ksarul]

Now that IS a sweet idea, Matthew! You could put a bunch of these on an HRD set up for 32Kc8 chips to make it nonvolatile without having to worry about rechargeable batteries too. . .you'd have to put a switch or a jumper on the write enable for the cart board to use it this way though. That's an easy change. . .and one I could implement this weekend.

Edited April 4, 2014 by Ksarul

[matthew180]

Wouldn't it write to the RAM when you switch banks, overwriting the cartridge header?

Just move your header down a few addresses in memory, i.e. don't use the first 8 memory addresses or so (for up to 4 banks). At least I think that's how it works, I have to review every time I go back to mess with bank switching.

 

Hmm, maybe the first header would have to be at the first address to be recognized by the system, but the other banks could be moved. Also, bank switching ignores the data, so you could just make sure to always write the data that is already at that address and not worry about moving the headers. Finally, I'm not sure if the 64K boards route the write-enable signal to the EPROM socket... That would be a problem, but one that could be fixed with a wire and soldering iron.

[+Ksarul]

I can also do that set of changes to the layout if it isn't there yet, Matthew, this is a very good idea for folks wanting to develop stuff. . .

[Asmusr]

Yes it is a very good idea. And if you bank switch using MOV @>6006,@>6006 or similar it should always work.

[+Lee Stewart]

I agree that this is a fantastic development idea. It was my impression from a cursory glance at the datasheets that these act as EEPROMs, so they would not be overwritten in normal operation and, hence, would work normally for bank-switching with CLR instructions. I thought they would have to be write-enabled (as @Ksarul indicated) to be overwritten with normal memory accesses. The more I think about it, it almost must be this way because, otherwise, any cartridge that allows user programs ( like TurboForth and my upcoming fbForth 2.0) could be trashed by said user program. Of course, that would mean providing the cartridges with these devices—which I am definitely considering (see next).

 

That said, if, in fact, they can be written under normal program control, this would actually provide a way to write programs in a normal RAM way that would obviate the necessity for providing expansion RAM space for cartridge-specific workspace I can't put in scratchpad RAM. I would think, however, that this mode would be a development problem until the emulator authors provide a way to run programs this way. Currently, any memory in the 6000h – 7FFFh range is treated as ROM in the emulators!

 

H-m-m-m...perhaps, we could provide software on disk that would actually load into cartridges of the sort described in my last ¶—if for no other reason than insurance. It would only add $10 – $15 to the cost of a cartridge.

 

...lee

[+Ksarul]

After doing some careful datasheet comparison I found that these aren't a direct replacement for the EPROMs we use, as A14 shifts from pin 27 to pin 1. I was able to quickly modify the layout to incorporate both of the changes this difference required, however, so the problem only increased the complexity of the modification a little bit. To make it an elegant change, I changed JP1 and JP4 to three-way headers so that all necessary signaling changes are accomplished by setting just those two jumpers differently from their normal use position. If one wants to have the WE signal switched, just connect two wires to the appropriate jumper lines on J4, add a third wire to carry +5V and add the switch so you can toggle between WE and +5V. I made sure to place a clearly marked pad near JP4 to grab the +5V from. I didn't want to add it to the header to prevent accidental connections to the +5V during standard operations.

 

This change was done to the V9 board template. I still have to do my final QC checks on it, but all of the necessary trace changes look to be right now.

[marc.hull]

Need a different page switching method for ram.

[+Ksarul]

I think we have that covered, Marc--if the WE* signal to the SRAM is held high (and it will be when the switch disables it, as it will then be providing +5V on WE*), the board should respond the same way as it would with an EPROM. We would need a loader that makes sure its last action before exiting is to verify that the header bits are undamaged though. If you have some additional thoughts, feel free to join in--I'd rather work though the ramifications of any possible gotchas before I finalize the design.

 

We should probably move this discussion to its own thread though. . .as it is an interesting topic in its own right.

[marc.hull]

I think we have that covered, Marc--if the WE* signal to the SRAM is held high (and it will be when the switch disables it, as it will then be providing +5V on WE*), the board should respond the same way as it would with an EPROM. We would need a loader that makes sure its last action before exiting is to verify that the header bits are undamaged though. If you have some additional thoughts, feel free to join in--I'd rather work though the ramifications of any possible gotchas before I finalize the design.

 

We should probably move this discussion to its own thread though. . .as it is an interesting topic in its own right.

Maybe I misunderstood. Is the idea to use the NV RAM as RAM or ROM?

[+Ksarul]

ROM development module, actually, Marc. Use it as RAM to write the test module to the space, write protect it, and run the tests as if it was a normal ROM. It is primarily a modification to speed up 32K cartridge development cycles when using real hardware instead of emulation. It is definitely not for standard use most of the time, as the NVSRAM won't fit in a closed cartridge case without sawing a hole in the top of the case. I suppose it would also work for folks wanting to load existing cartridges up to 32K in size into it and running them as well. . .but that isn't the real reason we're thinking about this.

[Asmusr]

There is also a 128KB version (DS1245Y) and a 512KB version from TI (BQ4015YMA). Would those also work with the board?

[+Ksarul]

Maybe yes, and maybe no, Rasmus. I'll have to check the data sheets to see where all of the address lines go to determine compatibility. Note that I can still make some modifications (if necessary), so no may not be no by the time I finish with this one.

[ti99iuc]

in the meantime Tutankham for MSX is OUT ! ............. http://msx.ebsoft.fr/muffie/

 

 

very nice especially the golden cartridge

 

 

But ... i am sure The TI-99 Version by Retroclouds will be more nice !

... also because the manual and the cartridge label are already ready ...

 

- -

 

and for the Box i am organizing... the program was at a good point if i remember good... so Retroclouds ... please ... Give a Gift to the Community !

Edited May 10, 2014 by ti99userclub

[+Ksarul]

I finished analyzing the signaling differences on the 512K board when using the Nonvolatile SRAMs and determined that I can get the necessary changes for the DS1230Y and the DS1245Y into the board relatively easily. That would give 32K or 128K of development space to those who need it. The area around the 378 is getting a bit too crowded to try to fit the necessary changes for the BQ4015YMA into it, so it looks like the upper limit is 128K in nonvolatile SRAM mode without doing some flying wires. I may still be able to fit it in, but it will be tight (even though I only have to deal with one more signal line). I'm going to have to mull it over some more to explore the realm of the possible. . .

[+Ksarul]

I did some careful rerouting of signals this morning and succeeded in getting everything in place to use the 512K BQ4015Y in addition to the DS1230Y and the DS1245Y. New boards will now have the capability to use EPROMs from 8K to 512K and use nonvolatile SRAMs of 32K, 128K, or 512K. That was a bit of fun to twist into the board.

 

I had actually considered upgrading the board to use 42-pin 1024K or 2048K chips and a 74LS377, but I think I will leave that kind of modification for the future, as the current boards pretty much max out the capability to display everything on the menu. If someone decides to write a single, massive cartridge program that needs that much space, I'll revisit the issue. Note that there might not be enough room on that board to make it fully jumperable to accomodate all of the smaller chips--a 42-pin socket eats a lot of space, leaving very little usable space to set up the jumpers.

 

We really need to make a separate thread for this discussion though, unless Retroclouds thinks he'll need a 512K with Nonvolatile SRAM for continued development of a cartridge version of Tutankham. . .

Edited May 11, 2014 by Ksarul

[+retroclouds]

Quick question. How would I program such chip? Can I use a normal EEPROM programmer, or do I need special hardware for doing that? Could it be programmed on the TI-99/4A itself?

 

But an other questions comes up: Do the new cartridge boards offer any extra RAM space (e.g. 1K or 2K) ?

Edited May 14, 2014 by retroclouds

[+Ksarul]

Using the Non-Volatile SRAM chips, you would just move the write protect jumper to enable and write to the chip (you'd have to write a short loader app to do that). Once done, jumper back to write protect and test. . .note the issues your loader would have to address (identified in this thread). You could also program them with an EPROM burner, assuming the one you have supports the specific chip you're using.