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 - FloppusMaximus
Pages: 1 2 3 [4] 5 6 ... 20
46
« on: December 22, 2012, 04:47:48 pm »
thepenguin77: that won't work unless you disable the OS's key scanning (either by setting indicOnly, or handling interrupts yourself with an IM 2 handler.)
Also, if you're doing something (like text input or a menu) that requires debouncing, you should probably be using GetCSC anyway. The OS's key scanning routine is well-designed, and does a good job of handling all the corner cases that most people never think about. Use GetCSC unless you have a good reason not to (e.g. a game that needs to handle multiple keys at once, or that uses the keys as "analog" inputs) - in my experience, such cases also tend to be the cases where debouncing is not useful.
47
« on: December 18, 2012, 10:44:31 pm »
48
« on: December 18, 2012, 09:09:17 pm »
And I would like to remind everyone that unlocking flash is dangerous and not to be done lightly. But that's a discussion for another time and place.
49
« on: December 18, 2012, 04:47:24 pm »
I'm not opposed to the idea, but I'm pretty sure you're reading that wrong. It's not that execution is allowed on page 80, but that it would be allowed in the first kilobyte of page 82 if the execution limits did not wrap around at 32k (see port 21.)
It's not at all difficult to run large programs on the SE/84+: you can temporarily copy page 80 to page 83 and set port 5 to 3. Of course, you can't use the system USB routines, and of course you need to restore the app base page table afterwards.
Blank lines: visually, I kind of like the use of blank comments instead, since they show you that there's something there (like the colons at the start of lines in the BASIC editor, if you see a semicolon at the bottom of the screen you know there's more to come, but if it's a blank line you know you're at the end of the section.) UI-wise, maybe it would make sense for pressing Enter/Ins to automatically create a blank comment (if you don't type anything else.)
50
« on: December 17, 2012, 09:58:12 pm »
I've released version 0.4 of Mimas, an on-calculator IDE for writing assembly programs on the TI-83+/84+. First, this release fixes a number of long-standing bugs and annoyances: - incorrect definition of fullScrnDraw - plotLoc flag should be cleared upon exiting - div/mod operators - detection of dependency loops - archive-on-exit when multiple programs were edited - support for IFDEF/IFNDEF in asmto8xv Second, I've made a few improvements to the conversion tools: - use a default output filename for 8xvtoasm (instead of standard output) - prompt before overwriting output files - asmto8xv accepts options --case-sensitive, --preserve-case, and --fold-case And third, I've added some new features in the form of "plugins": - library symbols menu - instruction info popup - scroll bar The plugin concept is something of an experiment. The idea is that this way I can add new, optional features, while keeping the base application the same size. I'm interested to see what folks think of this - is it too complicated? Is it worth the (not insignificant) extra effort of continuing to add features this way? As always, I welcome your comments, suggestions, bug reports, flames, etc.
51
« on: December 15, 2012, 01:30:37 pm »
I vaguely remember that issue, but I thought we had fixed it.  (One issue that can't be fixed is that some assembly programs will let you create non-standard Pic variables numbered 10 to 255 - these variables can be transferred using traditional link cables, but the OS and the design of the USB protocol do not allow them to be transferred over USB. There's nothing to be done about that, except, as Lionel says, you can create a group (.8xo) file of them and ungroup on the calc.) --- Lionel, I've sent you a patch that should fix the more pressing issues with Pic (and Str and GDB) files. Compatibility with non-tokenized files (I think this is what you're talking about, DJ) is a little more complicated and will take more work.
52
« on: December 14, 2012, 10:04:07 pm »
Pathetic. No reason for simple validation to be that slow. They should have asked me to write the code for them. 
53
« on: November 20, 2012, 11:16:33 pm »
You're absolutely right, it would be best if programmers could select between several different modes based on which is best for your application. But I find that somewhat unlikely. If it were 8-bit pseudo-color, you could divide up the buffer by planes, and do double-buffered 4-bit graphics within a single 77-kilobyte buffer. (Of course, it may not be possible to change all the palette entries at once, but that should be comparatively fast.) Or you could reserve some planes for storing other data. On the subject of TI-Connect and image conversion... you can be sure that the community will very quickly release plenty of image converters that are far superior to anything TI comes up with. 
54
« on: November 20, 2012, 09:21:59 pm »
The hardware doesn't limit what algorithms you can use to resize or quantize the image. And those are not things you would normally be doing on the calculator anyway. You can use whatever algorithm you like - although, obviously, higher-quality pictures will require more memory, and memory is going to be in short supply. The interesting question is what the hardware actually allows you to display. 8-bit pseudocolor would, I think, be ideal for performance, but TI probably doesn't consider game performance to be their top priority. 
55
« on: November 16, 2012, 11:03:00 pm »
True. I did notice that in the photos we've seen, the graph screen appears to be 256 pixels wide - that would be convenient if it could be mapped to a memory buffer with 256 bytes per row. But if that were the case, where would the left and right "margins" be stored? Perhaps it's just that the OS has a graph buffer that is a convenient size for drawing, and it adds padding when copying that image to the actual framebuffer.
56
« on: November 16, 2012, 10:34:27 pm »
I was assuming it was memory-mapped (that was part of my assumption that "the display is as fast as possible.") If everything has to be done with Z80 I/O instructions like on the older calcs, performance is obviously going to be atrocious.
To elaborate on the idea of "executable sprites" I mentioned, a sprite would be written as a series of PUSH instructions; you would load the desired pixel colors into registers before "calling" the sprite. There are ten 16-bit registers that can be used this way (although actually, you'd probably want to reserve one or two to use for moving from one row to the next), and each push instruction takes 11 or 15 clock cycles and outputs two bytes. Of course, you can get more creative if you want to use more colors at the expense of speed.
57
« on: November 16, 2012, 10:17:47 pm »
Even if the display is as fast as possible, the Z80 will be a bottleneck. Assuming the screen is 8 bits per pixel (a 256-color palette) and assuming a 20 MHz clock rate, the fastest possible drawing algorithms would be on the order of one pixel per microsecond (except, perhaps, to fill the screen with a solid color or pattern.) If you're redrawing the entire screen for every frame, one pixel per microsecond translates to about 13 FPS (and remember, that's if the CPU is doing nothing else.) Programmers will need to be very clever in order to get decent performance from this thing. That said, the programmers in this community are pretty clever.  (Just had a fun thought that contradicts what I said above: executable sprites. If you're willing to reduce your palette to 3 colors at full resolution, or 10 colors at half resolution, you could encode your sprites as Z80 machine code and draw about 1 pixel for every ~6-8 clock cycles. So, like I said, clever hacks.)
58
« on: November 14, 2012, 10:23:59 pm »
You're talking to the guy who released the first free software 83+ SE emulator, in 2004. (I don't remember when SE support was added to the Flash Debugger, though. And there was also an unfinished version of VTI that supported the SE and had some limited Flash support.)
59
« on: November 14, 2012, 09:53:05 pm »
It was somewhat popular for a while among assembly programmers because it supported Flash, while VTI didn't. As the name suggests, it was designed for debugging Flash apps. It doesn't hold a candle to any of the newer third-party emulators, though.
60
« on: November 13, 2012, 11:11:36 pm »
EDIT: Something I am kinda worried about: Kerm mentions something about a charging port in one of the pics. That scares me. What if TI decided to remove USB charging and go the Apple way of forcing customers to buy their proprietary cable that doesn't fit anywhere else than the device if you lose your cable? I hope not, but sometimes we never know...
Good point. I'm guessing that the charging port is a special feature for the "classroom" model (looks like it's designed so you can simply drop the calcs into the charging station.) But it would definitely be better if it could be charged over USB.
Pages: 1 2 3 [4] 5 6 ... 20
|
Show Posts