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.
Messages - DrDnar
1
« on: May 27, 2016, 09:02:11 pm »
Oddly enough, the error fixed itself.
That's usually not a good sign. It tends to mean you have (or had) latent bugs. Definitely check for memory leaks and signs of data corruption.
2
« on: May 23, 2016, 11:31:34 am »
Asm(FDCB09A6) just attempts to reset the ERR:BREAK flag. Which isn't happening here.
The Axiom is intended for running external assembly programs. Does the issue with error messages only happen when you run BASIC programs? It's possible the error message isn't being cleaned up properly. From what I read in TI's SDK, you don't need to zero errNo after catching an error. But maybe I misread. Perhaps Asm(AF32DD86) will fix that.
3
« on: May 17, 2016, 11:12:04 am »
That's . . . odd. Can you give me the simplest program that demonstrates the problem? Does running Asm(FDCB09A6 before quitting fix the problem?
4
« on: September 06, 2015, 05:22:52 pm »
I believe that a properly optimized emulator could run significantly faster on the eZ80 units. OS and flash app performance are crippled by an insane number of wait states on flash reads. RAM, however, is less crippled, and there exists the potential to get better MIPS from RAM programs than the old Z80 series could provide. So an emulator that runs entirely in RAM might be able to be much faster, though it would be limited in the size of ROMs it could handle (but at least 256 K).
It's kind of technical, but basically, the eZ80 runs at 48 MHz (the TI-83+SE, TI-84+/SE, and TI-84+CSE ran at 15 MHz), but the bus feeding data to and from the CPU is so slow that the CPU spends about---I'm taking a guess here---80 % of its time idle, waiting for data. Essentially, the benefits of a much faster CPU clock speed are entirely negated by the awful bus performance for code running from flash. The eZ80 models still get a little bit better performance because the eZ80 is also tightly pipelined, such that its performance is limited by the external bus performance; the Z80, by contrast, is limited by both its lack of pipelining and slow ALU. The upshot is that on the rare occasion the eZ80 does get data, it processes it in fewer clock cycles than the Z80, so even with a much slower bus, it can still process data a bit faster. As a bonus, C code on the eZ80 gets a relative boost to C code on the Z80 because the eZ80 is much far efficient with stack frames.
RAM is subject to less than half the wait states of flash, which is partly why display operations are so much faster. Overall, programs running from RAM might be twice as fast as a flash-based apps, which is good news for us, because we don't have an app signing key anyway.
The screen interface is entirely different between the CE and CSE, and display performance is subject to a completely different set of performance rules. The Z80 is ridiculously slow when using the IN and OUT instructions, which were used for talking to the LCD. The eZ80 is far faster with IN and OUT, but TI instead decided to use a memory-mapped display, which is great for some purposes, but actually slower for drawing sprites. Which is odd, because sprite-like drawing is most of what the calculator needs anyway. The memory-mapped display requires a lot of pointer arithmetic, so it's a good thing the eZ80 is considerably faster at pointer arithmetic. The memory-mapped display also uses a DMA that steals about 10 % of the bus bandwidth. Good news, though: the new display supports palletized modes, which use fractionally less bus bandwidth depending on the bits-per-pixel setting (e.g. 4 bits-per-pixel uses a quarter of the bandwidth that the normal 16 bits-per-pixel mode uses).
Somebody should probably put all of that on Wiki or something other than WikiTI, which is only read by programmers.
5
« on: January 13, 2015, 07:19:32 pm »
Some people in Cemetech have speculated that it might actually be Nspire hardware in disguise, emulating a TI-84 Plus C SE with a modified OS.
[cross-posted from Cemetech]
If the new model does indeed use an ARM with a Z80 emulation layer, I suspect there will be a programmer interface for direction ARM code execution, because software development and maintenance costs are much higher for Z80 assembly. They therefore have a strong business incentive to mitigate that with C-based ARM code.
However, I would like to suggest an alternative theory based on the history of TI's previous Z80 line.
In 1996, TI released the TI-83. It provided the correct combination of math functionality for the lucrative high school education market, but limited programmability. Therefore, in 1999, TI released the TI-83 Plus, featuring the same math capabilities, but with enhanced programmability via 512 K of execute-in-place (XIP) flash memory. In time, however, the device proved to feel slow, and half a megabyte proved to be somewhat limited for some students. Therefore, in 2001, TI released the TI-83 Plus SE.
Concurrently with TI-83 Plus development, TI developed the TI-86. The TI-86 addressed limited memory by adding more RAM, but proved unsuited for the high school market due to too-advanced mathematical abilities.
The TI-83 Plus SE featured the same general architecture, but with an entirely new ASIC with a much-improved MMU, the Z80 integrated into the ASIC to reduce chip-count and pin-count, and support for multiple flash chip sizes, going into production with a 2048 K chip. It also secretly featured more RAM, with support for up to 256 K, and perhaps TI wanted to see what 3rd-parties would do with the 128 K that went into production. Somewhat strangely, the TI-83 Plus SE also featured two mirror ports of the LCD ports, possibly suggesting support for a second chip-select line for the LCD driver interface to permit a more sophisticated driver in the future. The success of the TI-83 Plus SE led TI to develop further yet another new ASIC for the TI-84 Plus/SE line.
Released 3 years later in 2004, the TI-84 Plus/SE models appeared to add little new to the TI-83 Plus SE---which was now discontinued---, adding only a USB port and a clock, and the option of either 1024 or 2048 K of flash. Internally, the TI-84 Plus/SE ASIC saved money for TI by integrating the RAM into the ASIC, eliminating an extra chip from the hardware. Moreover, the USB port proved successful, as the older DBUS port was antiquated. TI later posted an update to the TI-84 Plus/SE OS, adding some minor new functionality, which was well-received, but not a market-changer. Then, in 2007, TI, having noticed that the extra RAM wasn't being used much, silently released a cost-saving update to the ASIC, featuring less RAM but otherwise identical. Three years, TI released a significant update to the TI-84 Plus/SE OS: MathPrint. MathPrint addressed significant usability concerns for students, and was well received.
Again three years later, in 2012, market desires were changing again. The TI-83 Plus and TI-84 Plus/SE line were ridiculed for having the same old 90's-era B&W LCD. Therefore, TI slapped a color screen on the same old hardware, and utilized the ASIC's support for multiple flash chip sizes to increase flash to 4096 K. Because the back light for color LCD consumes far more power, TI also replaced the AAAs batteries with a rechargeable LiPo cell, giving us the TI-84 Plus C SE. The OS for the new model required significant changes to support the new LCD, but the overall interface retained the same text-centric design. Overall, teachers and students liked the fancy-but-not-very-useful color LCD, but panned the slow performance and large imbalance between the smaller user RAM and far larger archive.
TI's engineers concluded that the performance issues would be difficult to address, being in-part due to the large large pixel count being driven by a slow CPU. Unfortunately, the Z80 in the ASIC could not be driven much faster, possibly due to the old process node of the ASIC, and the nature of the IP TI was using for the Z80 core. While it would be possible to optimize the OS to run faster on the color LCD, Z80 assembly optimization is not something TI's engineers are good at. While they could increase available user RAM with an OS update, they chose not to, perhaps feeling that it would be too much of an ass-pull.
Given this history, I'd like to suggest the following for the TI-84 Plus CE:
The TI-84 Plus CE is based around yet another revision of the Z80 line ASIC. It again features 4096 K of XIP flash memory, and a Z80-compatible CPU. However, the Z80 is not the same Z80 IP TI previously used. Instead, it is a Z80-compatible CPU with either or both superior pipe-lining and a faster CPU clock speed. Because the CPU is still a Z80-compatible CPU, TI did not need to re-engineer the user interface of the TI-83/84 Plus line, nor license a considerably more expensive ARM CPU IP. The ASIC also features the maximum 256 K of RAM that the 2001 TI-83 Plus SE ASIC specification supports, and TI altered the OS to make much of that RAM available to end-users through changes similar to how the TI-86 supports extended RAM. As TI re-engineered most of the ASIC with a new CPU IP and more RAM, they also likely took the chance to move the ASIC to a newer, smaller process node, reducing production costs through using a smaller die, despite a considerably higher transistor count.
I therefore expect that porting older TI-84 Plus C SE software to the TI-84 Plus CE will not be too difficult. However, porting will be nonetheless be required, because the OS's handling of user RAM changed significantly in order to support addressing more than 32 K of user RAM. Games are likely to be easily ported and compiled for both models, while software that interfaces more closely with the OS's math and user storage functions may require much more work.
Overall, the TI-84 Plus CE is therefore just another evolution of TI's high-school-oriented calculator line. While we may find that being kept in the dark about the new hard is annoying (I bet IQ Joe has a pre-production sample), the new model will likely be very well-received by both the education community and the programmer community.
6
« on: January 10, 2015, 11:32:13 pm »
I fixed a single bug with a single-byte change. After quitting with MODE or graph-var, upon restart, the game might still see the MODE key in the key buffer and immediately quit again unless you held down another key to push something new into the key buffer. The solution was to zero more scrap-RAM.
7
« on: November 27, 2014, 06:42:15 pm »
If they used a stock eZ80 that would be fine, but yeah I guess TI wants to use their own parts to keep the cost low.
That would add an extra chip, and would cost $5 (20 MHz) to $10 (50 MHz) per CPU. It's just far too expensive. The current design has the following digital ICs: - A custom ASIC, containing CPU, RAM, USB, bus, glue logic, charge pump for USB host mode, and lots of miscellaneous support logic. Probably < $3. - Flash chip, for firmware storage. Can't be integrated into the ASIC without changing the manufacturing process, but doing so would vastly increase ASIC size, and lower yield. A 4 MB chip is about $2. - LCD driver, which can't be integrated into the ASIC due to the high pin count the raw LCD requires. Less than $2. - Battery charge controller, which could be integrated into the ASIC at the cost of several extra pins due to the high power handling requirement. Costs less than $1, especially since it's TI's own chip. - Back light dimmer, which has the same objection to ASIC integration. Costs less than $1. You're suggesting that TI literally double the manufacturing cost of the calculator.
8
« on: November 27, 2014, 05:59:26 pm »
I rather hope it's just a TI-84+CSE in a new case, possibly with only 2 MB of flash. It would be neat if they bumped the CPU speed up to 25 MHz---I'd have to buy one. But that would require them to use a much more accurate CPU oscillator. (The old spec for the TI-83+SE was +/-20 %, so 20 MHz + 20 % would put it over the 22 MHz speed limit some overclocked units have seen.) An eZ80 seems unlikely due to the need to license a new CPU core. I look forward to learning more about this.
I personally like the new case design. I was never a fan of the curved rows of keys.
9
« on: November 17, 2014, 01:47:00 pm »
TIcalc.org has much better screen shots of Solitaire. The screenie above just shows that the game deals with a rare circumstance intelligently. (Specifically, where you stack cards in FreeCell super deep. You can't stack them any deeper than what is shown, at least not within the game rules. The stack of cards you see is actually not legal; I disabled legal move checking so I could quickly test deep stacking.) Solitaire isn't an active project; it's a completed project. Yes, I recently released an update, but it's just bug fixes. And they were all bugs that chances are, nobody even noticed.
10
« on: November 16, 2014, 05:36:18 pm »
You should load TI-Boy up, port the emulator to emscripten, and run the emulator in a Bochs so that you can run an emulated GameBoy in an emulated TI-83+ in an emulated in Nspire in an cross-compiled Javascript in an emulated PC.
11
« on: November 16, 2014, 05:11:59 pm »
thepenguin77 is not a coder who believes in commenting code.
12
« on: November 13, 2014, 07:57:23 pm »
I finally got around to writing the code to disable and re-enable USB so USB interrupts can't crash your program/app. It's on WikiTI: http://wikiti.brandonw.net/index.php?title=83Plus:USB section "How to Disable & Re-enable USB to Prevent USB Interrupts from Freezing Your Program/App"
13
« on: November 13, 2014, 07:33:51 pm »
This minor update to Solitaire fixes some minor issues.
Build 1050 (13 November 2014)
- Fixed stack overflow issue that would happen if you played more than 200ish
games without exiting the app
- Prevented a potential issue where unknown behavior could occur if a
GarbageCollect or error occurred during saving
- Fixed bug where saving a FreeCell game would not re-archive the appvar
(Why did this happen? The above change also fixed this for some reason.)
- Plugging in a USB cable no longer causes an abort
- Optimized some code for size
- 238 free bytes remaining
- Unless new bugs are discovered or somebody has a better idea for the face
card graphics, this is the last update.
14
« on: November 09, 2014, 02:57:04 pm »
You could just _InsertMem on 9D95 like the OS does when running a program and copy the second page over into RAM, so that all the code is in the same physical address space. (And, of course, require about 8 K of free RAM to execute.)
15
« on: October 29, 2014, 02:33:03 am »
Would this program be in the form of an OS patch so that no current ASM program need to be modified in order to fix that issue or would this be in the form of an ASM routine released on ticalc.org that people can insert in their respective programs?
Er, a patch seems like a little too extreme a solution. Could you clarify about if an ASM program is left running without crashing, then if the battery is safe or not and if the calculator will just shut down? I might be missing something, though.
It depends on whether the program takes over interrupts. TI checks for the low battery condition in their interrupt handler ---or at least they used to, I should probably check that---, so if their interrupt handler is still active, the OS can see the problem and shutdown. I should definitely look into how TI checks for the low-battery condition so that people know how to make their own interrupt handlers do it.
|
Show Posts