A loop of known clock cycle length during the wait period between interrupts. Cycles used in this loop is compared against the total number of cycles during program execution. I would have this loop update a 32 bit counter, which is then later read out after the end of the program execution via debugger. Your math would then be:

To determine CPU percentage idle:

(NumberOfTimesLooped*ClockCycleCountOfLoop)/(15,000,000*NumberOfSeconds)

This will give you a good enough estimation, since any inaccuracies, if done right, are negligible (less than 0.1%). This is also assuming you're running the calc at 15MHz.

Changes:

* Size reduction (now 737,280 bytes on-calc)
* Video playback perfect
* Aspect ratio preserved. Video cropped on left and right to fit.

What happened:

Implemented a page filling algorithm that actually tries to fill in the gaps between pages with data by sorting through the chunks to see what will still fit, starting from the largest available piece working its way down the list until none of the available blocks will fit any more. Saved 48-64KB.

Changed compression/decompression scheme from puCrunch to APACK. This fixed the video playback corruption issue, which doesn't inspire much confidence in what I had before. APACK also seems to perform better than puCrunch in this application. Saved another ~48-64KB.

In an attempt to fix the playback problem, I performed much of the video/image processing in FFMPEG instead of doing the ridiculously slow batch file conversions in Irfanview. Although I spent more time learning how to actually use FFMPEG than it did if I had actually went through with the batch conversion, I learned how to use it better, which makes me happier. Unfortunately, the destination folder went up dramatically, as I was unable to figure out how to change color depth of the output .png files. But, I was able to perform resizing (while preserving the aspect ratio), cropping the video, and (as was done before) splitting the file into its individual frames as PNG's.

Also, the Java script had to be changed to handle PNG files that had a color depth of more than 1bpp. If it had a color depth of 1bpp and you knew the image was 96x64, you could create an ImageData object (from the SWT library), then do something like "myPictureObject.data" to get a data stream that's binary-compatible with the calc. Just put that data into a source file and LDIR it to a screen buffer. But... since I couldn't do that anymore, I had to change it so that it actually scans through the file and creates the bitmap. Ah well.

When I changed from puCrunch to APACK, the application's performance characteristics didn't change all that much. If anything, APACK is a slight bit faster than puCrunch, but I'll have to test using an actual stopwatch later on instead of counting it out.

The audio interrupt is running at 24KHz. The app has 23-29% free CPU clocks left.

I can no longer continue this project until I have finished (or at least, completed basic functionality) my on-calc music tracker project. So unless there are other suggestions (I've already tried KermM's mt3 converter, with no luck), I'm putting this on hold for a while.

Or... if you happen to have the music for Bad Apple playable via MobileTunes3, this will plug right into the app, albeit at the wrong octave (due to the app running at 24Khz vs the required ~62KHz)

EDIT: Whoops. Forgot to upload the video. I'll do that now.

Second attempt. This one took a much longer amount of time to accomplish, as there were many problems both with the Java side of things and with SPASM, not to mention the woes of trying to get my 4 channel audio interrupt to work with the renderer and keep the decompressor running in the background at all times.

I still use pucrunch, but this time around, I decompress to ~16KB blocks and have the renderer scan across it.

After some manual tinkering with the data block locations, I've got the app down to 835,584 bytes total. There's still a disgusting amount of space being wasted between pages and I'm sure I could reduce the size by another 16-64KB if I coded the Java side of things to actually sort and try to fill the gaps.

Anyway.

Even tho there is no (real) music, the 4 channel audio interrupt *is* running in this screenshot at a very low frequency hum (as is the setting if not initialized). The video itself is much smoother on-calc, despite the fact that there is frame-skipping logic if the video can't render at ~30FPS.

-------
EDIT: Music *can* play. I just don't have a track to play with the thing yet.

Also, there's still an unidentified encoding problem. I don't know if it's with pucrunch or if it's the Java code unreliably reading in the .png files. Or if it's a problem with the frameskip logic.

EDIT3: Maybe I should try apack next, just for the fun of it?

Tested the version linked to me on the IRC chan on hardware (TI-84 Plus SE).  The timing fix works, and the interlacing is less noticeable on the actual hardware. It's still obvious when the scene changes very fast, tho.

Sample. The only real observed difference is the fact that the defpages are not in the same file as the first defpage, and that the closing quotes in the initial defpage is not closed.
#include "pc/redefs.inc"
#define main_build
#include "pc/defs.inc"
#include "pc/app.inc"
#define getpagenum(label) label>>16
#define cpcall(label) call XPC \ .dw label \ .db getpagenum(label)
#define cpjump(label) call XPJ \ .db getpagenum(label) \ .dw label
#define loadslot(xx,lbl) call LSL \ .db xx*3 \ .dw lbl \ .db getpagenum(lbl)
#DEFINE CLSB(xx) $000000FF&(xx)
#DEFINE CMSB(xx) ($0000FF00&xx)>>8
#DEFINE MENU_SCREEN_WIDTH 12
;-----------------------------------------------------------------------------
;DEFINE AREA FOR DEBUGGING PURPOSES. UNCOMMENT TO ALLOW FOR EASIER WORK.

;Bypasses menu on app startup into game mode. To change the parameters of
;what you're starting up with, check in p0\_0.z80 and search for the define.
#DEFINE CADAN_MENUBYPASS

