Classic99 Updates

[oddemann]

6 hours ago, HOME AUTOMATION said:

Today, I finally figured out why, sometimes when I paste from Windows clipboard, it goes lightning fast, other times, not...

 

...apparently one of us is forgetting to untick PWWI, while pasting!

PWWI?

[+Lee Stewart]

1 hour ago, oddemann said:

PWWI?

 

“Pause When Windows Inactive” on the Options menu.

 

...lee

[+OLD CS1]

Ah. I thought it was like a WWWD ("What Would Windows Do?")

[+Schmitzi]

ah ok pwwi

[GDMike]

Wish there was just a hot key instead of clicking the options for turbo.

[Tursi]

6 minutes ago, GDMike said:

Wish there was just a hot key instead of clicking the options for turbo.

Well, you ain't never had a friend like me!

 

 

I have gone BACK IN TIME to IMPLEMENT YOUR WISH!

 

 

There is a catch - there always is with wishes. Close Classic99. Head outside on a nice cool summer evening and take a deep breath of the fresh air. Then come back in and open Classic99.ini. In the [emulation] section, find enableSpeedKeys, and set it to enableSpeedKeys=1

 

If it's not there, your version of Classic99 is even further back in the past than my flux capacitor allows for, grab a newer version, launch it and then exit it. Repeat above with the cool summer evening.

 

When you restart Classic99, F6 will set CPU Normal. F7 will set CPU Overdrive and F8 will set System Maximum, while F11 will toggle System Maximum (like MAME does). These keys are also active any time the debugger is open. Note that these keys will no longer be FCTN+number keys in this mode.

 

This table summarizes the keyboard shortcuts in Classic99, and is in section 7.8 of the manual:

 

[+OLD CS1]

Classic99 once was Classic88, and I saw some serious ?

[GDMike]

Oh wow. And just like that, ini repair is what the Dr. Ordered

 

[Airshack]

On 6/18/2021 at 4:47 AM, Lee Stewart said:

Pause When Windows Inactive” on the Options menu

Didn’t realize this. Thx. 

[Tursi]

Classic99 399.048

 

- Fix broken GPU - was broken in .044

 

http://harmlesslion.com/software/classic99

 

[Retrospect]

On 6/28/2021 at 6:44 PM, Tursi said:

broken GPU

Hi Tursi

What "symptoms" did having a broken GPU give?  I have had some strange behaviour lately out of classic99, well I don't know if it's something I have done or otherwise.  Does having a broken GPU give bizarre behaviour such as reporting "Memory Full in 10" when running compiled code?  I had 5000 bytes remaining and running HunchBack (programmed in XB256 and compiled) ran for like six or seven out of the 12 screens the game has, and then decided to stop, reporting the memory full error.  Line 10 was just the code to execute the compiled M/C.  I understand I have to retain some bytes for the program to run, but 5000 and a memory report?  That's the reason the new version of HunchBack (non-F18A) isn't out yet

[tmop69]

52 minutes ago, Retrospect said:

Hi Tursi

What "symptoms" did having a broken GPU give?  I have had some strange behaviour lately out of classic99, well I don't know if it's something I have done or otherwise.  Does having a broken GPU give bizarre behaviour such as reporting "Memory Full in 10" when running compiled code?  I had 5000 bytes remaining and running HunchBack (programmed in XB256 and compiled) ran for like six or seven out of the 12 screens the game has, and then decided to stop, reporting the memory full error.  Line 10 was just the code to execute the compiled M/C.  I understand I have to retain some bytes for the program to run, but 5000 and a memory report?  That's the reason the new version of HunchBack (non-F18A) isn't out yet

My Super AstroSmash can run with only 210 bytes free for the runtime (for non VDP RAM). With less than 180 bytes I experienced issues with memory full errors.
The compiled version of Atlantis by Intrigue has some memory full errors moving from various screens. These were solved placing the compiler runtime in low memory during compilation. Have you tried this?
The only drawback is that Module Creator 2 was not able to generate a SSS and you have to use MakeCart to create a GROM file (more expensive if you need to create a SSS, no difference if using the FinalGROM).

 

[Retrospect]

10 minutes ago, tmop69 said:

My Super AstroSmash can run with only 210 bytes free for the runtime (for non VDP RAM). With less than 180 bytes I experienced issues with memory full errors.
The compiled version of Atlantis by Intrigue has some memory full errors moving from various screens. These were solved placing the compiler runtime in low memory during compilation. Have you tried this?
The only drawback is that Module Creator 2 was not able to generate a SSS and you have to use MakeCart to create a GROM file (more expensive if you need to create a SSS, no difference if using the FinalGROM).

 

