Classic99 Updates

[Tursi]

I've definitely left it running for extended periods, so I need a little more information.

 

When it's locked up - is it the emulator that is locked up or the TI inside the emulator? For instance, do the menus still work?

 

Can you open the debugger, and leave it open to see if anything is printed when it hangs?

 

What is the TI side doing at the time that it hangs?

 

What's your host OS?

[Retrospect]

I've definitely left it running for extended periods, so I need a little more information.

 

When it's locked up - is it the emulator that is locked up or the TI inside the emulator? For instance, do the menus still work?

 

Can you open the debugger, and leave it open to see if anything is printed when it hangs?

 

What is the TI side doing at the time that it hangs?

 

What's your host OS?

I've left the emulator running for nearly three hours now and so far it's not locked up, typical when you want it to lock up it won't.

When it did lock though, on both occasions I could not access the menu's at all and literally had to close the app and relaunch. Hence couldn't open debugger.

At the time when it hangs, I suspected the TI was going into that thing where the screen goes blank after not touching it for a while (however it has since done this and not locked)

My host OS is Windows 7 Ultimate Edition, 32-bit, running on an RM-One ex-school computer.

[RickyDean]

Have you run tests on the computer to be sure there is not a memory issue happening? I have experienced, in the past similar things happening on programs of different types on a pc, to find out I had a memory chip failing or something. just putting out some other possibilities.

[Retrospect]

Have you run tests on the computer to be sure there is not a memory issue happening?

I've not run any such tests to test the actual PC yet, but I can confirm, that the entire PC can lock-up at random when running the GIMP photo editing application, but it never, strangely ever, locks up during any Classic99 session. The only thing that's locked is Classic99 itself.

 

I'm still running Classic99 now, it's been on over four hours, and i'm waiting to see if Classic will lock up again, and if it does, if I can access the debugger to give Tursi some more information on the cause of the lockup. It's worth noting the previous release of Classic99 didn't ever lockup on me. Other than that, is all the info I have thus far.

 

If it does lock, I'll try for debugger and then try again running under different settings, for example I'm currently using the TV Emulation setting. I've never used Throttle on this version yet though so I'm having a different kind of issue to other people

[Tursi]

Please open the debugger /before/ it hangs. Since you can't access the menus, waiting until it hangs to try and open it won't really do any good.

 

I ran Classic99 for 8 hours when I went to bed without any issues -- and I've run long tests many times. I was running Demonstration this time -- what was the TI in your Classic99 running when it hung? Don't get hung up on the screen blank, that's just a jump and an extra bit set in the VDP on the TI side, it's not a different emulation state.

 

The TV mode is a good hint, I'll leave that up. I didn't write the TV filter.

[Tursi]

I let mine run today in Extended BASIC for 12 hours, with the TV filter on, monitoring for memory and handle leaks, and it came through clean.

[Tursi]

The current game competition, Flying Shark, made me take a look at why Classic99 runs too fast sometimes. Tracked it down to the mid-instruction VDP updates I added when the status register was read - the cycles used till that point were counted against the VDP credit twice - so the more often you read the VDP status, the faster it would go.

 

Released 399.003 - lots of room for versions now!

• fiddled with AVI audio, but no improvements. AVIs updated to 60hz otherwise.
• fix strange speedups - code that read the VDP status register was giving about 50% bonus cycles to the VDP. The more often you read it, the faster you went
• change waitable timer to a smaller value
• remove the forced time on CPU_MAXIMUM. Now it actually runs maximum speed. And stays in sync.
• add some comments to remind myself what the heck I was thinking in the 'full frame' update for overdrive

http://harmlesslion.com/software/classic99

[1980gamer]

i am having an issue with running the newest version under windows 10.

1. AVG virus scan does not trust the file.

2. when I okay the file and allow it to run, I get a windows error. Windows cannot access the Device, Path or Access the file.

 

I downloaded 3 times. The prior version works fine. I re-extracted and no problem.

 

I did get it to run once. but cannot repeat that.... Back to prior version for now.

