Classic99 Updates

[RXB]

Downloaded and Installed on PC, work great !

 

now i have to try and hope on my Apple ...

 

Thankyou for ever Tursi

 

 

You must not have a Intel Mac. I have Window 7 and XP 64 on mine along with OS X 10.7

[ti99iuc]

now i have to try and hope on my Apple ...

You must not have a Intel Mac. I have Window 7 and XP 64 on mine along with OS X 10.7

 

Perfect !

all work good like before

 

I have a MacMini Intel with a geforce video card, all work using "Wine"

 

great !

[Tursi]

Nice!

 

I've made a small update today, too, version 358. I dug into the clipboard formats used when you copy and paste from IE, and made it work properly again by parsing the RTF data (which is the only version that includes line endings now!) It's hacky, but copy and paste from the forums seems to work well again.

 

http://harmlesslion.com/software/classic99

[RXB]

Thanks wondered why my cut and past from the Forums was broken.

[sometimes99er]

Classic99 357

 

Okay, so I remove the old "src" directory and "install" (unzip). I go to the "src" directory and double click the "classic99.vcxproj" file. Tries to "build solution" (F6), and gets error:

MSB6006: "cmd.exe" exited with code 1.

 

File "classic99.log" has:

Build started 21-07-2011 14:15:02.

1>Project "C:\classic99\src\classic99.vcxproj" on node 2 (build target(s)).

1>InitializeBuildStatus:

Creating ".\Debug\classic99.unsuccessfulbuild" because "AlwaysCreate" was specified.

CustomBuild:

Performing Custom Build Tools

'nasm' is not recognized as an internal or external command,

operable program or batch file.

1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB6006: "cmd.exe" exited with code 1.

1>Done Building Project "C:\classic99\src\classic99.vcxproj" (build target(s)) -- FAILED.

Build FAILED.

Time Elapsed 00:00:00.06

 

Any ideas ?

[Tursi]

