Classic99 Updates

[Tursi]

Ok thanks, also there does not seem to be any indicator of what AMS bank I am in, I can use RXB to change the banks but it always says >0100 bank, is that GROM or AMS? I assumed it was AMS but it would most likely be GROM, the AMS would require a full listing of each 4K area of memory and what page was engaged there.

 

GROM is not banked in the hardware, so they will never show in the debugger. GROM banks are selected by changing which address you use to access them.

 

AMS banks are not displayed, no, that is a deficiency in the debugger. It'll be fixed when I condense the memory systems together.

 

The bank indicator that IS displayed displays the DSR page and the cartridge ROM bank that's active.

[Tursi]

Just a quickie fix for noted problems...

 

-Fix setting of VDP interrupt bit to happen AFTER the screen is drawn, not before (fixes Mad Marvin demo)

-fix stack overflow in loading 'O'ther cart types from Classic99.ini

-Updated TurboForth BLOCKS file to today's version

 

http://harmlesslion.com/software/classic99

[Willsy]

Wow! That's service!

 

Thanks for the rapid update

[sometimes99er]

-Fix setting of VDP interrupt bit to happen AFTER the screen is drawn, not before (fixes Mad Marvin demo)

 

Ahh, excellent ! Makes my Secret Scroll demo go from abrupt spasmodic movement to pretty smooth full screen one pixel scrolling.

 

 

[Tursi]

Nice! That looks very good. Are you updating the full character set every frame?

 

I did something along those lines years ago, but I only did 2 pixel scrolling by pre-defining all the characters, so that I only updated the 768 bytes of screen table. It worked, but of course there wasn't enough characters to do better than 2 pixel scrolling (and even then I only had 256/4/2 = 32 characters ). It was part of this unfinished intro:

[sometimes99er]

We touched on this once. Again, an impressive demo/intro you've got there.

 

Here's just comparing the two techniques - for a bit of fun. Both have their pros and cons - it all depends.

 