Hi Tmop69

Thanks, if I get more bother with the game I'll try to run from low memory.  I just thought it was worth asking about any bizarre symptoms of a broken GPU since I had 5104 bytes remaining and memory errors crept up on screen 7 of 12.  It's likely something I've done.  Either way I've updated to the latest classic99 and gotten rid of the previous version, so fresh code on the new emulator and we'll see how it goes.  Another reason I asked is because this particular one I had trouble with was using XB256 which uses extra characters and I didn't know if any GPU hackery was going on to do this .

[digdugnate]

On 6/17/2021 at 11:17 PM, HOME AUTOMATION said:

Today, I finally figured out why, sometimes when I paste from Windows clipboard, it goes lightning fast, other times, not...

 

...apparently one of us is forgetting to untick PWWI, while pasting!

Clearly it was double-interpreting, duh!

[+OLD CS1]

19 minutes ago, digdugnate said:

Clearly it was double-interpreting, duh!

 

[Tursi]

7 hours ago, Retrospect said:

Hi Tursi

What "symptoms" did having a broken GPU give?  I have had some strange behaviour lately out of classic99, well I don't know if it's something I have done or otherwise.  Does having a broken GPU give bizarre behaviour such as reporting "Memory Full in 10" when running compiled code?  I had 5000 bytes remaining and running HunchBack (programmed in XB256 and compiled) ran for like six or seven out of the 12 screens the game has, and then decided to stop, reporting the memory full error.  Line 10 was just the code to execute the compiled M/C.  I understand I have to retain some bytes for the program to run, but 5000 and a memory report?  That's the reason the new version of HunchBack (non-F18A) isn't out yet

I didn't write the compiler, so I can't tell you what it does. I don't think it uses the F18A GPU though.

 

The broken GPU was using the stack CPU, so if you attempted to execute any GPU-specific opcodes, they would not work. The most common visible symptom was, since most GPU programs use IDLE, a complaint in the debugger that IDLE was executed.

 

[Tursi]

6 hours ago, Retrospect said:

Another reason I asked is because this particular one I had trouble with was using XB256 which uses extra characters and I didn't know if any GPU hackery was going on to do this .

Remember that if it was, it would not work on a stock TI, and XB256 does.

 

[Retrospect]

Ok, thanks Tursi.  I think I may of figured what happened with my game, but it's not for this thread. 

[+InsaneMultitasker]

I'm doing some "playing around" with TIPI and Classic99 and encountered a few things that are probably the result of the code I am mucking with and/or more stringent requirements to support the simulation.

 

When attempting to open a connection I was seeing this weird failure in the debug log:

Accessing HEATWAVE.DDNS.NET:9640
Failed to look up address in TCP open, code 10109

 

I tested on my hardware and the open succeeded.   I also tried the TELNET program in Classic99 and it succeeds with the following debug message:

Accessing HEATWAVE.DDNS.NET:9640
Trying result 1

 

Digging into the connect routine (on my side) I found that it was sending a static length string of '50', with spaces appended to the url.  I'm thinking that maybe my 'real' TIPI ignores anything after the first terminating character, eg., null or space.  I should be able to adjust the program code to send only the host:port with no terminating chars.

 

The other challenge I am running into is that when BL'ing to the well-known addresses for messaging, and using a workspace other than GPLWS, the debug log warns me about the WS.   The TIPI wiki suggests using gplws is best practice though the code I've been looking at wasn't written that way for real hardware.  I'll try to reverse engineer the code to get around this as preliminary tests seem to indicate the Classic99 routine won't work unless it is called from GPLWS.  (is this true?)

 

I know the TIPI simulation code isn't necessarily "supported" so this is mostly just to share what I've encountered, and to say that it is nice to be able to play around with some TIPI code in Classic99. 

 

[Tursi]

Again, I offer no support of any kind whatsoever for Classic99's unreleased TIPI simulation. I did not officially announce it as a supported feature - that was Omega.  JS99er has full TIPI emulation.

 

I simply do not want to get into the nitty gritty on it and, as it's a simulation, it is coded to match the /documentation/ and not the actual implemented hardware (as much as possible). If the documentation is correct, and the software works on Classic99, it should work on real hardware, but there is no promise made that the inverse is true. Hell, the path matching is still wrong.

 

This is a big difference between implementing original hardware which has 40 years of people breaking all the rules, and implementing new hardware where there's really no good excuse for it.

 

