Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - thepenguin77

Pages: 1 2 [3] 4
31
TI Z80 / ThePenguin77's Game of Life
« on: May 04, 2011, 10:51:30 pm »
Every thread needs a creative title.

Lately, between track and homework for the AP tests, I have had almost no time to program. So I decided to start programming during school in Mimas. I decided to do Conway's Game of Life because I saw the demo for the Prizm and it looked like it would be fun to use. So I've been working on this during school for about two weeks now and finally today, it actually worked. Although, I probably would have finished this way sooner if I could have used a debugger. It's pretty frustrating to just make changes and hope the program doesn't crash.

If you don't know what Conway's game of life is, here is the general idea: Every pixel is a cell acting independently, whether the cell lives or dies is decided by a set of rules:
1. If three of the eight cells surrounding a dead cell are living, it is born
2. If there are 0 or 1 cells surrounding a living cell, it dies of loneliness
3. If there are 2 or 3 cells surrounding a living cell, it lives on
4. If there are 4 or more cells surrounding a living cell, it dies of overpopulation

To make all this happen, I use most of the extra ram page (13,608 bytes) as well as about 900 bytes of hard-coded routines to do all the checks for every bit. I use the concept of active and not active cells to speed up my simulation (if none of the cells around a cell are alive, it won't do anything next round either). I also make extensive use if IX.

Some stats:
  • 160 x 160 board
  • goal 16 fps (it typically does this until about 200 active cells)


Controls:
  • 2nd - toggle pixel
  • Y= - clear board and recenter
  • Zoom - step
  • Graph - start/stop
  • Clear - quit


Here is the game, I've been using it all day, so it works. I'll get the source later, it was written in Mimas after all. And I think my favorite part of this game is that while the actual game is only 1,042 bytes, it expands to about 1,900 bytes of code and uses 14,000 bytes of ram.

Ironically, my name makes a pretty awesome design.

32
TI-Boy SE - Game Boy Emulator For TI-83+SE/84 / Ti-Boy Grayscale
« on: April 18, 2011, 11:08:57 pm »
Now, I've never actually played Ti-Boy (I should) but I know that the grayscale is not as good as it could be graphics wise. The reason why Ti-Boy can't get great grayscale is because it uses all of the cpu time emulating games. But I think I have found a way to make it work really nice.

For my Chess game, (which people have said has perfect grayscale,) I refresh the screen between 59-61 times per second. Of course the user adjusts this because every calculator is different. And 60 fps takes a pretty big toll, that's 50% of the cpu time. But, another option is to refresh the screen at 30 fps and still match the refresh rate. So essentially, write to the screen buffer, let it get displayed twice then update it again. This method gets some minor scan lines, but it's consistent; there's no flicker.

So to Calc84:
I don't know how you do your grayscale. But if you are using interrupts, make a two stage cycle. Using the crystal timers, make the first stage a static length of 172 at speed $40 (10923Hz) When this interrupt comes back, don't do anything. Then send out a second interrupt of user adjusted length default at 172. When that comes back, update the screen and repeat.

Of course I don't know if this sort of thing is feasible, but if it is, you'll have people talking about how good the grayscale looks :D. (If you get really desperate, you could even refresh at 20 fps, but I don't know how that would look)


Here's a demo to show what I'm talking about:
+ and - adjust delay, 2nd displays delay, and clear quits

33
TI Z80 / zStart - an app that runs on ram clears
« on: April 04, 2011, 10:33:42 pm »
From the future: To get the latest version of zStart, click on the link in my signature.



I've been needing to make this topic for about a year, I just never did because it was started before I joined omni.

Features:
zStart is a really cool app made by me that enables all kinds of things within the calculator. These include:
-setting degrees/radians
-enabling diagnostics
-MathPrint/Classic
-Kill the 2.5x popup
-Enable/disable stat wizards
-Enabling an 8 level grayscale picture on startup (which can and should be in the archive)
-Enabling the CtlgHelp app
-Enabling Omnicalc
-Setting contrast
-Calibrating the screen driver (ALCDFIX)
-Setting custom fonts (which can and should be in the archive)
-Creating and editing custom fonts
-A molar mass calculator for the homescreen
-A hex/binary converter for the homescreen

And some silly stuff:
-An unfinished Solver++ (I wanted to have one side equal the other side, but I got bored with it)
-The ability to use long tokens (sin( = sine(, tan-1( = arcTangent(, ln( = naturalLogarithm( )

But most importantly, it runs on ram clears. This means, once you set an option in zStart, it is essentially permanent. I haven't had to deal with MathPrint in probably 6 months. Also, since its name is zStart, it will probably be the last app in the app menu for quick access.


Using the Homescreen tools
Most of the options are pretty easy to find as they are actually options. The only two you might have trouble finding are the molar mass calculator and the hex/binary converter. To enable these, while turning on the calculator, hold + for the hex calculator and - for the molar mass calculator.

To use the molar mass calculator, put a ?, then your equation, then another ?. The ? act like parenthesis, so you don't actually need the last one. For instance, ?Ca(NO3)2 will return 164.1.

To use the hex/binary convert, just follow a number with either a h or a b. So FFFFh returns 65,535 and 10101010b returns 170.

These tools don't really like basic programs and both can be disabled by running something that enables a parser hook (zStart if you selected Omnicalc, or DCS)


Running on Ram Clears:
   Here's the cool part. I currently have support for OS's 2.43, 2.53, and 2.55. Just enable the Run on Ram Clears option and you're good to go. If for some reason something should go wrong and you enter a boot loop, (with about 100 people running this for about a year I've only heard of 2, and I caused one of them) hold [VARS] while restarting the calculator. zStart will not run and you can figure out what you screwed up.


For best results, I say use MirageOS because I have designed it mostly for that. The only reason I say this is because DCS and zStart both use OFFSCRPT and the parser hook, so whichever one you run last will have it's stuff enabled.


Technical Stuff:
    To make the calculator run on ram clears, it first found the call that displayed "RAM cleared." Then I routed this to the end of that page and added my own code to set a getCSC hook that points to $4083 in zStart. ($4083 so it will never move) Then when zStart gets control, it closes the edit buffer and does it's thing. It then returns control back to the OS with all the settings now in place.

During the whole 2.71 thing, I disassembled the entire boot sequence and found a much better place to install all the features, the only problem is that I don't really want to have to make an unpatcher for all the previously patched calcs.

Solver++ was my attempt at a true TI app. It uses a lot of semidocumented bcalls to make the edit buffer happen. I got the top part completely done, but the bottom part will probably crash.

zStart never actually disables hooks, it only enables them. This is to prevent it from disabling hooks other programs set. The only downside is that if you disable a feature, the hook is still there so it's still going to work.


Included:
For this first post, the file is the whole thing I tried to upload to ticalc.org. (It wouldn't accept it) It includes:
-the app
-the source (~8500 lines)
-the versions of the apps its compatible with (Omnicalc + CtlgHelp)
-the font I currently use on my calculator (smaller basically, all caps are same height and lowers are too)
-some sample pictures along with the converter
-outdated readme  (it's not too old, it has good instructions on how to make pictures)

So try it out, it might be the most useful app on your calculator :D

34
Humour and Jokes / [APRIL FOOLS JOKE] OS 2.71 Released
« on: March 31, 2011, 07:02:29 pm »
Have you guys heard the news? TI just released OS 2.71. Here's the link. Go get it.

I'm pretty busy so I don't have much time to test it out tonight, but if I find anything cool, I'll definitely tell you guys.

35
Computer Projects and Ideas / Long Exposure Pictures from Video
« on: March 30, 2011, 11:03:55 pm »
I know I'm not the only one who has wanted to make a long exposure picture but didn't have the camera to do it. So I made a C++ program that will convert a video into one of those pictures. And after about 2 weeks, it works!!!

This is one of the coolest programs I have ever made. You just take a video file, send it through my program, and get a picture.

I am using DirectShow to do most of the dirty work for me. It parses the video file and gives me a copy of each frame which I then average together. But simply averaging isn't enough because it results in pictures that are very dark. I take each pixel to the 8th power, average them all together, then take the 8th root. This means that little bright spots get really bright, and bright pictures probably turn white.

To use it, the syntax is      longExposure <video> <picture.bmp>      . The video can be anything that DirectShow supports, but to be safe, I'd just use .wmv since DirectShow is made by windows. I'll also have to see about exporting these as .jpg because .bmp sucks.

As for what you need to run it, I feel bad for whoever tries first. I know you will need C++ runtime libraries (x86 x64). And you will probably need DirectX as well.

Here are some pictures that I made in my basement with a flashlight.

36
ASM / Really Long Source Code
« on: March 17, 2011, 07:30:18 pm »
Edit 3:
    Topic move weirdness. My original first post is the sixth post. So that is where the question is at.



______________________________________________________________________________________________

would you imagine the source is 100K, and over 2500 lines of pure code? (for starfox) O.O

You think 2500 is big?

zStart: 8223 (All files tallied)
Geowars: 6815
Starfox: 6783 (I have no idea what you're looking at :D)
Chess: 4821
Imposble: > 4000
TetrisM: 4005
Tower: 3995 (Never mentioned, never finished)
BluTooth:3307
LandRovr: 2205 (Never mentioned, never finished)
Missile: 2124
Bubble:2056


That was after he emailed it to me ;) and with the email came the permission to use what I wanted ^-^ you guys don't have that.  HAH.  SUCKERS.  :P jk

Also, anyone can use it as long as they give me credit ;)


Edit:
   If you meant starfox is only 2500 of code, the code ends around 5188. And I definitely did not skip every other line.

Edit2:
   Those all add up to 48,000. I'm prolific, lol.

37
Computer Projects and Ideas / Screen Ruler
« on: March 13, 2011, 10:53:55 pm »
For quite some time, I have needed to measure distances on my computer screen. But the only screen rulers I could find on google were either vertical or horizontal, which were not very useful to me. So after about a half hour of searching today, I thought, "Why don't I just make one?" And 15 minutes later it was done.

It's not technically a ruler, but it does measure distances. I am not skilled in the way of graphics, so it is just a console program.

To use it: Run it. Move your mouse over the start. Press left shift. Move your mouse to the end. Press left shift. Then see how far it was.


This has quite a few uses: like calculating the speed of things in videos, or porting games from youtube videos. So have fun measuring.

(Here are the C++ redistributables x86 and x64. If you have a 64 bit machine, I believe you have to install both.)

38
ASM / Perfect Grayscale - Tutorial
« on: March 07, 2011, 11:58:14 pm »
With my recent work on Chess, people have been asking me how I make my grayscale so perfect. So here is a tutorial!

First, a little background, most of it can be read in this topic. A while ago, I made a program that displayed 16 level grayscale pictures. It worked pretty well, but it was clearly not flickerless, it had major scrolling patterns and some spots literally flickered. Then I thought, if I can do 16 with 120 refreshes per frame, why not do 64 level grayscale with 100,000 refreshes per frame. This was accomplished using z-addressing and I put 1 pixels in the first column, 2 in the second, 3 in the third, and so on until the screen was full. Then I scrolled that at 100,000 fps. What I noticed was that at certain frequencies, the images would slow down, stop, then reverse direction and go back into oblivion. After a little bit of playing with it, I figured out that the LCD actually has a refresh rate. And that rate is 60Hz.

This little refresh rate is what causes all of the problems with the LCD. Lets say that you quickly change the screen color, if you've used your calculator long enough, you know that there is a diagonal line going up your calculator for a split second while it is clearing. This is caused when you and the LCD driver are updating the screen at the same time.

The LCD driver has two parts, and each part works independently of the other. First you have the LCD ram, which is just like regular ram. And then there is the LCD driver which updates the screen 60 times per second, at a speed of about 100 pixels / (1/60 second) from top to bottom. In common practice, the LCD ram is filled one column at a time, starting at the left, and working your way across. This operation takes about 1/120 second. What can happen is that while you are updating the LCD ram, the LCD driver decides that it is going to start displaying the screen. It displays 1 row at a time, and as it falls down the rows, it displays whatever is currently in ram. So you can see that if you are updating the screen while it is reading it, there will be some spots where you as the writer will cross over what the driver is displaying, effectively making the driver display part of two different frames.

For your average game, this is no problem, a minor graphical glitch that is only present for about 1/60 second and that only happens about 1 time per second. But grayscale is an entirely different case. This graphical glitch is very obvious because it screws up your careful pixel timing. Instead of ON ON OFF ON ON OFF, sometimes you will have ON OFF ON ON OFF ON, which spread over the whole screen, just looks bad. Also, let's say that you don't know about this whole refresh thing and you update the screen at either 80 fps or 40 fps. At 80 fps, some of your frames are never going to even make it to the LCD, you are updating it so fast that you will update it again before the driver has time to display it. And at 40 fps, some of your frames are displayed twice.


After hearing that, I'm sure there are a few of you that could go out and write your own display routines, but there are also those who can't. Here is an example of what we don't want.

You can see that the LCD driver and the displayer are not in sync and scan lines are clearly present. (Technically since that is in wabbitemu, I had to do something entirely different to get that effect, but you get the drift.)

Now, to get away from this, you have to learn the way of the LCD driver, and try to basically run away from its display line. First off, it displays rows, not columns. So we will obviously have to write a 07 to port (10h), and work horizontally across the screen. This does have some speed drawbacks, but that's just how grayscale goes.

Now that that is out of the way, you will notice that your grayscale routine actually looks a lot better, but we're not done yet. The next step is to get in sync with the driver, which is accomplished with the crystal timers. Our goal is around 60 Hz, so the timer that gives us the most flexibility around this range is timer 40h, it runs at 10922.667 Hz. Then you have to apply your multiplier to it 10922/60 = 182, so a counter of 182 will get you 60 Hz. I of course prefer 178 as that is what my calculator is synced to, but to each his own. (The typical range is about 160-180). To put this into code. 40h to (30h), 0 or 2 to (31h), and 178 to (32h).

That's it, do that and you will have perfect grayscale.

And why did I mention 100 pixels / (1/60 seconds)? That's because you can't perfectly match the frequency of the driver and there will always be a small glitch line. But if you do it right, the line is off screen for 1/3 of the time.

Here's an example of implementing what I just talked about. It's commented quite nicely, but I left it up to you to make your own calibration screen (I don't want all the games to look the same ;))

39
TI Z80 / Chess
« on: February 26, 2011, 08:49:40 pm »
To all the googlers who come through here. The newest version is over at ticalc.org.



My friends at school told me to make chess. So I did.

I started this on wednesday, so it's pretty new. But it's awesome. :D



This is me playing against the calculator. I played in 50% speed, so don't think I'm a chess genius. Some strange stuff happens in that game though, like me castling out of check (legal?), it cheating its way out of checkmate, followed by me losing my queen, and then it forks me with a knight.

Since you're wondering, here is how the AI works. It looks through every single possible move and gives it a rating. It then chooses randomly from the top 4 unless there is one clear obvious choice. This way, you don't always play the same game, but the CPU won't pass up an obvious move. This rating is calculated, as of now, by this formula.

4*capture + 3/2*(threatAgainstCpuFinal - threatAgainstCpuInitial) + (threatAgainstPlayerInitial - threatAgainstPlayerFinal)

Each piece is rated on the usual scale. (pawn = 1, bishop = 3, knight = 3, rook = 5, queen = 9, king = 10) To calculate threat, you look at the sum of the reward of all possible attacks. So if there is a lone rook out in the center, and two different pieces can capture it, the threat would be 5 + 5 = 10.

As far as grayscale goes on this one, I'm trying out a new system. The first time you run the program on your calculator, it asks you to calibrate the flicker and adjust the contrast. Then it stores these values internally and never asks you again. But what makes this one different is that when you send it to your friend, it will ask them to recalibrate it even though you have already done so on yours. How? Along with the contrast and delay, it also stores the calcSerial. So if the stored serial and the real serial don't match, it asks to recalibrate.

In it's current state, this game is very playable. The only thing it lacks is pawn promotion, but I even included en passant. The menus however need serious work, the current ones are just to make navigation possible.

And for those people who will ask, GRAPH quits.

40
TI Z80 / Four Level Grayscale Video
« on: January 28, 2011, 11:46:25 pm »
Yes, that title means exactly what you think it does. I can play 4 level grayscale videos. The videos run at 15 fps and are 12*64*2 = 1,536 bytes a frame. But through some RLE (compressing 00's and FF's) I managed to get compression ratios of about 30% meaning that overall, these videos run at about 16KB/s.

As far as the converting, it is very ugly. First I send a video through SUPER and it spits it out as a series of .jpg's. Then I use a GIMP extension to convert those to .bmp's. Then my converter looks at each picture, decides which colors go where, and spits out a binary which goes through To8xk and Wabbitsign to become an app.

To decide what color to use where, I tried two different strategies. The first was to tally up all the brightnesses of every pixel in the whole video then take the Q1, Mid, and Q3 as the cutoffs for each color. But this resulted in parts of the video that were mostly one color. So used the same technique to calculate the cutoffs each frame and that is what I use now. (But the old way is still possible with the flip of a bit.)

There'll be more videos to come. Even one sync'd with another calculator for sound (bet you can't guess what that is ;)). But for now, you just get to watch me do a Daffy off a jump while skiing.

Edit:
     It looks better in wabbitEmu, so here are the files. (I can't even imagine on a real calc 0.0

Edit2:
     I got too anxious and uploaded an uncompressed video and a decompressing player. Fixed now.

41
Computer Usage and Setup Help / Weird Speaker Sound
« on: January 17, 2011, 11:42:53 pm »
Now, I know I'm not the only one that has ever heard this sound, so someone has to back me up. Sometimes, a speaker will make this certain sound for no apparent reason. It is a a semi-low buzzing type noise that plays a very specific pattern. The pattern is this -..-..-..-... It is a repeating pattern of ..- that plays anywhere from 3 to 5 times. I used to hear this sound come from my friends computer speakers when I was in 3rd-5th grade. Just now, I heard it from a radio in a hotel room. I know I've heard it other places, I just don't remember where.

So, can anyone explain this. I have always wondered what this is, and I figured I would finally ask the question.

Or, if you have ever even hear what I am talking about, some support would be nice. ;)

42
ASM / System Monitor / Context Vectors
« on: November 14, 2010, 06:11:15 pm »
I want to improve solver so that it works like this. A = B. Instead of 0=B-A. And to do this, I am going to have to screw with the system monitor and solver's context vectors. I know almost nothing about these because there isn't much information released about them. But I know that people have the information. So basically, I just need to be filled in.

The sdk, was slightly helpful, along with wikiti. But what I've gathered so far is this. cxMain and the 6 vectors after it are basically a call table. When an event happens, one of the vectors is followed and the code is executed. But each one of those vectors appears to have it's own guidelines just like the hooks do. I can probably figure out the usage with enough debugging, but some notes would be greatly appreciated.

Edit:
    So I'm starting to figure some of it out. It looks like for cxMain, it gives you A = key, and you return the new key to be pressed in A with NZ set if it should be used.

The main thing I'm trying to figure out now is how the screen get's drawn. It doesn't look like cxRedisp ever gets called.

43
OmnomIRC Development / 404 OmnomIRC not found
« on: October 19, 2010, 04:17:03 pm »
It started today, whenever I go to the full screen OmnomIRC it says error 404 not found. Here is a screenshot of the error:

44
ASM / A guide to 28 days
« on: September 20, 2010, 08:31:49 pm »
Like many of you have probably seen. There are a lot of people who want to learn assembly, but they don't want to do it with "Learn TI-83 Plus Assembly in 28 Days." But I really like 28 days as it is what I learned with. The main problem that I found with it though is that it gives a little too much information at one time. So to combat this, I am making my own guide to this guide.

I basically am just going to go through and say what's important and what's not depending on what skill level you are. I will also try to make the process of creating programs as easy as possible. This means taking everything out of the equation except the actual z80 part. (No DOS or TASM to bother with.)

Here is what I have accomplished today. I just learned html today so it's not very complex, but it works.

Tell me what you think.

45
TI Z80 / Star Fox
« on: August 11, 2010, 05:29:41 pm »
For all you googlers out there. Here's the newest screenshot:

And here's the post containing the newest version.



Stop reading. Watch the screenshot VV


That's right, 4 level grayscale, polygon 3d Star Fox. I've only been working on it for about a week so it still has a long way to go, but it's still awsome.

A few days ago, I searched polygon 3d graphics on google, once I got the general idea for how they are stored in memory, I made a wire frame program. I realized how easy it actually was because I had a 3d cube on my calculator in about two hours, so then I thought, star fox? To make this work, it had to be grayscale because without it, you couldn't see anything. To accommodate this, I changed the screen to 48 by 48. Then after a long while of creating an arbitrary triangle and a quadrilateral drawer. I had 3d graphics.

Every thing in the game is super easy to change, I can add new objects, change the level, and make the enemies better. Right now, the enemies suck, but that's because they were the most recent addition.

Here are some general specs on the game:
48x48 screen
60 hz 4 level grayscale
The rest of the screen is updated at 7.5 hz.
Gameplay is held at 15 fps for now.
Each "tile" is 48x48
The tilemap is 9*12. (deeper than wide)

If anyone hates my sprites, I'll gladly accept new ones. Even new enemies that I haven't created yet. Just watch star fox snes on youtube. I'm a programmer, not a spriter.

I'll keep posting progress as it comes.

Pages: 1 2 [3] 4