Classic99 Updates

[Tursi]

Speaking of keyboard mappings .... I've got a linux box , and when I use classic99 under wine, naturally I have no copy/paste so I code straight to the emulator, i am quite happy doing that..... however .... when running under normal TI99/4A mode, I kept accidentally pressing, I think was it Minus and Equal down at the same time and it would reset back to the TI splash screen and BEEP

 

This one surprised me, so I tried it, and sure enough, Shift+dash+equals will reset. The reason is pretty simply, though..

 

Shift-dash is the underscore. On the TI keyboard, underscore is FCTN-U. So from the TI's point of view, you are pressing FCTN, SHIFT, and Equals.... FCTN-Equals is, of course, QUIT, and the interrupt routine doesn't care if other keys are also pressed.

 

Even worse, "Ctrl+Alt+= to reset" doesn't fix this, since it happens at a lower layer than the emulated keyboard (it happens after the mapping). I'll have to think about whether there is a way to fix this. It would happen with any other combination that invokes FCTN, too, for instance, Shift-tilde-equals, or shift-question mark-equals, or arrow-key equals, or function-key equals, or...

 

I wonder if other emulators with a mapped keyboard also reset in this case?

[Tursi]

Meh... I can live with it. I really only use a TI (Classic99) for TurboForth, so when the problem occurs it's usually when I'm in the block editor. Like I say, 99% of the time pressing enter fixes it (IIRC Classic99 resets something when Enter is pressed?) and if it's screwed up my source code I can just press FCTN = to exit the editor and lose the changes, re-invoke the editor and I'm off. It's a minor inconvenience to be honest. Classic99 is all about the debugger for me. I would simply be lost (and would have moved away from TI software development completely) without that debugger. I simply would not have the patience to do it any other way. Try writing machine code in Win994A, with nothing but Millers Graphics Explorer to help you when you're stuck! Ewww...

 

Maybe, but it's a major defect in a critical piece of functionality.

 

There are two ways it tends to get out of sync that Enter clears - the first is ref-counting on the meta-keys (alt and shift), the second is stuck keys.

 

Since I don't run into the issue, I see two potential causes. One is your keymap, which I think I'll need to get a UK keyboard to try against (wondering if there is an edge case in my code caused by different shift sequences on certain characters). The other is typing style.

 

When I did the PS/2 keyboard adapter, something I very quickly had to deal with was overlapping keystrokes. On the TI, it is completely illegal to overlap your keystrokes. If you don't release the old key before you press the new key, you will get the wrong character on the screen. On a PC keyboard, keystrokes are edge-triggered, and I (and probably others) tend to press the next key before the last key is released.

 

My mechanism seems to work fine on the AVR, but I ran into additional issues when I ported it to Windows with the messages being a little less reliable. I thought I'd nailed down a compromise, but perhaps not.

 

If you get into a situation where it's happening, I wonder if you can try to watch when it loses it for you? If it's around punctuation characters? Or if it's when you are typing very quickly? That will help me isolate where to kick the code.

[TheMole]

that's odd. In the basic case, again, I'm not doing anything fancy with the clipboard.

 

But I can't support all the emulation environments out there, I just don't have time. :/ Baffled though I am that they don't work.

 

That it put down anything at all means that it succeeded at opening the clipboard and finding text on it. I suppose we could add a ton of debug to figure out what it's glitching on (though I'd rather see Wine fix THEIR bug ).

 

Tursi, how do you handle data coming from the clipboard for the "special" past functions (such as paste XB). Might there be an issue of different control characters being copied to the clipboard in Windows and Linux? E.g. the newline/carriage return in windows vs newline only in Linux?

[Tursi]

Tursi, how do you handle data coming from the clipboard for the "special" past functions (such as paste XB). Might there be an issue of different control characters being copied to the clipboard in Windows and Linux? E.g. the newline/carriage return in windows vs newline only in Linux?

 

The Clipboard handling is the same in both cases - Paste XB just processes the received string, stripping unneded spaces mostly, and modifies the emulated TI briefly to accept a longer line. (That's why you don't use it outside of XB).

 