[+OLD CS1]

1. AVG virus scan does not trust the file.

What version of AVG are you running? Which scan is catching it? From what directory are you running the program?

 

EDIT:

 

VirusTotal scan of full archive

 

VirusTotal scan of classic99.exe

[jrhodes]

The current game competition, Flying Shark, made me take a look at why Classic99 runs too fast sometimes. Tracked it down to the mid-instruction VDP updates I added when the status register was read - the cycles used till that point were counted against the VDP credit twice - so the more often you read the VDP status, the faster it would go.

 

Released 399.003 - lots of room for versions now!

• fiddled with AVI audio, but no improvements. AVIs updated to 60hz otherwise.
• fix strange speedups - code that read the VDP status register was giving about 50% bonus cycles to the VDP. The more often you read it, the faster you went
• change waitable timer to a smaller value
• remove the forced time on CPU_MAXIMUM. Now it actually runs maximum speed. And stays in sync.
• add some comments to remind myself what the heck I was thinking in the 'full frame' update for overdrive

http://harmlesslion.com/software/classic99

 

2nd best feature of classic99 ever (1st goes to CS1 support)

[atrax27407]

Are you sure it isn't WINDOWS DEFENDER that is causing the problem? Because it is a new program, there will usually be a "history" exception.

[Tursi]

i am having an issue with running the newest version under windows 10.

1. AVG virus scan does not trust the file.

2. when I okay the file and allow it to run, I get a windows error. Windows cannot access the Device, Path or Access the file.

 

I downloaded 3 times. The prior version works fine. I re-extracted and no problem.

 

I did get it to run once. but cannot repeat that.... Back to prior version for now.

This sounds like your AV is not allowing the exception, or Windows isn't allowing it to run from the folder you've dropped it in...

 

I develop and test on Windows 10, so it's not a Windows 10 specific issue.

 

It's going to be a different program to your AV compared to the older version, so previous exceptions won't apply.

 

The one detection that pops up on the VirusTotal page is because I pack the EXE with UPX. It doesn't cause a many problems but it seems to occasionally catch someone's system. Unpacked the EXE is only 3MB, today that's not huge. Maybe I should stop packing it?

[Asmusr]

I find that in the latest Classic99 version Flying Shark is running unevenly at normal speed. Sometimes you rush ahead as if waiting for vsync is not working. The scrolling pace should be one screen update for every 4 vsyncs.

[1980gamer]

Windows Defender pops up first, but I say Run Anyway.

 

Then AVG scans it and ultimately says, no virus found and Classic opens.

 

Today running it, I did not see a problem. However, when I closed notepad and classic99, I had this message in the background. See Attached...

 

I was able to create an exception.

 

However, I never had to do that prior.

 

I have the past 4 versions all in the same folder. I just pull the exe into the folder.

 

 

It seems to be working now... Just strange, the prior version didn't do this. I haven't actually used the latest beyond having it actually load.

If I see any actual Classic99 issues, I'll let you know. I am a heavy user of overdrive.

 

 

 

[Tursi]

I can't help with Windows Defender or AVG issues...

[Tursi]

I find that in the latest Classic99 version Flying Shark is running unevenly at normal speed. Sometimes you rush ahead as if waiting for vsync is not working. The scrolling pace should be one screen update for every 4 vsyncs.

That's strange since Flying Shark was doing that /before/ I made the changes, and was my benchmark for deciding I fixed it If you enable 'show FPS', does the FPS counter change with the speed changes?

[Tursi]

Just ran a test here and got to 25,600 pts, up into the battleships, and didn't notice any speed changes, music was solid the whole time. I was firing pretty rapidly and that seemed to slow things down a bit, but what specifically should I be looking for?

[1980gamer]

Tursi, I know you cannot do anything about Windows defender or AVG.

 

It seems as though a pattern in the code may match other viruses. I had this happen to me in the past when we sent out updates to customers causing false positives and quarantining the exe.

It can be a real pain.

 

It was just strange. I re-extracted they prior version and did not get the W.D. or AVG messages.