Let's see what I can do - you're the first one to try it! (I did try in a separate folder, but that's no guarantee).

 

Okay, so I remove the old "src" directory and "install" (unzip). I go to the "src" directory and double click the "classic99.vcxproj" file.

 

Open the Classic99.sln solution file, I'm not sure that all the settings will come if you open the proj files directly.

 

Performing Custom Build Tools

'nasm' is not recognized as an internal or external command,

operable program or batch file.

 

Just like it says here (but nowhere in my documentation), you need to have nasm installed. nasm is an assembler and it's used to build the 2xSAI filters. http://www.nasm.us/ -- it needs to be in your path -- the custom build command is on the SXSAIMMX.ASM file in the Classic99 project. You'll see it calls a batch file with the actual command.

 

It's only nasm because that's what the filter was originally built for, and I never bothered trying to port it to the MS assembler. My machine has nasm version 2.07, which is fairly old.

[sometimes99er]

Thanks.

 

A google for 'nasm' returned just that. I should have looked just a little further to see the 2xSAI filter connection. Compiles fine with 2.09.10 (latest stable version).

 

I've tried and compile a few times in the past, but had myriads of missing files and what not. Wouldn't wanna bother you with my incompetence. Last time I did try and pass some of the errors only too often generating even more.

 

Got this error:

LINK : fatal error LNK1181: cannot open input file 'dxguid.lib'

 

From what I gather, I need to install, which is fine, MS DirectX SDK. That's a freaking 572 MB download.

 

Though apparently at a steady 245 KB/s, that's probably more than half an hour. I'll return later ...

 

[+OLD CS1]

From what I gather, I need to install, which is fine, MS DirectX SDK. That's a freaking 572 MB download.

 

Though apparently at a steady 245 KB/s, that's probably more than half an hour. I'll return later ...

 

 

I am surprised that does not use a download manager. Personally, I like DownloadThemAll in Firefox, which will open up to 10 connections for a download, provided the server is amenable.

 

And 572MB in half-hour? Why, when I was a kid we downloaded 22k in around an hour and we were happy to do it! (Shakes fist)

[Tursi]

A google for 'nasm' returned just that. I should have looked just a little further to see the 2xSAI filter connection. Compiles fine with 2.09.10 (latest stable version).

 

Don't feel bad. I knew it was NASM, but it took me about 20 minutes to figure out where the build command was hiding so I could prove it. I should just port it to the MS assembler.

 

I've tried and compile a few times in the past, but had myriads of missing files and what not. Wouldn't wanna bother you with my incompetence. Last time I did try and pass some of the errors only too often generating even more.

 

Not your incompetance at all. This is the first source release in probably 5-6 years that includes the ROM files. Some years ago, without talking to me, a fellow published a book on retro gaming which instructed people to download Classic99, then copy out the ROM files for use with MESS. Needless to say, that didn't impress me. So I removed the ROMs from the source archive. That combined with the utter mess that the source tree had become made it very difficult to figure out how to build it.

 

I hope that everyone will note that the license does not permit unauthorized derivative works to be published, though.

 

From what I gather, I need to install, which is fine, MS DirectX SDK. That's a freaking 572 MB download.

 

Yeah, I can't help you much there... sadly it is needed.

 

I am surprised that does not use a download manager. Personally, I like DownloadThemAll in Firefox, which will open up to 10 connections for a download, provided the server is amenable.

 

Personally, I'm not a fan of either of those techs. Download managers are a pain - I don't need more software lurking resident in my system, ready to pop up and take control at any time (not to mention the possibility of exploit and the fact that every site wants to use their own download manager). The multiple connections for download are also pretty hard on small servers like mine -- and in my case won't run any faster either, since I don't throttle by connection. (I'm surprised the MS download is so slow, though, I've gotten megabytes per second when my link supports it from MSDN.)

[sometimes99er]

I knew it was NASM, but it took me about 20 minutes to figure out where the build command was hiding so I could prove it.

Oh, "contents:nasm" in the search box of Windows 7 Explorer should locate the file in no time.

 

Well, VS "edit/find & replace/find in files" does that too.

Edited July 22, 2011 by sometimes99er

[Tursi]

The build command in the project? I have no problem finding my dev tools, I use them daily.

[sometimes99er]

The build command in the project? I have no problem finding my dev tools, I use them daily.

Probably yes and no, finding names and locations of files that uses the command nasm - which in the end then turns out to be compile.bat. Never mind.

 

[Tursi]

Probably yes and no, finding names and locations of files that uses the command nasm - which in the end then turns out to be compile.bat. Never mind.

 

I know you're trying to be helpful.. but finding compile.bat still wouldn't have told me where it was being called from, it just would have told me I was looking for compile.bat instead of nasm.exe

 

Probably I should just never have admitted it took me a while. Especially since there's only one assembly language file in the whole project.

[sometimes99er]

 

Oki doki. Sometimes things just take time. Now this one took two cups of coffee. Sometimes the best way to learn is the hard way - and sometimes you're just kinda lucky (like: I don't understand, it worked fine the first time around).

 

Let's see ... First of all I get:

error LNK1181: cannot open input file 'dxguid.lib'

related to the classic99 project.

I find the file in

C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)

I google and try different things with the project Property Pages, Configuration, VC++ Directories. I then install a DirectX Sample, DynamicShaderlinkageFX11 (June 2010), and find $(DXSDK_DIR)Include in the Include Directories and $(DXSDK_DIR)Lib\x86 in the Library Directories. I add these. And then I get:

error LNK1181: cannot open input file 'ddraw.lib'

I can't actually believe that, but that file is not on my computer.

Looks like the deprecation of DirectDraw and the drop of VS2005 support in the DirectX SDK (June 2010) left the ddraw.lib behind and you have to do some LoadLibrary and GetProcAddress dance to get them functions now.

