Classic99 Updates

[Willsy]

Feature request (pretty please)!

 

A routine to time sections of code. How would we integrate something like that into the Classic99 TI-99/4A "architecture"?

 

How about:

 

Write to CPU ram >0000 (any value) - zero's timer and begins counting

Write to CPU ram >0002 (any value) - stops counting and places the accrued number of milliseconds at >FFFA

 

So:

 

CLR @0 ; begin timing

LI R0,0

LI R1,BUFFER

LI R2,768

BLWP @VMBR

CLR @2 ; stop timing

Number of milliseconds to be found at >FFFA (and possibly in the debug window )

 

Whaddaya think?

 

Mark

[RXB]

Well got the Debugger to stop stepping in and taking over the Classic99 and locking up. As usual kinda my fault.

 

When I changed the GPL code from >C000 to >2000 it stopped going to the Sound routine even though I had no sound access at all in the GPL program at all.

 

 

Ok just figured out how to duplicate a lock on Classic99.

 

Load GPL@LOADER and set that GRAM address to load.

Before loading that GRAM file set a Breakpoint before starting GRAM file.

Load the GRAM Object file and run the GPL program.

With the debugger on it hits the breakpoint in GRAM.

Close debugger and reset Classic99 with Reset. Or just hit Reset and go to next step.

Reload a cartridge as you changed the cart in GROM memory. Or not as Reset puts you back with the cartridge loaded and normal GROM.

Now load GPL@LOADER and set GRAM address to load. ( Should have not to as it still works so this is optional)

Load GRAM Object file and it locks up while loading before half way done.

 

Does this every single time. Only solution is to Reset Classic99 and Close Classic99 and restart from beginning.

 

Or change the GRAM memory file to load at a different address like instead of >C000 to >2000 then to >4000 or >A000

 

If the same GRAM file loads at the same GRAM address GPL@LOADER locks up every time. Change the GRAM address it loads at and it never locks up again. Very odd behavior.

 

(By the way never locks up at the breakpoint address while loading so that does not seem to be the problem)

Edited July 30, 2011 by RXB

[+InsaneMultitasker]

Feature request (pretty please)!

 

A routine to time sections of code. How would we integrate something like that into the Classic99 TI-99/4A "architecture"?

 

How about:

 

Write to CPU ram >0000 (any value) - zero's timer and begins counting

Write to CPU ram >0002 (any value) - stops counting and places the accrued number of milliseconds at >FFFA

 

So:

 

CLR @0 ; begin timing

LI R0,0

LI R1,BUFFER

LI R2,768

BLWP @VMBR

CLR @2 ; stop timing

Number of milliseconds to be found at >FFFA (and possibly in the debug window )

 

Whaddaya think?

 

Mark

 

CLR @4 - breakpoint?

 

It's of little consequence but for trivia's sake, be aware there are programs which read/write to the ROM, usually 0x0000, to determine if its host is a TI or Geneve. The assumptiom: ROM=TI; RAM=Geneve.

[OX.]

Hi Tursi,

 

This isn't a request as such, more a wish list for Classic99 as I know this stuff would take quite a bit of work but maybe you can tell us if they are in the pipeline at all :-

 

Save states, 80 Column (already answered), floppy write support, speech (to MESS standard).

 

OX.

Edited July 31, 2011 by OX.

[sometimes99er]

Request

 

http://www.atariage.com/forums/topic/185594-filthy-balls-a-few-challenges/page__view__findpost__p__2338524

 

[Tursi]

Yes the emulator is running but is stuck in a loop I can not get it out of, the GROM address stays the same but the CPU is running the same loop over and over.

I can not print out a log when the emulator is locked up totally. But when F1 does work I will print one out for you. I do not have a scroll lock on the MacPro keyboard. Will have to look that one up.

 

It's easier than that... just select Edit->Debugger. If that also does nothing, then I need to know about that (because that's a pure Windows-side operation). You can use the menu on the debugger to breakpoint (no need for hotkeys), but I don't need you to breakpoint, I just want to see if Classic99 has reported any internal problems. Just copy and paste the debug information from the debugger Window. If you can't select the text because it is refreshing or scrolling, use View->Freeze.

 

 

I can not reproduce the problem as it never lets me get to the one that started it, it locks up before I get there but has the same GROM address each time GC124. If I can get a print out to help I will.

 

If it happens to you every other time, that's reproducing it. I don't need the original case, I just need a case where you are losing control of the emulator (crashes of the software inside the emulator is a different case ).

 

