That game DoorDoor looks quite fun. Would be interesting to see how it compares to the MSX version.
Many of the Tutor games are rather of poor quality, but this one might look worth converting to the TI-99/4A.
Could you do a short video on DoorDoor? Would be a primer as I havent found any Youtube video of this game in the Tutor version.
This is very interesting work. A few years ago I started doing a Tutor version of Pitfall but got sidetracked.
I remember that at the time the biggest problem was debugging. I used Mame (or was it Mess) for emulation at the time, guess that the debugger has improved a lot by now.
Basically there should be many TI-99/4a games that can be converted for Tomy Tutor and Pyuata. Especially the ones were there is assembly source code available, run from ROM and only use scratchpad. Having said that TI-Invaders and Munchman should also be good candidates and perhaps a few of the shortn sweet machine code games.
TMS9995 is faster than TMS9900, I wrote NOP before accessing VDP. And I've made PITFALL! debug version.
Oh, sorry to hear that it is freezing. I wouldn't think that the Pyuuta is slower than the TI-99/4A. I don't know though. We have another computer, the Geneve 9640 that uses the 9995 processor. I think, by default that uses the processor's built in wait state generation and is still a few times faster than the 4A.
I haven't looked at if the Pyuuta uses the wait state on or off. But even on, I would expect it to be faster. The Pyuuta runs the CPU at a lower clock speed too (10.??Mhz / 4), though. If the 9995 was at full speed using a 12Mhz crystal with 1 wait state, it would be about 25% faster than a 9900 with no waitstates. (At least that is what I infer from timings on Stuart Conner's website regarding these CPUs outside of the confines of these computer systems. However, in the 4A, we have severe wait states. So the 4A should be a lot slower.
The 9918 VDP has some kind of overrun issue. Could this be a case of the the CPU overrunning the VDP? I never read anything about what the symptoms are for that overrun issue. Maybe some of our experts here can rule that out?
Also, how have you configured your ROM to test on real hardware? I'd love to know. I want to recreate the Japanese cartridge adapter for the back of my US Tutor, and also be able to recreate cartridges.
I would guess that /CS ROM1 is high by default, and so you have it controlling the most significant address bit on a 32k x 8 eprom. So eprom offsets >0000 to >3FFF are in the beginning of the eprom and only visible when /CS ROM1 goes LOW.
Is that correct? I don't own any 32k cartridges, so I'm just speculating based on the cartridge port pinouts