http://blogs.msdn.com/b/chuckw/archive/2010/06/16/wither-directdraw.aspx

Well, later ...

 

Edited July 23, 2011 by sometimes99er

[Tursi]

hmm. I have the August 2009 SDK installed, so I guess that's possible. Maybe I should just update the interface and call it good.

 

I believe this is the August 2009 DXSDK download link, however, I don't like recommending people to download older software, so I will say do it if you must. http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=23549

 

Thanks for going through all this, Sometimes99er, it helps me identify what I need to look at.

[sometimes99er]

Maybe I should just update the interface and call it good.

Do you mean dropping the use of ddraw.lib ?

 

 

 

I'm not too happy about the above (08.2009). I tried and reboot to maybe free the resource, but the same warning comes up. Haven't googled this one, but I'll leave it for now (won't force older versions, as I think it may mess things up badly now or later).

 

Before installing (the huge) DXSDK (06.2010), I thought about copying and pasting a few small lib, h and dll files into a hack directory and add the path, and see how it works. I'll try this later (regarding the ddraw), unless you know it's a dead end ?

 

Edited July 24, 2011 by sometimes99er

[Tursi]

Maybe I should just update the interface and call it good.

Do you mean dropping the use of ddraw.lib ?

 

Yeah. You're supposed to run everything through Direct3D these days. I've known this for a while but didn't expect DirectDraw to be actually removed.

 

I not too happy about the above (08.2009). I tried and reboot to maybe free the resource, but the same warning comes up. Haven't googled this one, but I'll leave it for now (won't force older versions, as I think it may mess things up badly now or later).

 

Weird... and agreed - don't force it.

 

Before installing (the huge) DXSDK (06.2010), I thought about copying and pasting a few small lib, h and dll files into a hack directory and add the path, and see how it works. I'll try this later (regarding the ddraw), unless you know it's a dead end ?

 

I've no idea!

 

I don't know if this will work, or if the result will run, but I'll post my Include and Lib\x86 folders to see if that is enough to help. You'll have to manually set the include and library paths, of course. I had to use two files here because combined was /slightly/ more than the 2MB upload limit, and this board refuses to accept RAR which was small enough.

 

DXSDK Aug09 Include.zip

DXSDK Aug09 Lib.zip

[sometimes99er]

Well, it is apparently possible to bypass the error (ddraw.lib) as described. Then I tried to bypass the following errors using the same method of finding the correct file and adding the path. I guess the search tree is fine (from left to right), but I was beginning to suspect spaghetti anyway. I'll have another go later.

 

[RXB]

Using GPL@LOADER after setting the check mark to indicate the GRAM is locking up quite often.

 

The only thing that has changed is I am running Window 7 instead of XP and QI358 Classic99

 

I have to shut down and restart Classic99 almost every other time I load GRAM, this never happened in XP very often. Now it is really annoying.

 

I am running it under Windows7 and as Administrator and under XP SP3 ?

 

I even deleted another User account just to see it that was the problem. Any ideas as this is a fresh install of Window7?

[Tursi]

Using GPL@LOADER after setting the check mark to indicate the GRAM is locking up quite often.

 

The only thing that has changed is I am running Window 7 instead of XP and QI358 Classic99

 

I have to shut down and restart Classic99 almost every other time I load GRAM, this never happened in XP very often. Now it is really annoying.

 

I am running it under Windows7 and as Administrator and under XP SP3 ?

 

I even deleted another User account just to see it that was the problem. Any ideas as this is a fresh install of Window7?

 

No ideas. Give me some details about the lock up.

 

1) Is it Classic99 or the TI that is locked up?

2) Do menu options work at all? (ie: File->Reset)

3) Can you post the file(s) you are loading and a step-by-step reproduction (even if it takes a few tries to happen)?

4) If Classic99 is still working, while it it hung load the debugger and copy/paste all the details out of the log

 