To implement both tricks (scrolling of text in both demos), one has to have empty lines between the lines of text. Basically scrolling from one character to a character above will not have to care about any pattern already being there (it's empty).

 

Your patterns are prepared ahead of the actual scroll, and I scroll one pixel every frame. This is what the Pattern Descriptor Table will look like in the two cases.

 

 

This only has to happen for, let's say uppercase characters, the space and period. That's about 28 characters. Tursi prepares 28 x 8 = 224 characters before the effect takes place, while I continuously (once a frame) have to update 28 x 2 = 56 characters.

 

Next there's the update of the Screen Image Table. Tursi tries to update all 768 screen locations every frame (that's what I'm guessing). I swap between two screens and update the screen not seen with one eight of the number of locations, that's 768 / 8 = 96 bytes every frame.

 

So as far as the VDP is concerned, Tursi is occupying 224 * 8 + 768 = 2560 bytes and updating 768 bytes every frame. While I'm occupying 56 * 8 + 2 * 768 = 1984 bytes and updating 56 * 8 + 96 = 544 bytes every frame.

 

[marc.hull]

Just a quickie fix for noted problems...

 

-Fix setting of VDP interrupt bit to happen AFTER the screen is drawn, not before (fixes Mad Marvin demo)

-fix stack overflow in loading 'O'ther cart types from Classic99.ini

-Updated TurboForth BLOCKS file to today's version

 

http://harmlesslion....tware/classic99

Well... Mad Marvin Demo wasn't broken so a fix doesn't appear necessary. Oh you mean fixed CL99... Got ya.... !

[Tursi]

We touched on this once. Again, an impressive demo/intro you've got there.

 

hehe.. sorry for the repetition, then, the brain goes with old age.

 

This only has to happen for, let's say uppercase characters, the space and period. That's about 28 characters. Tursi prepares 28 x 8 = 224 characters before the effect takes place, while I continuously (once a frame) have to update 28 x 2 = 56 characters.

 

Ah, of course! It somehow didn't occur to me you were scrolling less than the entire character set. That's beautiful! When I first tried this (years before that demo) I did do the whole character set, which was of course a bit slower than was ideal. (Of course, I also used VSBW and VSBR ).

 

Next there's the update of the Screen Image Table. Tursi tries to update all 768 screen locations every frame (that's what I'm guessing). I swap between two screens and update the screen not seen with one eight of the number of locations, that's 768 / 8 = 96 bytes every frame.

 

Yep! It is actually fast enough, or pretty close, but double-buffering is definately the way to do it so you don't have to race the blank. Plus your method leaves untouched plenty of characters for other graphics, mine wastes all of them.

 

Very nice!

[OX.]

Hi Tursi, noticed an issue with Classic99 when you quit the emulator in fullscreen mode (Alt+tab out and right click Classic99 task and exit) and then restart (stretchmode=3 in the .ini), if the users desktop resolution is not the same as the chosen Classic99 fullscreen resolution then you end up with a view of a partial low res desktop instead of Classic99. A few people have asked me about this in Gamebase TI99/4A as they would like the emulator to default to full screen startup.

 

OX.

Edited December 13, 2011 by OX.

[Tursi]

I was planning to remove full screen mode, it's just a pain in the butt. I used it back when it was faster than Windowed mode, but I haven't used it otherwise in a very long time.

 

The full screen mode is supposed to change the resolution, so it's strange that you notice a correlation between the selected resolution and the desktop resolution.

[sometimes99er]

When I started with TI-99/4A emulation back in 2004, the full screen mode was cool since it gave the right look and feel, taking over the complete display. Now I run in size 2x all the time. I guess, if I had to demonstrate something to an adult, I might change to 3x, and then maybe window maximize (upper right window icon) would be good with a kid. I just tried to switch forth and back to full screen mode using Alt + Enter, and there's a delay at about 2 seconds, which is okay, but knowing that, I might just go for the maximize window, which is instant. Also coming back from full screen mode, the "new" size of the window is perhaps something leftover from the full screen resolution. Using "maximize" and then "restore down" does exactly that (returns to my 2x). The "Change size" option is crucial giving me crisp clear graphics. Bottomline, full screen mode is nice, but I can easily live without it.

 

[+OLD CS1]

hrmmmm I use full screen mode with my "entertainment" PC I have connected to the telly via S-Video. I may be the only one, but I will miss it if removed.

[kl99]

Regarding Full screen mode: I don't think, removing a working feature is a good idea.

[RXB]

Personally I never use more then 1/2 of the screen for Classic99 but then I have 1920 by 1080 so more would look silly. Besides it looks fine in the videos.

[OX.]

I was planning to remove full screen mode, it's just a pain in the butt. I used it back when it was faster than Windowed mode, but I haven't used it otherwise in a very long time.

 

The full screen mode is supposed to change the resolution, so it's strange that you notice a correlation between the selected resolution and the desktop resolution.

 

Some people like the classic feel of a full screen (although it would be nice to have it 4:3 ratio with vertical borders for widescreen monitors), any chance of an update Tursi?

[Bones-69]

I would like to see the Classic99 screen bordered by the image of old TV set.... But s'pose that's just being silly.

[sometimes99er]

I would like to see the Classic99 screen bordered by the image of old TV set.... But s'pose that's just being silly.

 

A comfy solution, but then the image of the old TV set would be bordered by your monitor ?

 

How about putting the monitor inside an old tubeless television or something that looks like it ...

 

[Tursi]

Regarding Full screen mode: I don't think, removing a working feature is a good idea.

 

hehe.. sure, but it doesn't work. At least not correctly.

 

Classic99 is first and foremost a programming tool. It's hard to do much programming on the rest of the machine while the entire display is used up. I also don't see myself adding TV border skins.. that's more the domain of MESS. (Although I guess it's not as hard as actually making things work... )

 

Although I love that cardboard TV picture, hehe.

 

Nevertheless, people have spoken. I won't remove fullscreen mode. But I don't promise to make fixing it any kind of priority! ^.^

[RXB]

Tursi in the CLIP section of the Classic99 Manual it says: "No SBRLNK opcodes are supported in the CLIP device."

 

Was this supposed to say DSRLNK or GPLDSRLNK?

The reason I ask is GPLDSRLNK supports almost anything and DSRLNK only works on devices only.