But I should note that in order to support copy and paste from Internet Explorer and this forum software, Classic99 actually has to check the clipboard for various types of data. I wonder if that is causing the issue? If there is nothing but plain text, then there is no problem, but maybe Wine is putting other data types on the clipboard.

 

There is a really annoying issue wherein some interaction between the way this forum renders text and the way IE copies to the clipboard that says of the 3-4 copies of everything that ends up on the clipboard, no one of them is entirely correct. (Whitespace is wrong in some manner in each of them.) Classic99 detects this and actually stitches together a couple of copies to try and get the best result.

 

This can be disabled, and I should have thought about it earlier. Under Options->Options, disable "Use Enhanced Clipboard (May need for IE copy and paste)" and see whether it helps at all?

[+Lee Stewart]

... But I should note that in order to support copy and paste from Internet Explorer and this forum software, Classic99 actually has to check the clipboard for various types of data. I wonder if that is causing the issue? If there is nothing but plain text, then there is no problem, but maybe Wine is putting other data types on the clipboard. ...

 

I used to have a similar problem quite awhile ago. The problem, for me, eventually was fixed in a later version of Classic99. Perhaps my fix then could help @TheMole now. It was to first paste to Notepad (or similar, text-only text editor); then select that and copy to the clipboard; and, finally, paste to Classic99. That never failed; but, like I said, I haven't needed to do that for a long time.

 

...lee

[OX.]

I am traveling so possibly later this week or over the weekend.

 

Hey Insane, did you ever upload the fixed version of this?

Edited August 10, 2013 by OX.

[+InsaneMultitasker]

Hey Insane, did you ever upload the fixed version of this?

I'll try to get to it soon. Real life reared its head with some nasties that have kept me away from pretty much everything computer related, TI and otherwise. I have not forgotten - and I may have even located a few other disk of dinosaur disks in my library. Pester me in a week or so if I haven't gotten back to this...

[+OLD CS1]

Tursi,

 

What would it take to put native CF7+/nPEB support into Classic99? Now that I have my CF7+ and TI back together, I can more easily develop on the PC and move things back and forth between a real TI and PC. I do this by having created a DSK file and mounting that in Classic99, then writing that to the CF7+ CF card (and back, sometimes) using TI99dir.

 

Now, if Classic99 had the ability to directly mount a volume on the CF card and read and write from within the program, life would be one notch cooler.

[Tursi]

I could directly mount and read/write the CF card, I suppose. I would hesitate to call it CF7 compatibility... I'll consider that for the task list.

[Tursi]

Classic99 v368 - http://harmlesslion.com/software/classic99

 

I found at least one possible reason for "stuck" keys as you guys have been describing. If you are using the emulated keyboard-based joystick (ie: using the arrow keys as a joystick instead of the joystick), Classic99 tries to be clever. If the program is reading the joystick, then the fctn-arrow keys are locked out, and only joystick reads are returned. After a few seconds, they return to being normal keys.

 

However, if you are holding the key in keyboard mode when it transitions to joystick mode, the old keys are not released. It can be impossible to know if a program has stopped scanning the joystick, so there's little you can do with this. I was able to reproduce that case and see it get me stuck in Munchman, so I fixed it, at least. And that's the main drive behind this release. See if it helps your gaming, anyway!

 

The other big update is a requested hack for 128k of VRAM for use in FunnelWeb. I was of mixed feelings about that one, but it didn't conflict with the F18 registers, so I put it in. Activate it with Video->Enable 128k hack, and Video->Enable 80 Column Hack must ALSO be on. It's not possible to go to 192k, by the way, without register conflicts, so I won't be doing that. If it doesn't work with a particular piece of software, checking out why is my lowest priority.

 

Also, the sprite fix that was mentioned elsewhere, and the debugger fix mentioned elsewhere again, and a potentially smarter Paste XB that sends less data to the TI by better space elimination, and skipping of blank lines and lines that start with '!'. Use with care till that's proven not to be buggy!

 

In detail:

 

-uber-grom updates to match upcoming release (not documented yet)

-added some debug to the disk controller for future memory-munching update

-better debug when classic99 munges TI filenames

-80-column 128k RAM mode added for 9938-compatible applications (loosely tested with Funnelweb - additional hack option in menu)

