Grayscale Lib for TI83 Basic

[UnknownKind]

Could someone make a grayscale lib for ti 83 plus basic? I know its possible but whos willing to do it.? Like what you could do is have.. 4 different shades and then the coordinates like example :

2:24:10:Asm(GrayLib

2 = shade of gray
24 = x axis
10 = y axis

Edit kv83:Please... don't use CAPS LOCK in titles (or posts)

[tr1p1ea]

I dont know how many times this has to be said. You cant just make a lib like that.

Omnicalc provides what you need to install a little int that can flash a pic for you. Thats all you need.

[Kevin_Ouellet]

Actually, making basic grayscale isn't only as simple as running an ASM(prgmGSENABLE prgm at the beginning of the game. You have to run the interrupt (if anyone have a proper word for BASIC interrupt plz tell me) after every lines of code.

Also NEVER use the Asm( command in a walking loop because it's very slow. Use Omnicalc or dissasemble (or hack) xLIB and run the hex code from the ExecAsm( command in Omnicalc. This should be faster.

There is a guide to BASIC grayscale here:
http://www.ticalc.org/archives/files/fi ... 35823.html

[DJ_O]

Just a thought: I saw the PI background program by Benryves at ticalc.org (http://www.ticalc.org/archives/files/fi ... 27493.html) and noticed that you can do anything with your calc during it's runtime. I was wondering if a multitaksing-based gray lib like the pi background would be possible? For example, you load your two map layer with xLIB and store them in two pictures (like in Reuben Quest), you display the first map layer, and you run Asm(prgmGSENABLE. That way, the second layer would be displayed as a full screen sprite like in RQ using the XOR logic very quickly during runtime. Then when you want to disable the grayscale you just run Asm(prgmGSDSABLE. Basically this would do almost the same thing than using Omnicalc, but this would decrease the game size dramatically. The interupt frequency would be stored in X so if you want speed but less quality you choose a lower value and if you want high quality but don't need speed much you choose a higher, and of course the grayscale would still be 3 level only. I was wondering if we could use the multitasking idea by Benryves to make that kind of library?

[dysfunction]

Yeah, all you'd need would be a separate program for each picture, then a regular b+w pic file to draw over it. That would make even more functional 3-level basic greyscale.

[Jim e]

As plausible as it sounds, at some point tios well hit an im 1 or a DI or some thing else of that nature. Not impossible, but not worth the effort put into it really. Besides every basic coder should learn asm eventually, lets not give them any reason to stay with basic.

But with that aside, increasing the interrupt frequency doesn't really improve the image, It's been a misconception that the faster you display your layers the better the grey scale. The 83(+) lcd only updates a frame at a certain rate, try going faster or slower than that and you'll get visible noise due to the images being out of sync. In gpp it's seen as the shifting pixels, and in rigview, prior to being tuned,you'll see a diagonal line of bytes being darker or lighter than they should. The key is trying to sync it just right, and that's hard with the normal interrupt timers.

[DJ_O]

Ok thx. It was just a thought because my BASIC game update the display 25 times a second on my TI-83+ SE (50 times during splash screens), making quite decent 3-level grayscale, but I have to shift the pixel with Omnicalc Sprite( command after every code of line so it was just a thought for shrinking the program size down .

[Jim e]

Well, if omnicalc is modified it could be possible to build a grey routine straight into it. I guess that's at micheal's whim, or any one else willing and knowledgable enough with hooks .
You know doesn't seem that UnknownKind first post was entirely impossible, just hard.

[dysfunction]

The least difficult course, however, would be to simply modify Ben's library. Cut out the part at the beginning where it prompts the user to input the interrupt value, and instead have the program get that value from X. For your actual pics, just replace the default pi pic data with your own exported from istudio or calcgs, then recompile the program.

[Gambit]

Hello everybody! Although this is my first post at the Maxcoderz forum, I'm quite experience in assembly and would like to say that I have some intriguing news about "revolutionary greyscale graphics": I have written a greyscale library demo! Before you read, I would also like to apologize in advance for the length of this post, since it is gargantuan...

I originally thought of this last Thursday, February 17 during school, wrote it after I came home, and sent off a demo to Kévin that evening. With that, he gave me a link to this thread, which meant that I wasn't the first to think of this After reading this, I tweaked the library to sort of fit Kévin's specifications. Here are some important pieces from the readme:

The syntax of ZGreyLib is as follows:
{#1,#2,#3:Asm(prgmZGREYLIB
#1 - Action code. The currently supported codes are install (1) and uninstall (0)
#2 - Picture #. For those who have used ZPIC, follow the same convention, mainly 1 = Pic1, 2 = Pic2; 10 = Pic0.
#3 - Interrupt Frequency. If you divide the # of times an interrupt triggers by this #, you get the number of times the images are XORed per second. Example: ~100Hz/4 is ~25Hz.

...This program takes advantage of the hardware interrupts built in the z80 microprocessor... Every time a counter reaches zero, the interrupt routine will XOR a buffer that holds the 2nd greyscale layer with the current screen, and reset the counter to the user-specified frequency before jumping to the system interrupt code. By XORing the two images many times per second, it gives the illusion of grey...

The first version I sent to him was extremely buggy because _FindSym in an interrupt isn't safe. It seems that the BASIC interpreter/parser doesn't update the VAT or something to that nature, so if I couldn't look up the picture variable every interrupt, I had to look for a fixed, untouched location where I could copy the picture to, since RAM data (i.e. the picture variable) is relocatable. Boy, that was a long sentence . Anyway, since appBackUpScreen had the interrupt code and plotSScreen was taken (duh), I immediately thought of the last 768 byte buffer, saveSScreen. The second version, which uses saveSScreen, works, but I then discovered some discouraging news: Omnicalc's "equates.inc" has Sprite_DATA equated to saveSScreen. And sure enough, when I tested sprite(), the image was messed up. Darn ... The solution I proposed to Kévin was to make the picture non-relocatable by archiving it. This new method works with near-identical quality to the saveSScreen version, but there are some glaring problems:

* Kévin's RPGs will have to use the archive, meaning slower map loading
* A GarbageCollect will mess up the picture pointers, and set interrupt mode 1
* You cannot delete/edit/unarchive the picture while the library is installed
* xLIB still uses appBackUpScreen, so the library must be uninstalled first before using it
* Omnicalc might sometime store data to the interrupt code (256 bytes @$9900 and ??? bytes @$9A9A), thus crashing the calculator

The advantages? Well, I'm glad you asked. If we can get rid of these problems, this library will allow:
* Omnicalc sprite() quality 3-level greyscale or better
* Reduced program size (because there aren't as many sprite() commands)
* Faster program execution (because there aren't as many sprite() commands)
* And best of all, higher-quality greyscale graphics than Omnicalc on an 83+

This is where I currently stand. Now I ask, what other possible method(s) are there to fix xLIB and Omnicalc compatability? Is there another mysterious 768 byte RAM buffer somewhere? Or will this greyscale library be just another dream?

@Kévin: The reason why this didn't work in an emulator is because VTI and FlashDebugger don't emulate interrupts properly, which means that you can't take screenshots I'm not positive about TiLEm though...
@Everybody else: I don't know of an easy way to distribute this library, seeing that I don't have a webpage to post a link to, and that I don't want to release it to ticalc.org yet... Btw, you guys can also catch me at the Detached Solutions forum, if need be

[sic]

Sounds cool.

You could always write your own interrupt-safe _findsym It wouldn't be that hard to walk the Allocation Table for normal variables until you find the appropriate picture variable. If you did this, you would also be able to handle cases when the pic variable is archived during execution (if that is something you want to do). And of course, you wouldn't have to worry about finding a safe 768 byte buffer.

One small thing: pictures do not take up the full 768 bytes. You only need 63*12, or 756 bytes

[Gambit]

Hmmm, never thought of that. However, I see a problem with looking it up every interrupt. What if the interpreter was moving the picture and an interrupt was triggered at, say, the 123 byte of the picture. That would then lead to those crashes/messed up pictures/etc I experienced in my first version...

Oh, and I'm aware a picture takes $02F4 bytes. Thanks anyway.

[tr1p1ea]

Ive actually made something very similar but i stopped. Good to see that something like this has popped up .

[DJ_O]

lol you replied one month later

[Jim e]

I honestly didn't notice gambits posting of this, I would paid attention to this subject.

I remember When I learn picture weren't 768 bytes. The fun times I had crashing my 83P. Sigh....