(edit: ran through your suggested steps with your zip file - see my results below)

Edited August 1, 2011 by Tursi

[Tursi]

Ok so it is stuck in a loop at >0C28, >0C2C, >0C2E, then loops back to >0C28 forever.

 

It never lets me get out of the loop no matter what I try. F3, F2 do nothing but F1 is the only one that works and that just stops and starts it the stuck loop.

 

I never get to a breakpoint so that does not matter. The debugger is broken as the when a program starts it crashes after I use GPL@LOADER to go to a program I wrote.

 

So here is the Object code and GPL@LOADER that loads at GRAM >C000

 

F2 and F3 won't do anything to a running program, and F1 is supposed to stop and start. F1 triggers an immediate breakpoint. F2 steps /after/ the program is at a breakpoint, while F3 does a step over /after/ the program is at a breakpoint. So that behaviour is completely correct.

Edited August 1, 2011 by Tursi

[Tursi]

Feature request (pretty please)!

 

A routine to time sections of code. How would we integrate something like that into the Classic99 TI-99/4A "architecture"?

 

How about:

 

Write to CPU ram >0000 (any value) - zero's timer and begins counting

Write to CPU ram >0002 (any value) - stops counting and places the accrued number of milliseconds at >FFFA

 

So:

 

CLR @0 ; begin timing

LI R0,0

LI R1,BUFFER

LI R2,768

BLWP @VMBR

CLR @2 ; stop timing

Number of milliseconds to be found at >FFFA (and possibly in the debug window )

 

Whaddaya think?

 

Mark

 

Classic99 needs a working realtime system before I'm going to add any kind of realtime measuring. In the meantime, use the cycle counting system. 3000 cycles = 1ms.

 

I'm not keen on adding fake memory-mapped hardware, the real hardware keeps me busy enough. The point of adding a flexible breakpoint system was to prevent needing to do that. If you need to be able to write to addresses from your software to run the cycle counting engine, I can consider changing it from a memory range (although in your example above, a memory range would be sufficient.)

Edited August 1, 2011 by Tursi

[Tursi]

Hi Tursi,

 

This isn't a request as such, more a wish list for Classic99 as I know this stuff would take quite a bit of work but maybe you can tell us if they are in the pipeline at all :-

 

Save states, 80 Column (already answered), floppy write support, speech (to MESS standard).

 

OX.

 

Save states = someday. Have toyed with the idea a few times. Not sure when.

80 column = someday, maybe when I rewrite the VDP, but no estimate on when. Expect years.

Floppy write = yes, probably sooner. I'll need this eventually myself.

Speech = maybe, but not "to MESS standard". I'm not really interested in what MESS does. I was toying with rewriting the speech engine though.. right now it's using the old MESS code. We seem to have enough data these days.

[Tursi]

Request

 

http://www.atariage.com/forums/topic/185594-filthy-balls-a-few-challenges/page__view__findpost__p__2338524

 

 

Done and posted.

 

358, I think. Figured out what went wrong with the last upload and it should work now.

 

http://harmlesslion.com/software/classic99

[Tursi]

Well got the Debugger to stop stepping in and taking over the Classic99 and locking up. As usual kinda my fault.

 

When I changed the GPL code from >C000 to >2000 it stopped going to the Sound routine even though I had no sound access at all in the GPL program at all.

 

 

Ok just figured out how to duplicate a lock on Classic99.

 

Load GPL@LOADER and set that GRAM address to load.

Before loading that GRAM file set a Breakpoint before starting GRAM file.

Load the GRAM Object file and run the GPL program.

With the debugger on it hits the breakpoint in GRAM.

Close debugger and reset Classic99 with Reset. Or just hit Reset and go to next step.

Reload a cartridge as you changed the cart in GROM memory. Or not as Reset puts you back with the cartridge loaded and normal GROM.

Now load GPL@LOADER and set GRAM address to load. ( Should have not to as it still works so this is optional)

Load GRAM Object file and it locks up while loading before half way done.

 

Does this every single time. Only solution is to Reset Classic99 and Close Classic99 and restart from beginning.

 

Or change the GRAM memory file to load at a different address like instead of >C000 to >2000 then to >4000 or >A000

 

If the same GRAM file loads at the same GRAM address GPL@LOADER locks up every time. Change the GRAM address it loads at and it never locks up again. Very odd behavior.

 