-fix bug that showed sprites when display was disabled

-fix setting of breakpoint registers so you can type them in decimal again

-fix (?) GROM breakpoint addresses

-fix keyboard ref counting if an arrow key is pressed when the arrow keys transition from keyboard to joystick mode internally

-improvements to Paste XB code to strip unneeded spaces better and skip over empty/comment lines (with '!' only, not 'REM')

 

 

[sometimes99er]

Excellent. Thanks.

[unhuman]

Well that's quick work! I just installed Classic99 last night on another PeeCee to play Titanium... And boom, there's a fix! THANK YOU!

[Tursi]

well, I don't know for sure if it's a fix till you guys tell me it's fixed.

[unhuman]

Well, I'm telling you!!!! It's fixed!

[+OLD CS1]

I think it is fixed for me, but this last version has taken a huge performance hit on my system so it is difficult to tell. If I re-size the screen to 2x or 3x, emulation performance drops drastically. I believe the problem is the graphics chip set (Intel 945 Express) on this laptop or its driver, and I think it is high time for me to accept that this laptop just is not up to the task. If I run Classic99 on an older laptop with a lesser CPU but a discrete video card (GeForce) the emulation runs fine.

[Tursi]

I think it is fixed for me, but this last version has taken a huge performance hit on my system so it is difficult to tell. If I re-size the screen to 2x or 3x, emulation performance drops drastically. I believe the problem is the graphics chip set (Intel 945 Express) on this laptop or its driver, and I think it is high time for me to accept that this laptop just is not up to the task. If I run Classic99 on an older laptop with a lesser CPU but a discrete video card (GeForce) the emulation runs fine.

 

Nothing at all has changed in the CPU core, timing system, or video rendering code... so I'd be inclined to suggest running one after the other to confirm that it's the new version that caused the performance hit. It doesn't make much sense that it would. Is it pegging the CPU?

 

Check the CPU speed under Options->Options is set to 100%. There was an old bug that caused it to sometimes drop to 0% on upgrades.. I'm pretty sure that's fixed but it doesn't hurt to look and see if it's off.

 