If I can't reproduce it, I can't fix it, so give me as much as possible. I haven't seen or heard of any other lockups, but everything about the Classic99 underlying framework is new and I am not using it daily at the moment.

[RXB]

Using GPL@LOADER after setting the check mark to indicate the GRAM is locking up quite often.

 

The only thing that has changed is I am running Window 7 instead of XP and QI358 Classic99

 

I have to shut down and restart Classic99 almost every other time I load GRAM, this never happened in XP very often. Now it is really annoying.

 

I am running it under Windows7 and as Administrator and under XP SP3 ?

 

I even deleted another User account just to see it that was the problem. Any ideas as this is a fresh install of Window7?

 

No ideas. Give me some details about the lock up.

 

1) Is it Classic99 or the TI that is locked up?

2) Do menu options work at all? (ie: File->Reset)

3) Can you post the file(s) you are loading and a step-by-step reproduction (even if it takes a few tries to happen)?

4) If Classic99 is still working, while it it hung load the debugger and copy/paste all the details out of the log

 

If I can't reproduce it, I can't fix it, so give me as much as possible. I haven't seen or heard of any other lockups, but everything about the Classic99 underlying framework is new and I am not using it daily at the moment.

 

No Classic99 just locked up and I have to close it. Using any of the options above do nothing even the reset. The pop down menu do nothing even the Reset. Closing Classic99 is only way out of lock up.

 

Now I have been using the Debugger screen so maybe that has something to do with it as Classic99 never locked up before like this till I have started to use the Debugger.

I am setting GROM Breakpoints to see the scratchpad and see the values of the variables. Also compare the VDP to those values.

 

That means the Debugger has to be the problem I think, as I exit what I am doing by reset or reset scramble RAM and then use GPL Assembler to make a Object file then back to GPL@LOADER and sometimes it locks up while loading GRAM.

 

So the lock up is always after I have used the debugger but is pretty random about when the GPL@LOADER locks up the Classic99. I think it is some kind of memory conflict in the GRAM with the DEBUGGER. like something is still there or set up.

 

You know I may be causing it unkownly by the way I exit the debugger. I was exiting by just reset and going back to what I was doing, but if I clear the breakpoints and get back into the GPL program I am running and exit that way there is no problems.

Edited July 28, 2011 by RXB

[RXB]

Ok got a lock up and the dump worked.

 

OK LOL it is locked up at GC42C and stuck trying to load that GROM address. That address is part of the GROM sound list.

 

UPDATE: REWROTE GPL CODE SO IT HAS NO SOUND ROUTINE CALLED AT ALL BUT STILL LOCKS UP ON GC42C

 

Also reinstalled Classic99 and it still does it. I end up at GC42C even though I are not accessioning that address in any way.

 

It appears the Debugger wants to go there no matter what is being done. Even clearing the break point does not fix it.

DUMP.zip

Edited July 28, 2011 by RXB

[Tursi]

Please don't attempt shotgun approaches to solving it.. just collect as much data as you can. I've used the debugger a heck of a lot, even for GPL debugging, so you are not the first person in uncharted territory.

 

Your descriptions are somewhat confusing. You say that Classic99 itself locks up, but you can still select from the menus. That would not be the case if the emulator itself had locked up. Neither would closing the emulator without killing it from task manager. This means that the Windows code is still running.

 

It can't lock up at GROM addresses, it doesn't execute GPL code. The CPU code executes GPL code, and as long as the CPU is running, the emulator is working. So you need to focus on that side of things for debugging. Remember that settings a read breakpoint on GROM is /any/ read, the emulator can't tell the difference between GPL reads and data reads. You could simply be getting into a crash loop that's reading memory sequentially.

 

I'm not at a point of understanding the issue where a memory dump will be helpful yet - this is just a dump of the CPU's 64k space and the VDP's 16k. I need a copy of the debug log to see if anything strange is happening. It's just text, you can copy and paste it.

 