(By the way never locks up at the breakpoint address while loading so that does not seem to be the problem)

 

I think I followed your steps, but I don't see a lockup. I see Classic99 breakpointing because GROM was read at the address I had a breakpoint set on. It even says in the title bar, "Classic99 - Breakpoint. F1 - Continue, F2 - Step, F3 - Step Over"

 

However, if you have the debugger window closed, you may have trouble undoing the breakpoint, especially without a scroll lock key. But just opening the debugger window, clearing the breakpoint, and continuing the program (Debug->Normal Speed) should do the trick. When I do this, it continues on to a successful load.

 

Maybe we are just seeing confusion because you have closed the debug window? It's possible that it is not updating correctly and the reported GROM address is incorrect -- someone else was mentioning oddness there.

[RXB]

Yea Tursi that may be it. It seems to be that object file that did it? Now that I have newer better code it does not do that. So that oddness may be what I hit.

[OX.]

Hi Tursi,

 

This isn't a request as such, more a wish list for Classic99 as I know this stuff would take quite a bit of work but maybe you can tell us if they are in the pipeline at all :-

 

Save states, 80 Column (already answered), floppy write support, speech (to MESS standard).

 

OX.

 

Save states = someday. Have toyed with the idea a few times. Not sure when.

80 column = someday, maybe when I rewrite the VDP, but no estimate on when. Expect years.

Floppy write = yes, probably sooner. I'll need this eventually myself.

Speech = maybe, but not "to MESS standard". I'm not really interested in what MESS does. I was toying with rewriting the speech engine though.. right now it's using the old MESS code. We seem to have enough data these days.

 

Thanks Tursi that's good to know - the save state and floppy writes are what I think will make the emulator functionally much better.

[Tursi]

Yea Tursi that may be it. It seems to be that object file that did it? Now that I have newer better code it does not do that. So that oddness may be what I hit.

 

As a safety, I'd recommend not closing the debug window while breakpoints are configured. I was slowly migrating the system to disable all debug features unless the debug window was open, but it's not there yet.

[RXB]

Yea Tursi that may be it. It seems to be that object file that did it? Now that I have newer better code it does not do that. So that oddness may be what I hit.

 

As a safety, I'd recommend not closing the debug window while breakpoints are configured. I was slowly migrating the system to disable all debug features unless the debug window was open, but it's not there yet.

 

 

Thanks.

Ok another snag. When I run and load into GRAM the GPLHOW2I and it exits to the TI Title screen as I did this to prevent key scan lock ups as they seem to occur for no reason at all.

 

What happens is none of the number keys do anything at all, ALT+= key will exit back to TI Title screen but the key scan is locked and keys 1 to 4 (see screen shot) does not work so I have to reset and reload GRAM and start over each time.

 

Classic99 seems to be reseting the Scroll Lock key just randomly. My MacPro has no Scroll Lock key I have to run the Accessories, Ease of use, and on screen keyboard to get access to it from Windows 7, what is going on?

 

My GPL program should not be able to affect the Scroll Lock key as the TI does not have one and neither does my MacPro.

FROZEN.bmp

[RXB]

Does not matter what cartridge I use to load the GRAM it still does it.

FROZENAGN.bmp

[Tursi]

Ok another snag. When I run and load into GRAM the GPLHOW2I and it exits to the TI Title screen as I did this to prevent key scan lock ups as they seem to occur for no reason at all.

 

They /appear/ to be for no reason because you don't understand what has actually happened. There is always a reason for anything software does.

 

Unfortunately I've never seen any of the symptoms you describe, so I can't explain it. But if you come to a conclusion first, and then match the symptoms to the conclusion, it slows us down. Stick to symptoms and the steps taken to get there or correct it, without trying to explain what you think went wrong.

 

What happens is none of the number keys do anything at all, ALT+= key will exit back to TI Title screen but the key scan is locked and keys 1 to 4 (see screen shot) does not work so I have to reset and reload GRAM and start over each time.

 

The only keyboard stuck issue I've seen is if you swap windows a lot while pressing keys, the metakeys may get "stuck" as they don't see an up event. Pressing Enter should clear this. If it doesn't, press and release each shift, control, and alt key once while the window is focused.

 

Classic99 seems to be reseting the Scroll Lock key just randomly. My MacPro has no Scroll Lock key I have to run the Accessories, Ease of use, and on screen keyboard to get access to it from Windows 7, what is going on?

 