[Asmusr]

That's strange since Flying Shark was doing that /before/ I made the changes, and was my benchmark for deciding I fixed it If you enable 'show FPS', does the FPS counter change with the speed changes?

 

On my computer with normal CPU throttling the FPS is changing all the time between values in the interval 45 to 85. In overdrive mode it's steady at 62 FPS and Flying Shark is also running at an even pace. I don't actually know if this is related to the latest update.

[Retrospect]

I let mine run today in Extended BASIC for 12 hours, with the TV filter on, monitoring for memory and handle leaks, and it came through clean.

I ran it for 8 hours the other day, in Ext.Basic, with my notepad open and magellan open. The cursor was still winking at me after those 8 hours so I'm putting it down to something my PC has done rather than say a fault with the emulator. For what its worth info-wise, this particular PC runs Fuze Basic badly, as it randomly quits the app when I click "edit" .. I'm thinking maybe it's buggering up the Classic99.exe at random. Time for a new PC.

Edited September 9, 2018 by Retrospect

[+OLD CS1]

Tursi, I know you cannot do anything about Windows defender or AVG.

 

I can submit the program to AVG/Avast, but the problem is the detection cannot be reproduced with the latest version (18) and the definitions as of the original report.

[Tursi]

On my computer with normal CPU throttling the FPS is changing all the time between values in the interval 45 to 85. In overdrive mode it's steady at 62 FPS and Flying Shark is also running at an even pace. I don't actually know if this is related to the latest update.

Hm. Not much to go on... but in overdrive it turns off the scanline-based VDP, so it's doing less work. I wonder if it's not keeping up - is the host CPU pinned while its fluctuating? If it falls behind on expensive frames it will try to catch up on easier ones, up to 10 frames. That's fine for a one-off but doesn't do any good if it's consistently behind.

[Retrospect]

Hi Tursi, Classic "locked" again just now, not a proper lock though as I had access to the menu this time and so I took 3 screenshots of the debugger.

 

You'll see one of the shots shows a blank debugger and then afterwards it decided to show some info.

 

Most curious.

 

It was the TI itself that had locked. Pressing Fire or any of the keys didn't correspond. This was during a game I had written.

 

 

[RXB]

This looks very much like a Buffer or memory leak of the OS or possibly hardware.

My MacPro did this from time to time with Classic99 and TIDir99...

 

The solution turned out to be me switching 1 of the 1 Gig Memory sticks of RAM in the MacPro.

Moving that 1 Gig Stick to upper page not used often fixed this issue.

I had 6 of these 1 Gig sticks of memory so it has no trouble to me since then.

 

 

This was suggested by Apple when I asked about this issue, tests run showed one stick was rarely flaky and was the one I moved to upper slot.

Edited September 11, 2018 by RXB

[Tursi]

Well, you can see a full loop in the debugger there... from 15EC though 1608. The only way out of the loop is: cb *r10,r3, jeq >160e.

15EC inc R4 -- currently at >35F1

15ee movb @>83e9,*r15 -- reads a byte from R4 LSB into >8c02, VDPWA

15f2 jmp >15f4 -- NOP

15f4 movb r4,*r15 -- writes the MSB of R4 (currently >35) to VDPWA, address now >35F1

15f6 li r10,>8800 -- load VDPRD to R10

15fa cb *r10,R3 -- compare VDP byte to >03, and increment address

15fc jeq >160e -- loop's only exit

15fe movb *r10,r6 -- read from VDP and copy to R6, got >35

1600 jmp >1602 -- NOP

1602 movb *r10,@>83ED -- read from VDP and copy to R6 LSB, got >F0

1606 mov R6,R4 -- copy read value to R4

1608 jmp >15ec -- loop around

So, this loop sets the value in R4 to the VDP address, looks for a >03. If it's >03, then it exits the loop, otherwise it reads the next two bytes and uses them to set the next VDP address. Note that in this case, that first byte (which was not >03) is discarded. You're currently at >35F0.

Doesn't look like an emulation issue, though...