All that said, so far your descriptions lead me to believe that you've simply got a frozen CPU. This could be because the system is breakpointed, and it could be because a bug has set the CPU speed to 0. Next time it happens, try these steps in order and capture the screens for me (press Alt-PrintScreen, then load MSPaint and select Edit->Paste - save the picture and upload).

 

1) Check the title bar of the main window - does it say 'Classic99' or 'Classic99 - Breakpoint'? Capture this screen.

1a) If it shows a breakpoint, that's why it's not running. Make sure Scroll-Lock is on on the keyboard, and press F1 to continue.

1b) If it does not continue, open the debugger window (if needed) and remove any listed breakpoints, then try again

 

2) If the above fails or it does not say breakpoint, select Options->Options from the menu. Capture this window. Make sure that the "CPU Tuning" slider is centered at 100%, then click OK.

 

Let's see if that helps.

 

One thing I will warn - there are bugs in the TI Boot ROMs that will sometimes hang the system if you use File->Reset-Scramble RAM. Again, this is the TI hanging, not the emulator. You may have to use it more than once in that case. Basically, certain values in certain scratchpad locations can hang the interrupt function, which sometimes gets a chance to run before they are initialized. It's still a useful function, you just have to be aware of that (if the title page comes up, you are okay). (Actually, it can trigger a Munchman bug too, where you can never finish the level ).

[RXB]

Please don't attempt shotgun approaches to solving it.. just collect as much data as you can. I've used the debugger a heck of a lot, even for GPL debugging, so you are not the first person in uncharted territory.

 

Your descriptions are somewhat confusing. You say that Classic99 itself locks up, but you can still select from the menus. That would not be the case if the emulator itself had locked up. Neither would closing the emulator without killing it from task manager. This means that the Windows code is still running.

 

It can't lock up at GROM addresses, it doesn't execute GPL code. The CPU code executes GPL code, and as long as the CPU is running, the emulator is working. So you need to focus on that side of things for debugging. Remember that settings a read breakpoint on GROM is /any/ read, the emulator can't tell the difference between GPL reads and data reads. You could simply be getting into a crash loop that's reading memory sequentially.

 

I'm not at a point of understanding the issue where a memory dump will be helpful yet - this is just a dump of the CPU's 64k space and the VDP's 16k. I need a copy of the debug log to see if anything strange is happening. It's just text, you can copy and paste it.

 

All that said, so far your descriptions lead me to believe that you've simply got a frozen CPU. This could be because the system is breakpointed, and it could be because a bug has set the CPU speed to 0. Next time it happens, try these steps in order and capture the screens for me (press Alt-PrintScreen, then load MSPaint and select Edit->Paste - save the picture and upload).

 

1) Check the title bar of the main window - does it say 'Classic99' or 'Classic99 - Breakpoint'? Capture this screen.

1a) If it shows a breakpoint, that's why it's not running. Make sure Scroll-Lock is on on the keyboard, and press F1 to continue.

1b) If it does not continue, open the debugger window (if needed) and remove any listed breakpoints, then try again

 

2) If the above fails or it does not say breakpoint, select Options->Options from the menu. Capture this window. Make sure that the "CPU Tuning" slider is centered at 100%, then click OK.

 

Let's see if that helps.

 

One thing I will warn - there are bugs in the TI Boot ROMs that will sometimes hang the system if you use File->Reset-Scramble RAM. Again, this is the TI hanging, not the emulator. You may have to use it more than once in that case. Basically, certain values in certain scratchpad locations can hang the interrupt function, which sometimes gets a chance to run before they are initialized. It's still a useful function, you just have to be aware of that (if the title page comes up, you are okay). (Actually, it can trigger a Munchman bug too, where you can never finish the level ).

 

Tursi sorry, when it locks up the menus are there, and you can select them as drop downs, but nothing happens, reset does nothing. I have to close the window manually.

 

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.

 

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.

 

And thanks for the help.

 

Rich

[RXB]

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

StuckGPL.zip