Classic99 is not capable of altering the state of the scroll lock key. And the only keys on the keyboard affected by Scroll Lock are the function keys F1-F12. You are jumping to conclusions here, this hurts our ability to troubleshoot the issue. The only question is whether you have Scroll Lock enabled by default or not. If you do, don't use the function keys unless you mean it. Otherwise, just ignore it. You can do everything from the debugger menu without scroll lock.

 

My GPL program should not be able to affect the Scroll Lock key as the TI does not have one and neither does my MacPro.

 

They are not able to affect the Scroll Lock key.

[RXB]

Thanks, what happens is I load the GPL DEMO and the game plays as normal, then the game if I win or lose exits to the TI Title screen. The only keys I have used to this point is the Arrow keys. And I have not clicked anything out of the Classic99 window.

 

I also have not touched any key but the arrow keys. Then when at TI Title screen I press enter it goes to the TI Menu screen but any key I press just honks and nothing happens(except the ALT+= works), so I open Accessories, Ease of use, then On screen keyboard and press Scroll Lock, now the number keys work. (But then this affects the programs I use so I again have to go turn off or on the Scroll Lock key)

 

What I am asking is why does this happen? I have done nothing to make me have to go toggle the Scroll Lock key. Is there something in the .ini file causing this, I am using the same one I have always used. Also this only happens when loading GRAM files so why I assumed the two are related.

[Tursi]

Thanks, what happens is I load the GPL DEMO and the game plays as normal, then the game if I win or lose exits to the TI Title screen. The only keys I have used to this point is the Arrow keys. And I have not clicked anything out of the Classic99 window.

 

Which arrow keys.. the PC arrow keys or the ESDX keys?

 

Remember, a real TI doesn't have PC arrow keys. So when you press them, assuming your software is not reading the joystick, those keys return FCTN+E/S/D/X (depending on which one you pressed).

 

I /have/ seen issues with the arrow keys and the Fctn keys sometimes leaving the Meta key state inconsistent. Again, pressing Enter is deliberately programmed to reset that, so it should clear if you do that.

 

I also have not touched any key but the arrow keys. Then when at TI Title screen I press enter it goes to the TI Menu screen but any key I press just honks and nothing happens(except the ALT+= works), so I open Accessories, Ease of use, then On screen keyboard and press Scroll Lock, now the number keys work. (But then this affects the programs I use so I again have to go turn off or on the Scroll Lock key)

 

You almost definately have a stuck meta key. The fact that toggling scroll lock is working is a red herring, it has nothing to do with that, you just changed the keyboard state. Try the tips I gave in my last message. Press Enter to clear the state, and if that doesn't work, press and release each shift, alt, and control key once to clear them. This always works for me.

 

I hereby advise you to not touch Scroll Lock.

 

What I am asking is why does this happen? I have done nothing to make me have to go toggle the Scroll Lock key. Is there something in the .ini file causing this, I am using the same one I have always used. Also this only happens when loading GRAM files so why I assumed the two are related.

 

Scroll Lock hasn't toggled. But when you toggle it, you change the virtual keyboard mode, which is apparently indirectly clearing your stuck meta key. Scroll Lock's state does not affect the number keys on the keyboard.

[RXB]

I use the arrow keys on the PC keyboard or FCTN keys on the TI as I absolutely hate the WSDX keys as they are not in any stretch of the imagination in the same pattern as the arrow keys are. Mine look like this:

 

WE

SD

ZX

 

And needless to say the arrow keys are in the normal upside down T pattern as you would expect:

 

U

LDR so I can put my left had on the arrow keys and use my right hand on the mouse just like every bloody game made today online or previously. (I do not mouse steer unless I am forced to)

 

I will try your suggestion with the ENTER key and others. Just wondering why does only the Enter key fix this? Why not just reset on any key that way it works like it should whether I use the Space bar or any key?

[RXB]

I use the arrow keys on the PC keyboard or FCTN keys on the TI as I absolutely hate the WSDX keys as they are not in any stretch of the imagination in the same pattern as the arrow keys are. Mine look like this:

 

WE

SD

ZX

 

And needless to say the arrow keys are in the normal upside down T pattern as you would expect:

 

.U

LDR so I can put my left had on the arrow keys and use my right hand on the mouse just like every bloody game made today online or previously. (I do not mouse steer unless I am forced to)

 

I will try your suggestion with the ENTER key and others. Just wondering why does only the Enter key fix this? Why not just reset on any key that way it works like it should whether I use the Space bar or any key?

 

 

 

