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 - DrDnar
Pages: [1]
1
« on: April 12, 2014, 03:09:31 am »
As some of you may be aware, I've been working on a Solitaire clone for the TI-84 Plus C SE. The game is fully functional, but is lacking face card graphics. The graphics need to be 24 pixels wide by 25 pixels high. I need graphics for the J, Q, and K of each suit. See the attached images for what the game currently looks like, and templates for the current graphics. The areas marked in gray are part of the card's suit and rank indicator, and are not usable. There is enough space remaining in the app for ten 4-color graphics, or twenty 2-color graphics. A combination of the two would also work (e.g. eight 4-color graphics and four monochrome graphics), and might produce the best result, since there isn't enough space for twelve 4-color graphics.
Yes, you get a credit on the about screen.
EDIT: There's going to be over 1500 bytes left without the graphics, and each 4-color sprite would be about 150 bytes, so there's space for ten---not eight---4-color graphics.
2
« on: March 13, 2014, 04:38:08 am »
As some of you are aware, for the past month, I've been working on a combination Solitaire game, containing both the popular Klondike kind found on most versions of Windows, as well as FreeCell. Today, I present a working beta. Title & options screen:  Playing game:  I've managed to win a game twice, including on hardware. However, there is still much work to do. There is no scoring code (though you can indeed switch between draw-1 and draw-3 modes), the FreeCell mode isn't implemented at all, there are no graphics for the high-ranking cards, the save feature isn't implemented, the undo feature isn't implemented, and there is no code to detect the win condition. If you find any bugs, you may report, but only if you can reproduce them. Which is difficult, considering that the RNG is not only implemented, but well-designed to prevent the same game from being generated twice. EDIT: You can find the latest version and good screen shots at ticalc.org .
3
« on: June 25, 2013, 08:16:04 pm »
For years I've been generating my own fonts for various projects using a font editor I made as one of my first desktop applications. Recently I decided to rewrite it from scratch, cleaning up its code significantly. This new version lets you generate fonts for zStart and Omnicalc. It can also generate .asm files matching the font format used by MicrOS for the TI-84+CSE, and I threw in three custom formats Zeda uses. It's easy to add new formats, and I'd like to add .FON support sometime. However, because this program is also the final project for a class assignment, the source will not be available until later this summer. Due to .NET reflection abuse, this requires .NET 4.5 or above and therefore Windows Vista or above. EDIT: After 13 downloads, I've created an updated version; see post below.
4
« on: April 25, 2013, 09:54:01 pm »
As most of you probably don't know, two years ago I wrote flash editor utility for the TI-84+/SE. The TI-84+CSE has prompted me to revive the project and rewrite most of it. MicrOS now functions on the TI-84+CSE and has the three vital utilities you'd want to see in a Calcsys replacement: port monitor, hex editor, and disassembler. Additionally, MicrOS, once loaded into RAM, does not use ANY B_CALLs; MicrOS has its own set of keyboard, screen, memory, and flash routines. Thus, you can use MicrOS to edit any part of the OS without fear of crashing MicrOS.
To run MicrOS, copy both MICROS and MILO to your calculator. Make sure MICROS is archived! Unarchive MILO and run it with the Asm( command. MILO will archive itself, load MicrOS into RAM, and transfer control to MicrOS. You'll notice that, because MicrOS doesn't use the OS display routines, it feels faster than the OS.
This initial beta release of MicrOS does not feature full functionality of the hex editor. In particular, the user interface side of the flash editor has not been implemented, nor has the find feature, nor the text mode of the hex editor. Currently, I am requesting comments before continuing major development. In particular, I would like opinions on whether to keep the existing font, or move to a 5x7 font with 2x upscaling. The 5x7 font would make displaying text about 40-50% faster, reduce the size of the font data set by over 1.5 KB, and be a lot uglier.
5
« on: March 12, 2013, 07:57:19 pm »
Although we know a lot about the TI-8x ASICs, there still remains significant work to be done. Recently, I have discovered something new that needs to be confirmed. You can help confirm this by typing in the following program and posting your results. This test can be performed by TI-83+SE, TI-84+, and TI-84+SE users; the TI-83+ is not relevant. If you have a MathPrint OS, disable MathPrint before trying this and clear the homescreen. The information from this test relates to port 27h and is realted to accessing the extra RAM pages. It may be of use to operating system writers, assembly programmers, and Axiom writers. :AsmPrgm
:DB156F2600
:EF0745EF2E45
:F31E801686
:0E052100C173
:ED51723EFF
:D327463CD327
:ED79FB260068
:EF0745EF2E45
:C9
(For assembly experts:) ; Yes, I know you can optimize this by at least two bytes.
in a, (15h) ; DB15
ld l, a ; 6F
ld h, 0 ; 2600
b_call(_DispHL) ; EF0745
b_call(_NewLine) ; EF2E45
di ; F3
ld e, 80h ; 1E80
ld d, 86h ; 1686
ld c, 05 ; 0E05
ld hl, 0C100h ; 2100C1
ld (hl), e ; 73
out (c), d ; ED51
ld (hl), d ; 72
ld a, 0FFh ; 3EFF
out (27h), a ; D327
ld b, (hl) ; 46
inc a ; 3C
out (27h), a ; D327
out (c), a ; ED79
ei ; FB
ld h, 0 ; 2600
ld l, b ; 68
b_call(_DispHL) ; EF0745
b_call(_NewLine) ; EF2E45
ret ; C9
Run this like a regular assembly program. It should print two numbers. The first will is the ASIC ID and will be either 51 (TI-83+SE), 68 (TA2), 69 (TA3), or 85 (TA1, what all new calcs have); the second will be either 128 or 134. If you don't mind causing a RAM reset, there's a second test you can perform. This test is related to custom interrupts. The test will cause a crash, hang, freeze, or otherwise errant behavior if it fails; if it passes, the busy indicator will keep scrolling until you press CLEAR (give it half a minute or so). If the above code printed 69 for the first number, this should pass if I'm right. If I'm right, all other values will cause a crash. Do not use any shells. Doing so is likely to cause a false negative. The test is simply this: :AsmPrgm
:FBED46FD3421
:10FBEF1840
:FE0F20F1
:ED5676C9
Assembly = _: ei \ im 0 \ inc (iy+asm_flag1) \ djnz $-3 \ b_call(_GetCSC) \ cp skClear \ jr nz -_ \ im 1 \ halt \ retIf this test passes with the first number from the above test being anything other than 69, let us know; it could provide a great optimization for Axe.
6
« on: February 19, 2013, 12:29:21 pm »
Community members critor and KermM have received preview units of the TI-84 Plus C Silver Edition. So, over the weekend (and all of today, for KermM), BrandonW, calc84, critor, DrDnar, and KermM been working to get simple assembly programs running on the TI-84+CSE. We made significant progress, and have discovered the following: - The ASIC is exactly the same as the TA3 ASIC on the TI-84+/SE, where port 15h reads 45h.
- Consequently, the CPU speed is still 6/15 MHz.
- There is (again) 128 KB of RAM.
- The TA3 ASIC has always supported 4 MB of flash. It's accessed by writing to ports 0E and 0F. (There's a mystery solved.) There might be support for 8 MB chips, too, but TI seems unlikely to release a such a calculator.
- The screen controller is an ILI9325 or equivalent (http://www.adafruit.com/datasheets/ILI9325.pdf) and is permanently attached to the screen unit.
- Graph screen background images are 16-bit color, uncompressed, but are scaled up 2x for display; the actual data size is 133x83.
- The pixels are likely non-square: the old resolution is 96x64---a 3:2 ratio---and the new one is 320x240, which 4:3. So, the pixels will likely be about 9:8, or 1.125.
The UI feels a little bit sluggish; indeed, simple calculations suggest that this is because the 15 MHz Z80 is just not fast enough to drive such a large display. Adding a faster CPU mode like 20 or 25 MHz (like the TI-83+SE was originally intended to support) would go a long way toward making the UI feel more responsive. Alternatively, a lower-resolution display, automatic 2x or 3x scaling, or a palette-based or grayscale 8- or 4-bit color mode would also do the trick, or perhaps TI could even switch to the fully-pipelined eZ80. More technically, the controller only accepts 16- or 18-bit color, meaning 2 to 3 writes per pixel. Outputting a single pixel takes at least 29 clock cycles (for filling the screen with a single color). By contrast, the old controller needed about 100 clock cycles per write, but each write could send 8 pixels, so each pixel only averaged 12 clock cycles. So it takes three times as long to write a single pixel (if you want actual graphics), and the screen has 12.5 times as many pixels. The old controller can accept 120 96x64 frames per second (but it only displays at 60 fps); the new one, displaying only a shrunken 96x64 subsection, can only manage 60 fps. So, the maximum frame rate for full-screen display is 7 fps (0.15 sec/frame), and that's only possible if you're filling the screen with a single color. In practice, 5-6 fps (about 0.2 s/f) is the best you can possibly get for full screen graphics. Critor ran a CPU test program that DrDnar wrote, which was the first program to produce screen output, and the first to produce troll output: http://tiplanet.org/forum/gallery/image.php?album_id=144&image_id=2100&view=no_countKermM is already working to add TI-84+CSE support to jsTIfied. Given that he has a head start and the only major changes are screen-related, he's likely to claim the honor of being the first to add emulator support; however, there is also word of competition from the TilEm team. EDIT: To clarify, when I said "competition from the TilEm team", I meant that FloppusMaximus has also been in on the action, although he keeps quiet about it.
7
« on: December 19, 2012, 12:31:20 pm »
As far as I know, nobody has yet written a routine to detokenize the output of the Axe input routine. I'm a bit surprised, because the routine is pretty easy to write. Below I have posted my implementation. It is rather large, because I just threw it together tonight and haven't optimized it at all. Maybe I will work on that tomorrow, maybe I won't. You could definitely shrink it by at least 10%---probably more like 30%---if you removed the local stack variables and did something more fancy.
UPDATE 14 January 2013: Fixed a bug in the Axiom, specifically a bug in the buffer overrun check. It was accidentally hard-coded for a fixed buffer size of 256 bytes because an arithmetic error. Also shaved two bytes off the routine.
Here's a sample program that just redisplays whatever you type in:
:.AA
:#Axiom(DETOKENI)
:input->A
:Detokenize(A,L1,128)
:Disp L1
Following is the readme.
====== Detokenize( =============================================================
The Axe input command is small, but it returns data in the OS's tokenized
form. As far as I know, there is no built-in system for limiting what the user
can enter. The input command allocates a temporary variable in user memory to
hold the user's input. This may or may not be an advantage for you. The
temporary variable is a legitimate system variable, inasmuch as it has a VAT
entry and is length-prefixed. However, the OS will automatically delete the
temporary variable for you when your program ends, so you do not need to worry
about leaking memory.
The Detokenize( command uses the String>Eqn( token as its key. The token is
located in the Catalog and is not in any other OS menu. This routine is about
115 bytes.
Detokenize( takes three arguments: The pointer returned by input, a pointer
to where you want to store your output, and the size of the output buffer.
Detokenize( does not return any status information. If the detokenized string
cannot fit into the output buffer, the last full token that fit will be the last
token in the string. The output is zero-terminated, which is what the Axe Disp
command expects.
It is not safe to point make the output overwrite the input. Many tokens
expand to more than one character, so the detokenized text could overwrite the
input token stream.
Detokenize( can also be used to detokenize equations, strings, BASIC
programs, your Axe program's own source code, &c.
====== CleanAll() ==============================================================
The input command creates a temporary variable in RAM. This command uses
the CleanAll B_CALL to erase all temporary variables, including the one created
by input. This is not necessary, but may be useful if you want to make sure the
RAM is free so you can do other things.
The key for CleanAll() is ClearAllLists. This routine is 3 bytes.
====== IsA2ByteTok( ============================================================
This command is useful for parsing tokens yourself. It returns 0 (false) if
the input byte is a one-byte token. It returns 1 (true) if the input byte is
the first byte of a two-byte token. The high byte of the input argument is
ignored. This wraps the IsA2ByteTok B_CALL.
The key for ISA2ByteTok( is Fpdf(, under DISTR. This routine is 9 bytes.
====== Get_Tok_Strng( ==========================================================
This command is useful for generating detokenized strings yourself. It
calls the Get_Tok_Strng B_CALL to get the string for a particular token. The
input is a POINTER to the token to get the string for. Thus, if A points to the
token you are processing, you do Get_Tok_Strng(A) to get the string for A, not
Get_Tok_Strng({A}). The string is stored into OP3 (address 848E in hex). The
string is not zero-terminated. Instead, this routine outputs the length of the
string.
The key for Get_Tok_Strng( is Fcdf(, under DISTR. This routine is 13 bytes.
8
« on: April 08, 2012, 11:20:32 pm »
Run Programs Axiomhttp://www.omnimaga.org/index.php?action=downloads;sa=view;down=786This Axiom lets you run other assembly/axe programs from any Axe program or application. The program can even be archived. This lets you break down your program or application into smaller parts that can live in the archive. Additionally, it also lets you catch errors that the OS may throw; that is, it lets you prevent that ERR: screen from showing up. See the readme for more details. Protip: Since the Axiom itself always has to check for error conditions like low-memory and the subprogram not existing, you don't have to check yourself. Just wrap the RunPrgm() call in an error handler, and the handler will only be called when there's an error.
9
« on: March 06, 2012, 02:52:08 am »
I thought that some Axe programmers would find it useful to be able to run archived programs. Also, the Asm( sequence I posted to run programs in RAM will leak memory if the program you call throws an error. So I wrote an Axiom that lets you run other assembly/Axe programs and fixes memory leak issues. If you want, there's even a provision in there that lets you prevent your subprograms from being run from anything other than this Axiom, in case they do nothing useful on their own. Additionally, it also lets you catch errors that the OS may throw; that is, it lets you prevent that ERR: screen from showing up. The attached ZIP file contains the Axiom, its source code, and all the documentation. I'm a little afraid that the part of the documentation about error handlers is a little unclear, so if you're confused, feel free to ask questions.
Quigibo and Runer112: Feel free to optimize this---I'm sure it can be---and put it in Axe.
Here's an example. Let's say you have a fancy intro screen that's very large. You want it to run if the user has it---regardless of whether it's archived or in RAM---, but you want your program silently to skip running the intro screen if it doesn't exist. Just put this code in the main program:
:AppOnErr(LSKIP)
:RunPrgm("prgmINTRO")
:AppOffErr
:Lbl SKIP
:Your program continues here
10
« on: July 15, 2011, 06:24:50 pm »
Axe Undeleterhttp://www.omnimaga.org/index.php?action=downloads;sa=view;down=692An undeleter written in Axe that can undelete all variable types except groups. It does some pretty wacky things, such as abusing the files feature and doing shifty things with the VAT. It's far larger than my assembly undeleter, but this is exactly what you need if you need to undelete a picvar, list, string, or something else that isn't a program or appvar.
11
« on: July 14, 2011, 05:11:29 am »
Remember how in IM 2, the high byte comes from the I register and the low byte of the address for your ISR is random? That may have been true for the TI-83+, but I don't think it's true for the TI-83+SE and TI-84+(SE). A while ago, I did some tests on my TI-84+SE that suggested that in IM 2, the only vector that ever gets used is the FF one. Now, once again, I have written a slightly more advanced tester, based on MicrOS, to keep track of what vectors are issued. Attached is a program for this and its source. Be aware, this program erases all of your RAM. Run the program, and you just get a basic hex editor, starting at address 6200. Address 6200 is the start of a table keeping track of how often a particular IM 2 vector is used. Each entry is two-bytes, so to check how often 20h was used, go to 6240h. The only vector I have ever seen is FF (63FE). Does anybody else with TI-83+SE or TI-84+(SE) ever see a non-zero value in the 6200h to 63FDh range?
12
« on: July 10, 2011, 08:40:31 pm »
IntroductionIn the past few weeks, we've resolved many important mysteries concerning the hardware of the TI-83+ series of calculators. However, there are still questions remaining. There are three questions that I cannot answer without amassing data from other people. They are: - What does port 15h mean?
- What does port 3Ah mean?
- Do the autoselect commands work on all units?
- Is the boot sector of the TI-83+ locked by the flash chip?
By giving me some simple information and running a small program on your calculator, you can help answer these questions. People with any model, from the TI-83+ to the TI-84+SE, can help. Skip to the How to Help heading if you're super lazy or just have no curiosity. Current TheoriesPort 15h has a non-zero value on the TI-83+SE and above. Its value never changes on any one particular unit, but it seems to be different on different units. Also, I've heard nothing about its value on a TI-83+. I think port 15h may be some kind of ASIC hardware version indicator. To verify this, I need data from many units. I'd also like to know whether it reports anything of interest on the TI-83+. By request of thepenguin77, I've added a test concerning port 3A. It has something to do with USB. DanE (the prophet from the Kingdom of USB) believed it was a USB driver revision ID. We may ask you additional questions if we see an interesting value, because we have some evidence to indicate that it means something really important. Similarly, I need data from many units too see if the autoselect commands work. I'm particularly interested in the TI-83+, because autoselect hasn't been tested on it. What is autoselect, you ask? It's a special command that allows you to query the flash chip for its manufacturer ID and device ID. The manufacturer ID will probably change from unit to unit, but the device ID should be the same for all models: - 23h or 0B9h for the TI-83+
- 0DAh for the TI-84+
- 0C4h for the TI-83+SE and the TI-84+SE
Previously, we used port 21 to distinguish between the TI-84+ and the TI-84+SE, but port 21 can be programmed to lie. If autoselect is reliable, we have a way to be certain. (I also believe that the TI-84+ and the TI-84+SE and fully identical except for the flash chip.) Finally, you may be aware that we've succeeded in unlocking the boot sector of the TI-83+SE and TI-84+/SE. <technical stuff> However, the hardware of the TI-83+ is different. We're not sure if the boot sector on that model can be unlocked. The data sheet for the flash chip says that the chip can be configured, using a piece of hardware known as an external flash programmer, to permanently lock any combination of sectors from being written to or erased. The TI-83+SE and above don't use this method of protection, and it's possible that the TI-83+ doesn't, either. The bad news is that this can only be undone by applying 12 V to one particular pin. </technical stuff> The good news is that there is a way to find out whether or not the flash chip's internal protection--and therefore if the boot sector can be changed--is being used: there is one additional autoselect command that allows you to query whether any particular sector is has been protected with the flash chip's internal protection. If the boot sector of the TI-83+ is locked with this protection, it will return 01; if not, 00. If you get a 00 on a TI-83+, then there may be a way to unlock the TI-83+'s boot sector. How to HelpFirst, answer a few questions about your calculator. - 1. What is the model? (TI-83+, TI-83+SE, TI-84+, or TI-84+SE)
- 2. What is the HW revision? (This is the last six digits of the serial number on the back of your calculator. Mine is S-0605D.)
- 3. Do you need ALCDFIX? If you've never had any issues with corrupted graphics in games, you don't need it. Optional: If you do need ALCDFIX, how much delay does it add? (check ports 29 and 2A in Calcsys) Just say "yes" if you have a TI-83+.
Next, run the attached program (hwtests.8xp) on your calculator, using the Asm( token found under 2nd+0. The source is attached below, too. This program will report some information: - 4. The program version number
- 5. Do you have the full 128 K of RAM?
- 6. The value in port 15
- 7. The value in port 3A
- 8. The manufacturer ID and the device ID returned by the autoselect commands
- 9. The protection status of sectors 1F, 3F, and 7F
Post your answers here. Mine are - 1. TI-84+SE
- 2. S-0605D
- 3. No LCD issues.
- 4. Version #2
- 5. Do you have the full 128 K of RAM? Yes.
- 6. The value in port 15: 45
- 7. The value in port 3A: 00
- 8. The manufacturer ID and the device ID returned by the autoselect commands: 04 (Fujitsu) C4 (2048 K chip, top boot)
- 9. The protection status of sectors 1F, 3F, and 7F: all 00
Other MysteriesThere are still other unknown ports. If you have hardware that can supply your calculator with a carefully variable voltage (from 2.9 to 5.0 VDC), let me know and I'll send you another program. I believe that the calculator can test the voltage down to at least half a volt of accuracy by writing to port 04, but I don't have the hardware to test this. Other unknown ports are listed at WikiTI.
Pages: [1]
|
Show Posts