Classic99 Updates

[globeron]

I had this issue long ago with real analog joysticks on a Sound Blaster game port, but it went away for me with USB. The problem (likely) is that Classic99 polls the joystick API way more often than it should (for every CRU request!), and so if the driver is slow, doesn't buffer, or needs delays, that can have an impact. The impact would be worse on some titles than others depending on how much they read. There's no fix for it right now save trying a different joystick, but it's educational to learn it still impacts people, it sort of fell off my radar to fix.

 

Okay let me try to look into it -> the drivers that might be the issue (as it is using Windows 10 drivers now) and

trying to find the original Joystick drivers. I will try different PCs and let you know the result asap. I tried to run Classic99 in "Windows 7 compatibility mode" but did not help.

[+Schmitzi]

Hi,

 

in Classic99 I want to SAVE DSK1.MYFILE but I get an ERROR 63... Any ideas ? (my DSK-File is mapped)

 

I remember there was something about write-protection but this is UNchecked (in the window where I map my DSK-File)

and I cannot find back what I saw months ago

 

Thx for any answer

 

xXx

[+Lee Stewart]

Hi,

 

in Classic99 I want to SAVE DSK1.MYFILE but I get an ERROR 63... Any ideas ? (my DSK-File is mapped)

 

I remember there was something about write-protection but this is UNchecked (in the window where I map my DSK-File)

and I cannot find back what I saw months ago

 

Thx for any answer

 

xXx

 

If you are using a DSK image, I believe only sector writes will work—other writes throw an error. I think you can invoke the TI controller for a specific DSKn by changing the type to Type=3 under that DSKn's heading in the classic99.ini file.

 

...lee

[+Schmitzi]

Hi Lee, thanks, I will try that. I found a quick workaround for now, I made DSK2 to FIAD, saved my file there,

and replaced it with Fred´s TI99DIR in the original DSK-File - Not the optimal way, but worked.

But I have to check that out with directly writing to DSK, I could use that every day...

 

thanks

xXx

[+Schmitzi]

Yes, TYPE=3 works I try to enter that fix for all my drives now, as I work with DSKs only

++thx

[+Lee Stewart]

Yes, TYPE=3 works I try to enter that fix for all my drives now, as I work with DSKs only

++thx

 

Cool! I usually do try to use FIAD when I can. I remember pushing @Tursi regarding the sector writes for TI Forth because there is no way to use FIAD for TI Forth—it uses only sector read/write for Forth blocks.

 

...lee

[+Vorticon]

I thought Tursi had fixed the disk issue with the latest Classic99 update...

[+Schmitzi]

ah OK. I have v386, will update to v388 soon. thanks

[Tursi]

It's not an issue, I deliberately don't write to DSK images for normal file access.

 

If you used the TI controller workaround be aware that your image is limited to 180k images (larger ones should not even be attempted) and only DSK1 through DSK3.

[globeron]

Today tested the v388 version, with F18A graphics in TI-Scramble, all looks good ! (thanks Rasmus/Tursi)

[Tursi]

Updated to 389:

 

•fix two bugs in 379 cartridge make code - one would not detect the size of carts that bumped right up against an 8k boundary, and the other wrote the wrong jump address to the startup code (file that under 'how did it ever work?').

•add menu option to erase UberGROM contents (for testing)

•add a hack for programs that require the 5th sprite number to count up during frames when 5S and F are reset (Miner2049er - may have been in previous release)

•fix a "Paste XB" bug that would incorrectly collapse spaces used as PRINT separators

 

http://harmlesslion.com/software/classic99

[ti99iuc]

Thank you !!

[Davvel]

Tursi,

 

Is there a way where I can call Classic 99 from command line (No GUI) and immediately execute a TI 99 program.

 

The main aim is to have a windows application call classic99 and immediately start a predefined TI application and when the TI app is done it closes off Classic 99 completely and return back to the windows app. The main aim here is to facilitate the test cycle when you would need to iteratively reload your game/app on every small change you do to your code/game attributes.

 

Thanks.

 

David

[globeron]

Classic99 TI-99/4A on an Intel Compute Stick: https://www.youtube.com/watch?v=ZQT-RYf74Zo

[Tursi]

Tursi,

 

Is there a way where I can call Classic 99 from command line (No GUI) and immediately execute a TI 99 program.

 

The main aim is to have a windows application call classic99 and immediately start a predefined TI application and when the TI app is done it closes off Classic 99 completely and return back to the windows app. The main aim here is to facilitate the test cycle when you would need to iteratively reload your game/app on every small change you do to your code/game attributes.

 