SERVER RESTARTED ON ME SO IT PUT UP THREE POSTS.

Edited August 3, 2011 by RXB

[OX.]

Hi Tursi, can I place a request to remap TI keys? One annoying issue I've found is trying to play Keyboard games that use S,E,D,X for directional keys on a PC keyboard, this would give the ability use the PC standard W,A,S,D or cursor keys.

 

Thanks, OX.

[Tursi]

I will try your suggestion with the ENTER key and others. Just wondering why does only the Enter key fix this? Why not just reset on any key that way it works like it should whether I use the Space bar or any key?

 

If you press FCTN-S, you don't expect the S key to release the FCTN key. Enter is a key that, in practice, indicates you are done typing something. Since it's the logical end of line, I selected it as a reset for a rare condition I occasionally saw. Space bar would probably have been fine, but it's not usually the end of line. Definately don't want "any" key to reset the meta counts, you're probably still using the meta keys for most of them!!

 

The problem comes up because there are so many ways to press FCTN (as a for instance), and is worse on the emulator because of the Windows method of messaging keypresses. For instance, the real TI has one FCTN key. But the emulated keyboard may have to activate FCTN for left Alt, right Alt, PC arrow keys, PC function keys, and numerous punctuation characters. Most complicated are those that remap PC meta keys. For example, when you get a question mark, that's SHIFT + / on a US PC keyboard. But it's FCTN + I on a TI keyboard, so the logic has to ignore the shift key, virtually press the FCTN key, ignore the / key, and virtually press the I key. Made more complex by the fact that you don't press them at the same time, you press shift, then /. Then you may release them in either order, and that has to be handled. (I simplified this a bit by not reporting the shift keys to the TI. On the real adapter you can force shift keys with the Windows keys, but this will be intercepted by Windows in Classic99). The last and trickiest part is that on a PC keyboard, people tend to overlap keypresses (press the next key before releasing the old one). The TI keyboard doesn't like it when you do this, so it's also handled.

 

I'm not sure offhand how others handled the virtualization of the keyboard, but since I had to interface with the same keyboard pins as the physical keyboard, there were no sofwtare-based shortcuts available.

 

In practice, the PS/2 adapter only tends to gets the meta counts confused if I seriously confuse it by hammering on the keyboard - something I'd still like to work on. But it's worse in Windows, because not every key down event is guaranteed a key up event (particularly some of the Alt-key combinations are eaten by Windows), so I had to put a little extra code in there to make the PS/2 emulation reliable.

[Tursi]

Hi Tursi, can I place a request to remap TI keys? One annoying issue I've found is trying to play Keyboard games that use S,E,D,X for directional keys on a PC keyboard, this would give the ability use the PC standard W,A,S,D or cursor keys.

 

Not any time soon. My stance on that is that the TI is not a PC game machine. Though a remap ability would probably help the Brits get their keyboard set!

 

Unfortunately a lot of the logic is hard-coded for a physical PS/2 keyboard, so the mapping in use maps PC keys to PS/2, there's no easy way to map from PC key to TI key. Just the GUI for a keyboard editor is a pain in the butt, too. Though I'll put some thought into adding some manual INI adjustment commands.

[RXB]

All the TI99 games or programs written use the arrow keys by substituting ESDX as being the arrow keys. On a PC the arrow keys are off the on the side instead of using the same keys and that is the problem.

Any program I have ever written uses this fact, but fails on the PC keyboard as the PC keyboard does not line up the keys correctly to pull this off.

Nor do they line up like the TI99 keyboard, they are misaligned that way on purpose on a PC, and some PC keyboards are worse then others for WSDX or ESDX.

As the FCTN key on a TI99 is on the right side you use two hands to steer (i.e. right hand on ESDX and left on FCTN key), this is not necessary on a PC keyboard as we can now use the Arrow keys with out having to hold the FCTN key.

Why is it a problem to use the Arrow keys on the PC?

 

I would not even mind if I had to hold the FCTN key to use the Arrow keys just like the TI99 but then again the Arrow keys on a PC are on the right side and the FCTN is on the left, opposite of the TI99.

So that is impossible to duplicate the TI99 keyboard on the PC keyboard as your hands become the opposites. The only choice is to use the Arrow keys on the PC keyboard because of this.

 

Maybe we need a indicator on Classic99 we can turn on to see what bloody keys are set, as right now it is pure guess work as to which meta key is the problem.

Edited August 3, 2011 by RXB