6 replies to this topic

[Willsy]

I wonder if Tursi would consider adding the following feature to the next release (or add it to the todo list!) in Classic99:

• Software controlled CPU overdrive; whereby
  
  • CLR @>0000 sets CPU to normal
    
  • SETO @>0000 sets CPU mode to overdrive

Obviously, the above would have no effect (which is a good thing!) on real TI equipment, but it would allow Classic99 users to switch on Overdrive for slow stuff, then turn it back off (I personally would not be interested in, for example, developing games that rely on the overdrive to function). For me, it would be useful to switch on CPU overdrive while TF is loading blocks from disks (to give the compiler a kick) and then turn it off again.

[matthew180]

Things like this have come up before, i.e. somehow having the code running on the emulator *know* they are running on the emulator, or do something emulator specific. Tursi tries very hard to avoid adding features like that, since the idea of the emulator is that the software does *not* know the difference between it (the emulator) and real hardware. Also, Tursi does not usually implement things that don't exist in the real world, otherwise people write software that can run on the emulator, but not a real system. I'm not speaking for Tursi, just relaying what I think I remember him saying in the past. And of course you can ask him in person in a week or two.

[OX.]

How about just having an option in the emulator to detect when disk activity is taking place and switching to turbo? It's a feature in quite a few emulators that is very handy.

[RXB]

I think Mathew is spot on this one. I often speed up Classic99 when I need to but how to make it automatic would just create programs that crash on a real TI or would not work on other emulators at all.

Edited by RXB, Thu Oct 27, 2011 3:45 PM.

[Willsy]

matthew180, on Thu Oct 27, 2011 10:28 AM, said:

Things like this have come up before, i.e. somehow having the code running on the emulator *know* they are running on the emulator, or do something emulator specific. Tursi tries very hard to avoid adding features like that, since the idea of the emulator is that the software does *not* know the difference between it (the emulator) and real hardware. Also, Tursi does not usually implement things that don't exist in the real world, otherwise people write software that can run on the emulator, but not a real system. I'm not speaking for Tursi, just relaying what I think I remember him saying in the past. And of course you can ask him in person in a week or two.

Indeed, and I completely understand that view point. Before you know it, you've kind of 'forked' the TI-99/4A into something else that only exists in emu land.

Mark

[Willsy]

OX., on Thu Oct 27, 2011 10:55 AM, said:

How about just having an option in the emulator to detect when disk activity is taking place and switching to turbo? It's a feature in quite a few emulators that is very handy.

That would work for me! It would remain compatible with the TI, and would have the benefit of improving the performance of all software that used disk a lot. For example, the Editor Assembler system would get an instant boost.

[Tursi]

Still no. But I appreciate the effort. However, I would not be adverse to making one of the breakpoint actions trigger overdrive. Breakpoints are flexible enough that you can trigger via PC, or any memory read or write of your choice.

The case of overdrive during disk activity is less relevant to Classic99 than many other emulators, because Classic99 is not emulating the disk DSR code. The parsing of the PAB, locating and parsing the file, and copying the requested data into VDP RAM all happens in native C++ code in Classic99. The processing of that data itself happens in the application. So in the normal case the line would be drawn, say, at the disk DSR. If that were done, though, there would be no difference in Classic99's case because the DSR already runs faster than is possible even with overdrive.

The alternative is to say that after a disk activity, overdrive stays on for a timed period. Determining the right period would be tricky and not be correct for 100% of the cases, but may be closer to what you're looking for.

I could add both of those things to my list (although I'm way behind and even more backlogged right now thanks to new job...)