Thanks.

 

David

Use Classic99Paste.exe to paste a startup string - that's what I use in my makefiles.

 

I never close Classic99, this utility can request a cold reset before pasting so that it starts fresh.

 

(although I admit it might not be working right, I noticed the other day that it wasn't doing what I expected, but I haven't

had a chance to see why yet.)

 

You can also pass a cartridge filename on the command line with the "-rom" option. Just pass one of the files - it works the same way as cartridge->user->open from the menu. It won't autostart it but carts are only two keypresses away.

 

classic99.exe -rom munchmanG.bin

 

classic99paste.zip

[ColecoFan1981]

I want to submit a palette revision for this emulator, please. What I did was to change the color saturation to 51 percent so none of the RGB voltage values go beyond 1.00 (255).

 

Please see attachment for exact details.

 

Thank you,

 

 

 

Benjamin "Ben" Edge

Edited March 27, 2016 by ColecoFan1981

[ColecoFan1981]

I want to submit a palette revision for this emulator, please. What I did was to change the color saturation to 51 percent so none of the RGB voltage values go beyond 1.00 (255).

 

Please see attachment for exact details.

 

Thank you,

 

 

 

Benjamin "Ben" Edge

I forgot to add that the original values were taken from the TMS9118 series datasheet.

 

~Ben

[Tursi]

Thanks Ben. I haven't really changed my stance from when we last talked about this a few years ago, but I'll save the values off for later consideration. Eventually I will probably add a palette select, since I have a half-dozen available. (Or people can just run TV mode and tweak the contrast, brightness, and hue, like real life. )

[Tursi]

People have been asking for ports for a long time, but I was never terribly interested in most of the systems people wanted me to port to. But I realized that there is a system I like enough to port to, so I'd like to offer up this beta of Classic99 for the TI-99/4A.

 

 

Also works in emulation, tested in Classic99, MESS and JS99er. Download and run here.

 

classic99forTI.zip

 

Response will determine how much farther I take it.

[RXB]

You should be able to use REA 2015 right?

[Asmusr]

People have been asking for ports for a long time, but I was never terribly interested in most of the systems people wanted me to port to. But I realized that there is a system I like enough to port to, so I'd like to offer up this beta of Classic99 for the TI-99/4A.

 

Very nice, makes debugging on real iron so much easier.

[Willsy]

Ha! Hilarious!

[+OLD CS1]

Tursi has proven you can divide by zero!

 

Well, maybe not, but still kind-of mind-bending. Like BITD when I saw an Amiga 3000 running a Mac emulation running a Windows emulation running an Amiga emulation.

[Tursi]

Brief chat about the tech, as I did hit some surprises while I was on it.

 

The intent with this hack was to force the display of the Classic99 banner no matter what was running. To do this, a few steps were necessary.

 

The first was that I needed a way to get control of the system, while letting other programs run. I used the user interrupt hook for this -- without ROM modifications or hardware there really isn't any other way. I then had the hook display the banner at the top of the screen each frame. That wasn't perfect, applications could overwrite it, BASIC scrolling would lose it, and basically it vanished a lot.

 

But I wanted to move on to the biggest challenge - how to KEEP control. I knew that the user interrupt hook would be called EVERY TIME for a FCTN-= reset, and most times for other resets, including hardware. The user interrupt hook itself is cleared very late in the initialization, and from GPL, which guarantees interrupts are enabled. The FCTN-= guarantee happens because of a small bug in the ROM -- FCTN-= is checked during the VDP interrupt, but the console is reset before the interrupt is cleared, which means as soon as there's another LIMI 0, the interrupt will fire again. This happens on the first GPL instruction, long before the scratchpad RAM is cleared. (The 'most of the time' for the others is just because it takes the GPL code a bit of time to do all the initialization. Classic99 suggests it can be less than a frame, but you have a good chance of the VDP somewhere in the middle of the screen, so less than a full frame till the next interrupt.)

 

So I knew I could get control, but then what? I need to return eventually! I decided that I would replace the console initialization code up until just after the VDP RAM check with assembly code, then I could just jump back into the GPL interpreter and let it run. This let me preserve my interrupt hook -- as well as know when to reset any state data.

 

To determine this, the interrupt hook just reads back the current GROM address. If it's in the startup range, I run my init code instead.

 