If Classic99 warns you that you are breaking documented standards, then you need to get the standards changed before I'm going to do anything about it. "Everyone just does" breaks future compatibility, that's why standards exist. That nobody wants to follow them is why there are so many.

 

You're probably right that whitespace can be stripped from the DNS lookup - I would have expected the API to do that for me, but your diagnosis makes sense. I'll add the code but will not test it.

 

Not sure what issue you're having with not using GPLWS. I don't see anything in Classic99 besides the warning that uses it. 

bool directSendMsg() {
    unsigned char buf[65537];   // max size plus terminator
    int wp = pCurrentCPU->GetWP();
    if (wp != 0x83e0) {
        debug_write("Warning: Call TIPI functions with GPLWS (>83E0), SendMsg WP is >%04X", wp);
    }
    int len = romword(wp);
    int off = romword(wp+2);
    
    // because CPU memory is fragmented, use the read functions to fetch the data
    // we don't need to sanity test, this is safe
    for (int idx=0; idx<len; ++idx) {
        buf[idx] = rcpubyte(off+idx);
    }
    buf[len] = '\0';

    // now figure out what to do with it
    if (!handleSendMsg(buf, len)) {
        debug_write("handleSendMsg failed");
    }

    // always return false, direct calls don't skip like DSRs
    return false;
}

 

[Tursi]

7 hours ago, InsaneMultitasker said:

When attempting to open a connection I was seeing this weird failure in the debug log:

Accessing HEATWAVE.DDNS.NET:9640
Failed to look up address in TCP open, code 10109

At first this threw me with regards to the whitespace theory -- there's no whitespace in the name on the debug statement.

debug_write("Accessing %s:%s", hostname, port);

Winsock error 10109 is WSATYPE_NOT_FOUND, meaning "class type was not found". This means, in this case, that port 9640 was not supported for type SOCK_STREAM (TCP). Everything is passed around as strings, not as integers.

 

Soooo, I'm guessing the whitespace comes after the port, not the name.

 

A quick test on the real TIPI shows that user variables have leading and trailing whitespace both removed, at least through PI.VARS. I didn't check what counts as whitespace, mind...

 

That said, though, I think that I already strip trailing whitespace, so, I'm not entirely sure what is going on there... unless you have characters that are not traditional whitespace after the port (like the separator character 30, though that should have been stripped too... but we would not be able to tell from the debug as it doesn't print control codes.)

 

I did a test on my own server, and found that simply entering an invalid port number in Telnet gave me the same error 10109 -- this was simply for a port that does not respond and even ignoring whitespace issues. Is it not possible that was all that happened to you?

 

[+InsaneMultitasker]

1 hour ago, Tursi said:

Soooo, I'm guessing the whitespace comes after the port, not the name.

Thanks for the testing and information, Tursi. 

 

I completely understand the support situation and have no expectations in that regard.  I wasn't sure to what extent the simulation was being implemented, so I figured I'd share.  My goal is to update the TI code to reflect currently documented expectations, regardless of whether or not it works as-is     (I didn't write the original code in question)  (Edit: yes, there was whitespace after the port number, namely a number of spaces 0x20)

 

As for the GPLWS issue, I forced my routines to call recvmsg/sendmsg while my WS is set to 0x83e0 and that cleared up the issue.  I admit it might not be the real culprit, because while trying to debug my system kept "freezing".  It turns out that  when my Classic99 "option" to "pause when window inactive" is set, changing focus from the main window to the debugger window halts the main window's execution. No matter what keys I press while in the debug window, the main window sits dormant.    (I thought my system was locking up because none of the debug step keys were working).  By accident I later discovered that in some cases if I brought the main window into focus, the disassembly window started scrolling again.  Turning off PWIA let me select the debugger window without the main window halting.   I'll try this all on another PC when I get home to rule out my laptop and associated files.  (I am using the latest version .048 FWIW). 

 

 

[+dhe]

Any chance of adding the MBP Clock card - I'll do without A/D for now ?

Sometimes, it's nice and easy to just be able to read from a memory address.

 

[Tursi]

3 hours ago, dhe said:

Any chance of adding the MBP Clock card - I'll do without A/D for now ?

Sometimes, it's nice and easy to just be able to read from a memory address.

I think the odds of it being recreated are pretty low... I never had one and don't expect to write software for it.

 

It's a one time read for you - it's a lifetime of having to support it for me

 

[+OLD CS1]

Heat map is not working in .047; does it work in .048?  Or is it just me?