While you're in there, you can try adding a frameskip. That's under options->options. I have to confess I have not used frameskip for a /really/ long time and a quick test here didn't convince me it works anymore, but it didn't break anything. (Actually I don't think it works anymore..)

 

Also, remember Classic99 has three ways of rendering video to the screen - DirectX, DIB, and direct GDI ('none'). That's under Video->Stretch Mode. You may find that certain modes run faster than others depending on your drivers. DirectX is usually the fastest, but on some older machines DIB actually was faster. GDI will run a tiny unscaled window so probably isn't useful except for verifying whether it's scaling that is at fault. (The video system /will/ be modernized, the bitdepth I use internally was selected because it was the fastest on my Voodoo Banshee card, and that is pretty obsolete today ).

 

Finally, make sure you are not running "System Maximum" mode. That has a tendancy to hit the PC video system too hard and on some machines it's /slower/ than CPU Overdrive.

[OX.]

I'll try to get to it soon. Real life reared its head with some nasties that have kept me away from pretty much everything computer related, TI and otherwise. I have not forgotten - and I may have even located a few other disk of dinosaur disks in my library. Pester me in a week or so if I haven't gotten back to this...

 

I'm pestering

[Willsy]

Tursi, how does one access the extra VRAM? Is it documented with release (sending this via mobile so have not downloaded yet)

 

Mark

[Tursi]

It's not documented, but it's under Video->Enable 128k hack, and also requires the Enable 80 column hack to be on.

 

Please do not write new software that uses this mode. Unless Matthew does a new F18A that supports it.

 

[Tursi]

Version 369 released - DSRLNK debugging improvements, mostly. Also bugfixes for the configuration of the 128k VRAM and saving the screen size if you use something inbetween the fixed multipliers.

 

-First pass, sort of working read-only TI Disk Controller support (hacker only)

-Don't warn if 128k mode is active on startup

-save and restore 128k hack checkbox

-save screen size if not a multiple of resolution

-remove the hacky cartridge remap code that never worked

-add option to corrupt DSK ram to help find conflicts

-Ensure FIAD only writes well formed status bits into the header

-Create file by sectors will pad the file out to the correct size (not proven)

-Lots more DSRLNK debug & warnings - checks PAB and scratchpad addresses for basic information

-Fail opcode LOAD if file is larger than buffer - real disk does this

-Warn on DSR conflicts (turning on a card while another card is already on)

 

A note on the TI CC support - to enable it, set up a disk as a DSK image, then exit the emulator. Modify the Classic99.ini for that disk and change the type from '2' to '3'. The TICC code will be enabled, and you can step through it and use it fully. Note, however, that the disk controller chip is not emulated (and I don't plan to emulate it), and that sector read/write code is bypassed and handled in the emulator itself. However, this may be useful for troubleshooting DSR issues that Classic99 doesn't normally catch. Note that in this build, the drive must still be 1-3, and disks larger than 180k will not work (I will remove these limits in the DSR eventually, if it's useful). Another large limitation is the loss of debug information - the emulator doesn't know what is going on inside the controller, it's just running code.

 

I added this to solve some DSR issues I was having, and it did its job. I also added warnings and handlers for all the issues I found, so that Classic99 now notifies you of them when using the normal disk system. I think it's better now.

 

Regarding the corruption, in the normal FIAD or DSK modes, after a DSR call Classic99 will fill all VDP memory above the top of VRAM pointer, and known unsafe scratchpad locations, with the value "4A" - this can help you test if you are using assumptions from the DSR, which may fail on other DSRs. You can disable this in the Classic99.ini file by setting [DEBUG] "CorruptDSKRAM=0" -- it is ON by default. (We'll see if this bites me. So far it seems okay on most...) Note that Classic99 doesn't write this value in the INI right now - you have to add it.

 

http://harmlesslion.com/software/classic99

[Willsy]

Thanks Tursi - extra debugging information via the debug window is always welcome!

[Asmusr]

Another one for the wish list: in the debugger to be able to run to next vsync. You can add your own breakpoint if you know the code, but it would be really nice always to have this available as a one key/click option.

[Tursi]

Can you define what you mean by vsync there? You want a breakpoint to trigger when the VDP sets its internal blanking bit, or on external bit to the 9901 (you don't see if the VDP masks interrupts), or on signal to the CPU through the 9901 (you don't see if the 9901 is masking the interrupt), or on the CPU actually honoring it (ie: with LIMI 2, so you won't see during LIMI 0)?

 

As far as I can think, you can't trigger on any of those cases automatically right now, hehe. Seems like a good idea either way.

[Asmusr]

Can you define what you mean by vsync there? You want a breakpoint to trigger when the VDP sets its internal blanking bit, or on external bit to the 9901 (you don't see if the VDP masks interrupts), or on signal to the CPU through the 9901 (you don't see if the 9901 is masking the interrupt), or on the CPU actually honoring it (ie: with LIMI 2, so you won't see during LIMI 0)?

 

As far as I can think, you can't trigger on any of those cases automatically right now, hehe. Seems like a good idea either way.

Thanks. The first would be most useful to me. The important thing is to be able to see each video frame after it has been drawn.

[matthew180]

On a similar note, the MAME debugger lets you watch the screen being drawn while single stepping. I'm not sure of the exact mechanics, but any time any code executes that affects the screen, or an amount of time has elapsed that would have affected the screen, the results are visible. That has come in *very* useful for me in the past.

 

Since Classic99 keeps track of instruction timing then maybe while in single-step mode the elapsed time since last vsync could be passed to the render loops to limit how much of the screen they render. Scan lines are ~63.695us long and a pixel is rendered about every 186.2ns (~5.34 pixels per microsecond). Assuming there is a render loop similar to this:

 

render ( elapsed_time_us, single_stepping )
  render_time_ns = 0
  pixel_time_ns = 186.2  // in nanoseconds
  for y = 0 to 191
    for x = 0 to 341  // an actual scan line is more than visible pixels
      if x < 256  // only render visible pixels
        render pixel
      render_time_ns += pixel_time_ns
      if render_time_ns > elapsed_time_us and single_stepping == true
        y = 191
        break
      end if
    next
  next
  return