It gave me one other feature, I could control where the top of VRAM was, even before the disk controller allocated any. I moved the top of video RAM from >4000 to >3800, giving me lots of video memory that I didn't end up using after all. Except for one thing - I moved the Screen Image Table from >0000 to >3800. Any program that played nice with the TI pointers would never touch it, disk and TI BASIC still worked fine, and I could preserve my banner as well as get a screen 'paint' effect by copying just a few rows per frame from the real screen at >0000.

 

The next issue was dealing with the character offset in TI BASIC. I originally wanted to use my own character set, or normally unused characters, which was part of why I reserved so much VDP memory (another reason is simply limits on where the SIT can be placed). But I wimped out on that and just went with the normal character set, except that I redefined the tilde to be my banner bar. So, I needed to know when BASIC was active so I could use the correct characters in the banner. Since I already had a GROM address, I just added a check for the TI BASIC GROM addresses, and just set a flag. That flag is cleared in the init routine to reset it.

 

This was working reasonably well, but my success rate on maintaining reset, even FCTN-=, was roughly 50%, which wasn't quite good enough. I needed to hunt a bit, but finally I figured out why. This was where I learned that the GPL init can be fast enough to beat a VDP frame... when the console boots, it first starts in a jump table at the start of GROM, and THAT jumps to the real startup code. Since the jump table is used by other things, I couldn't check all of it, but adding just the two bytes of GROM to my address checks allowed me to raise the capture rate to 100% on FCTN-=, and much more acceptable on all others. Basically, in many cases that one branch was my only chance to retain control of the console.

 

So now it was working as I intended, and I started testing. I had tested user interrupt code way back in the 90's and been happy that many programs ignored it. It's not true anymore -- many many programs today use that hook. Which makes sense, we don't rely as much on the console ROMs to move sprites or play music anymore. So this was a stumper for me. It wasn't compatible enough to make a good demo, but how was I supposed to wrest power away from running assembly programs, even IF I got a chance to run before they installed their own hook. (Most programs do not check for an existing user interrupt, they just replace it.)

 

I added a check to the code that scanned the entire 24k upper memory bank, a little bit at a time, for code that looked like it was going to replace the user interrupt. It would patch that code to write to my own memory space instead, and I could jump to that program's interrupt after I was done my work. My first pass did 1k per interrupt -- and this worked on a number of programs, with just a little bit of slowdown.

 

I tried a number of things to improve it - shrinking the memory space scanned, scanning a smaller amount every frame, but the results were poor - I lost control more than I kept it. Then I decided that since I was getting control mostly because of the GPL loaders anyway, why not just detect if the E/A cart was about to launch a program, and scan then? Using Thierry Nouspikel's disassembly, I found both LOAD AND RUN and RUN PROGRAM FILE used the same setup function before jumping to code. I was able to hook that, and when I detected it, I scanned the entire 24k memory block and patched it. This worked better on programs that had multiple interrupt hooks that changed at runtime, too. (But it does mean that REA probably won't work (at least by my standard of maintaining control), Rich, that routine probably moved in GROM and so I wouldn't detect it.)

 

In the end, it works pretty well, and I learned a couple of tricks. There are a few weaknesses I ran into:

-LOAD AND RUN with autostart doesn't work, because it never returns to the E/A environment from the assembly loader, so my code loses control.

-Any other loader won't work, either, because we never get a chance to scan for interrupt replacement code.

-On that note, I only check for CLR @>8374, MOV Rx,@>8374, or MOV @>xxxx,@>8374, and only in high RAM -- but that covers most of it.

-Extended BASIC doesn't work right -- the hook and banner work but I don't have a clean way to detect it, so the character offset doesn't get updated.

-Any program that uses the top of low memory (where Classic99 resides) will probably crash.

-Any program that uses VRAM at >3800 will cause screen corruption.

-Any program that can't deal with the screen image table being FORCED to >3800 or changes screen mode will see screen corruption.

-And any program that never enables interrupts will "escape the sandbox".

 

But as a joke, I was pleased with how it came out.

[Willsy]

Yeah it was cool. Here's a technique that might work better, but it would require a hack to classic99 which you may consider to be cheating :-)

 

Intercept writes to the interrupt vector such that they get added to a stack of interrupt vectors. With each interrupt you work through the stack caking the intended routine then call your own routine before returning from the interrupt.

 

You might not need a stack at all. After all, most applications will only install one interrupt routine. Just a location in memory to hold the intended vector.

 

Good fun :-)