The GPLDSRLNK will find subprograms in GROM/RAM/VDP while DSRLNK only searches ROM and pretty much nothing else.

 

In a nutshell one is universal (GPLDSRLNK) and the other (DSRLNK) is RAM only.

[+adamantyr]

Regarding Full screen mode: I don't think, removing a working feature is a good idea.

 

hehe.. sure, but it doesn't work. At least not correctly.

 

Classic99 is first and foremost a programming tool. It's hard to do much programming on the rest of the machine while the entire display is used up. I also don't see myself adding TV border skins.. that's more the domain of MESS. (Although I guess it's not as hard as actually making things work... )

 

Although I love that cardboard TV picture, hehe.

 

Nevertheless, people have spoken. I won't remove fullscreen mode. But I don't promise to make fixing it any kind of priority! ^.^

 

I'd rather have the video recording fixed so I got full audio and video.

 

Adam

[RXB]

I personally think that time spent on Classic99 by Tursi should be better spent on other things then screen recorder apps as:

 

Hypercam, KRUT, uTIPu, uVNC, WINK, WEBNARIA, Camstudio, Jing, Webinaria.....

 

Besides here are many others:

 

http://en.wikipedia.org/wiki/Comparison_of_screencasting_software

 

All these apps work great and you can record not only the TI screen from Classic99 but also anything else you are doing.

[Tursi]

Tursi in the CLIP section of the Classic99 Manual it says: "No SBRLNK opcodes are supported in the CLIP device." Was this supposed to say DSRLNK or GPLDSRLNK?

 

SBRLNK. I no longer remember what the term stands for and it's possible I'm using it wrong, but these are the extended DSR opcodes used by the TI Disk Controller, for functions like "read sector". You use them through DSRLNK., and a single-byte device name from 0x10 through 0x16. No PAB is used, just hard-coded addresses in scratchpad:

 

0x10 = Sector access

0x11 = Format

0x12 = Protect File

0x13 = Rename file

0x14 = File In (read file by sectors)

0x15 = File out (write file by sectors)

0x16 = CALL FILES

[RXB]

Tursi in the CLIP section of the Classic99 Manual it says: "No SBRLNK opcodes are supported in the CLIP device." Was this supposed to say DSRLNK or GPLDSRLNK?

 

SBRLNK. I no longer remember what the term stands for and it's possible I'm using it wrong, but these are the extended DSR opcodes used by the TI Disk Controller, for functions like "read sector". You use them through DSRLNK., and a single-byte device name from 0x10 through 0x16. No PAB is used, just hard-coded addresses in scratchpad:

 

0x10 = Sector access

0x11 = Format

0x12 = Protect File

0x13 = Rename file

0x14 = File In (read file by sectors)

0x15 = File out (write file by sectors)

0x16 = CALL FILES

 

I have all of these in RXB written in GPL and they work with the SCSI Card to read/write sectors or files. I do not have a Format routine as it is not used that often.

The Extended codes are Scratch Record and Status both supported by GPL but no one has written a DSR except for SCSI to support it.

That SCSI DSR was not distributied by Western Horizon. I did write the GPL code to use it according to Don O'Neil docs he gave me.

 

That Sector read/write you talked about was mentioned by someone long ago but I never saw it used.

[+OLD CS1]

I use full-screen mode but I am not concerned about bug fixes as I have not really noticed any issues.

 

Personally, I am more interested in fixing audio recording in video, and figuring out how to get a good clean video capture that I can convert to clean GIFs. I have been successful with the later but they are not exactly pixel-for-pixel recreations. None the less, I see clearly Tursi's intent for the use of the program and understand these might be low priority.

[RXB]

I use full-screen mode but I am not concerned about bug fixes as I have not really noticed any issues.

 

Personally, I am more interested in fixing audio recording in video, and figuring out how to get a good clean video capture that I can convert to clean GIFs. I have been successful with the later but they are not exactly pixel-for-pixel recreations. None the less, I see clearly Tursi's intent for the use of the program and understand these might be low priority.

 

Well my Video Capture program HyperCam2 that I use is free and you can scale the size to be any size and any pixel window size. If you use Windows Magnify then pixels would be 4 times normal size.