;If you're using CADAN_MENUBYPASS, uncomment one of these defines below to
;SELECT YOUR CHARACTER automatically.

;#DEFINE CADAN_MENUBYPASS_CHARSEL %00000001 ;DevBlock
#DEFINE CADAN_MENUBYPASS_CHARSEL %00000010 ;Iambian
;#DEFINE CADAN_MENUBYPASS_CHARSEL %00000100 ;Netham45 (spork)
;#DEFINE CADAN_MENUBYPASS_CHARSEL %00001000 ;Placeholder
;#DEFINE CADAN_MENUBYPASS_CHARSEL %00010000 ;Placeholder
;#DEFINE CADAN_MENUBYPASS_CHARSEL %00100000 ;Nanami
;#DEFINE CADAN_MENUBYPASS_CHARSEL %01000000 ;Netham45 (lobster)
;#DEFINE CADAN_MENUBYPASS_CHARSEL %10000000 ;Placeholder

;Automatically sets hexadecimal mode in-game. Also, changes output to the
;scoreboard from curscore to the 4 bytes in scoredebug. Yus.
;#DEFINE CADAN_AUTOSCOREDEBUG

;-----------------------------------------------------------------------------

;=============================================================================
defpage(0, "CaDan v2") ;======================================================
;
;This project is dedicated to my beloved Etri, the Catgirl o' Nine Tails, who
;understood me and my desire to extract Red Kool-Aid from all of humanity.
;
;Coding of the Calculator Danmaku Project was done as a collaborative effort
;
;Primary coding and planning: Rodger Weisman (Iambian Zenith)
;Code and script build, test: Timothy (Geekboy)
;Big time code optimization : "calc84maniac"
;
.echo "------------------"
#include "p0/_0.z80"
#include "p0/xpage.z80"    ;RAM routines held here
#include "p0/lib_menu.z80" ;Menu library routines and their supporters
#include "p0/lib_txtr.z80" ;text display library routines
#include "p0/lib_grfx.z80" ;menu graphics library
#include "p0/lib_dcmp.z80" ;decompression library
#include "p0/lib_scor.z80" ;score handler library
MenuGraphicsData:          ;menu graphical data. Read tables from this address
#include "gfxdat/build/imenu.z80"
MenuExecData:
#include "gfxdat/build/smenu.z80"
MenuTextData:
#include "gfxdat/build/tmenu.z80"

.echo "Space before 7000: ",$7000-$," out of 14366"
.block $7800-($&$0000FFFF) ;Making room for page-aligned font tables
#include "p0/dat_font.z80" ;font, kerning, and ASCII translation data
#include "p0/dat/dat_minm.z80" ;danmaku mode mini menu. No more than 213 bytes
.echo "------------------"

;=============================================================================
defpage(1)  ;=================================================================
.echo "------------------"
#include "p1/LUTables.z80" ;must not exceed 256 bytes. Page-aligned lookup table
.block $4100-($&$0000FFFF)
#include "p1/_1.z80"        ;interrupt, initialization and tasking routines
#include "p1/lib_reso.z80"  ;Resource table handlers
#include "p1/lib_scrn.z80"  ;All LCD driving routines found here
#include "p1/lib_shot.z80"  ;Bullet system
#include "p1/lib_psht.z80"  ;Player bullet system. All references in here.
#include "p1/lib_scpt.z80"  ;Script system. Contains "dat_scpt.z80"
;.block $7800-($&$0000FFFF)  ;### DEBUG SO SCRIPTSYS EDITS DO NOT KILL SCRIPT
#include "p1/lib_sprt.z80"  ;Sprite library
#include "p1/lib_enmy.z80"  ;Enemy table handlers and initializers
#include "p1/tst_stgs.z80"  ;TEST STAGES. DIRECTLY CALLED AND EXECUTED
;#include "p1/lib_sldr.z80"  ;Loading system. Supports script suspension
.echo "------------------"
;=============================================================================
defpage(2)  ;=================================================================
#include "p2/_2.z80"
;=============================================================================
validate()  ;=================================================================


[...]
How will sharps/flats be represented? It seems to me that it would be best to use an extra character to specify when note values are hexadecimal, making hexadecimal values always three characters, and then using the third character in letter notation to display sharp/flat when necessary.

Also, notes with octave values attached traditionally have the octave following the note letter and sharp/flat symbol. What do you think about representing notes more like this, then:

Code: [Select]

CH1 CH2 CH3 CH4 TIME
A♯0 $1F G♭3 C3  /16


That looks like a great idea.

TBH, the reason I didn't talk about sharps and flats was because I was too lazy to look up how to type them. I have those characters ready to be placed into the font tables.

The way you have it set up, tho, looks a bit better than what I had on paper (oct, letter, sharp/flat). I'll probably do it that way

My desktop has changed a fair bit, but the general structure of icons on the desktop hasn't in the past ... so many years.

EDIT: Yes, I have a "Turn off Monitor" button. Very useful in the case of laptops, where most of them don't have a power button to begin with (most just sleeps the computer, which defeats the purpose of just turning off the monitor)

EDIT2: The quote is supposed to be motivational. If I can see it, I'm not doing enough.