My fourVid used deflate to store the videos. That's how I was getting like 30% compressed video sizes. Some quick math tells me that it was decompressing at least 30 KB/s on the z80s. (Though it might be much higher, that's just the lower bound.)

What I find interesting about your method is that you are kind of abusing Huffman codes in a way that makes them no longer Huffman codes. I thought the idea was the huffman codes are shorter for the more common values, but yours all end up taking the same amount of space. This would of course greatly speed up decompression, but, it's not really huffman anymore

Wouldn't you be able to get better ratios if instead of using huffman, you simply made your lookup tables bigger and used all of the bits in your huffman fields?

Asm(prgmFULLTEST) ran fine, exited fine and didn't mess with the free ARC display. So I guess it worked.

Well, that means the problem isn't FULLRENE and is somehow the way you are compiling it.

- turning pixels on and off perfectly in sync with the display driver: while this is very uncommon, this can be damaging to your screen (not nearly as bad as blue lines of death, but it's still best to avoid). If this is happening, some pixels wil be lighter than normal white pixels, and others will be darker than black pixels.

What? (I'm confused as to how this is bad, maybe I don't understand what you were saying)

Quote from: DJ Omnimaga on November 07, 2013, 04:45:04 pm

The only issue is that they drain batteries twice faster, especially ASM games with nearly perfect grayscale.

Does grayscale really use more battery power? I thought that most games (running at the same CPU speed) drain the battery equally because most of them use 100% CPU (meaning they never put the processor in halt/low power mode).

(This might be wrong) Grayscale does not use more power. You are right, considering most games don't halt the CPU, the power usage is directly proportional to the CPU speed and there are only 2 CPU speeds.


The reason grayscale doesn't damage the screen is because although to you it looks weird, to the LCD, nothing has changed. The screen is updated 60 times per second no matter what. This is done by the LCD driver which exists physically outside of the CPU. The LCD driver goes through the screen row by row and sets each pixel. That means that the driver is sending ON/OFF signals at around 4,000 signals per second. Simply changing whether or not the driver sends a 1 or a 0 between updates doesn't really change anything because it doesn't remember what it sent last go around. (By this logic, the most physically demanding operation for the driver would be a checkerboard.)

Now, if you actually want to damage the screen, instead of using grayscale, you use bluescale. This was a sort of horrible idea that we played around with for a little while but for the most part, a consensus was drawn to not use it because it actually did cause physical damage to the screen. Unlike grayscale which simply toggles the pixels (which the LCD is designed to do obviously which is why it doesn't cause damage) bluescale rapidly changed the contrast. This resulted in some pretty crazy stuff, but, running these programs for too long would permanently damage your screen.


Edit:
   Willrandship: has anyone tested that, I'm actually kind of interested now

Also, for future reference. bcall(_delVarArc) locks flash if a variable is in flash

And all OS errors lock flash as well.

Well, Omnicalc, as awesome as it is, needs to be updated anyway. I'm up for it but I can't promise anything.

DrDnar updated it, but the issue is that the new one doesn't work with zStart. zStart calls Omnicalc by address, so to fix it and remain compatibility you'd have to fix it OS patch style.

zStart is so awesome. Except the new version always crashes my calculator when I do ON + MATH, and I don't have anything else installed that could be affecting it...

Yeah, that's a glitch I haven't really found a way to fix. If you open Mathprint at least once, it won't crash anymore. (An easy way to do this would be to leave it defaulted to mathprint and then press ON + MATH on every boot)

Yes, I've done this before to add an option to a menu.

Now, there are two ways to do this, method 1 will only work for a specific OS (well, it will work unless they changed the menu), while method 2 will always work. I'm only going to talk about method 1 though because looking at my code, you don't want to do method 2.

The first thing you have to do is find the actual data for the menu you want to replace. To do this, set a menu hook that returns zero, set a breakpoint on the menu hook, and then open the menu you want to replace. Skip the first call (A = 4) and on the second call (A = 0) follow the function when it returns. It's going to "un-bcall" a few times but eventually you'll end up back where the hook was called. When it does LD A, ($85DE), you'll know that you're back. Take note of A because it's the value for the current menu. It's then going to do a little math and load HL with the value pointed to by HL. When it does this, HL is now pointing to the data for the menu.

Look at wikiti to see how the data is represented and then copy down everything for the menu (make sure you're still on the right flash page). (If there are 2 submenus, it's going to be the initial size byte, and then two of those data structures). Once you have the menu data, you need to figure out which item it is that you want to remove (you can probably just count). Remove those two bytes and readjust the size byte of that menu subgroup. This is now the actual menu you want to display.

To actually replace the menu. Make a menu hook and returns zero unless ($85DE) (it's called menuCurrent btw) equals the A value from before. (You can also look these values up by doing a ctrl + F "menuCurrent" on this page) The hook also needs to return zero if it's been called for any event besides A = 0. At this point, you need to have the menu data in ram. Just point HL to the menu data and return nz. The OS will handle the rest from here

Calc 2: This one seems weird to me. K_0411S, 1.03, TI-84+SE

Back around the time that the missing ram pages were discovered, we figured out not to trust anything written on the back of a K calculator. If I remember correctly, we thought they might be refurbished or something.