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 ... 8 9 [10] 11 12 ... 20
136
« on: February 14, 2011, 10:22:27 pm »
This is an area of ongoing work.  I'm not sure which version of TilEm you're referring to. Pre-0.973, TilEm used a very simple method that was strictly limited to 4-level, interrupt-driven display routines, which looks nice for the rare cases where it works at all. Version 0.973 and later used a simple IIR filter, which flickers a bit but does work (to a limited extent) for a much wider range of programs. For TilEm II, I'm working on a completely new algorithm that should work (without flickering) for any frame rate and duty cycle. It's a little buggy still, and does require somewhat more memory and CPU time. I don't know what Wabbitemu provides in the way of tunable settings, but this new algorithm should not require any tuning by the user.
137
« on: February 12, 2011, 10:04:06 pm »
My favorite character? I'd probably have to go with 無(for its geek significance, though the actual meaning of the character is rather mundane) Recently, though, I was amused to discover the character
138
« on: January 30, 2011, 09:43:59 pm »
I wasn't the original author (that was Julien Solignac, aka x1cygnus), but I did add support for the newer models, and a number of other nifty things.
139
« on: January 30, 2011, 09:36:11 pm »
I imagine dithering would help. It might also be interesting to consider adjusting the LCD contrast. And now I'm wondering if there would be enough CPU time to do any more sophisticated decompression.
Also, the Old Spice example looks like it had some serious MPEG and/or JPEG compression artifacts to begin with. Or maybe the conversion is making the existing artifacts a lot worse.
140
« on: January 29, 2011, 11:42:20 pm »
It seems like there should also be syntax for doing the opposite - using a computed value as the target of a Goto or sub(). Perhaps recycle braces for that? (e.g., "Goto {LA}" would be equivalent to "Goto A".) Or would that be too confusing?
141
« on: January 29, 2011, 11:28:40 pm »
dd and od or hd, perhaps? I don't know about any newfangled GUI tools.
(E.g., to show the contents of your MBR in hex: dd if=/dev/sda bs=512 count=1 | hd)
143
« on: January 29, 2011, 12:08:22 am »
Well, if you're only interested in the time of day (not the date), that's relatively easy. Doing it in pure Axe, using only 16-bit math, would be interesting and difficult, but the boot code provides an undocumented routine that you can use to divide a 32-bit number by a 16-bit number. Something like this (untested): Asm(
217884 ; ld hl, OP1
014904 ; ld bc, $0449
0D ; dec c
EDA2 ; ini
20FB ; jr nz, $ - 5
113C00 ; ld de, 60
EFB180 ; B_CALL Div32ByDE
)
{e8486}→S ; number of seconds
Asm(
113C00 ; ld de, 60
EFB180 ; B_CALL Div32ByDE
)
{e8486}→M ; number of minutes
Asm(
111800 ; ld de, 24
EFB180 ; B_CALL Div32ByDE
)
{e8486}→H ; number of hours
would obtain the hours, minutes, and seconds since midnight; I'll let somebody else figure out how to turn that into a string.
144
« on: January 28, 2011, 11:27:37 pm »
I think it's actually the number of seconds since January 1, 1997, and it's local time, not UTC. So not exactly Unix time. Im trying to do something like the Basic GetTimeStr(12) What does that do? I don't remember how the BASIC time functions work.
145
« on: January 28, 2011, 11:22:24 pm »
The number in FAT12/FAT16/FAT32 is the number of bits per entry in the file allocation table, so it's the logarithm of the maximum number of clusters. As a result, FAT16 can't be used for partitions larger than 2 GB; whether it's worth using FAT32 on smaller partitions depends on what type of files you have, but usually FAT16 will be more efficient.
Nobody uses FAT12 anymore except on floppy disks (and I guess hardly anybody uses those anymore.) But doesn't Windows still use FAT16 by default on small partitions?
Maybe it would be useful for somebody to write a partitioning-and/or-formatting tool for the 84+ itself, since small USB disks are getting hard to find.
146
« on: January 28, 2011, 11:07:32 pm »
Somehow I missed seeing this topic before! (For those who don't know, I worked on the original TilEm for several years; now I'm one of the folks working on the long-delayed TilEm II.)
If you're interested in adapting either the old TilEm core, or the new TilEm II core, to run on an iPhone, I'll be happy to help any way I can. The new core is stable (it's the GUI that's currently lacking) and, as far as I know, provides the most accurate emulation of any emulator currently available. It may be a little slower than the old code, though (especially on x86 systems); I really have no idea how it compares performance-wise with Wabbitemu. Apart from the emulation core itself, the TilEm II grayscale algorithm might be too much for an iPhone, and you might want to replace it with a faster and less memory-intensive algorithm.
147
« on: January 21, 2011, 09:38:06 pm »
Distributing TI's 8xu files would be just as much a copyright violation as distributing full ROM images. And it's not Android, but I do have a half-working version of TilEm II on my Neo Freerunner. I put it together a few months ago, just to see if I could; it's somewhat usable, but it needs a bit more tuning in order to run at full speed (mostly due to the phone's slow graphics chip.)
148
« on: January 09, 2011, 06:49:36 pm »
I can't tell about token names for now since I'm kinda tired but using the ones in an entire menu would be a good idea if it's all for the same thing, otherwise with all the renamed tokens it will get hard to find them in the CATALOG since they're not sorted alphabetically.
Yes, that would be great. Is this possible? 
Yes, it is, but I'm not sure whether or how well it's been documented. What you want is the catalog hook(s). One or the other of them - I think it's the second - is the hook that language localization apps use to reorder the catalog. It's been years since I looked at that stuff, though.
149
« on: January 06, 2011, 09:50:07 pm »
SPASM handles this properly, i.e. it only affects label values from that point on, but it doesn't move the location in the output binary.
"Properly" is a matter of opinion... it's a useful feature, to be sure, but it's also rather annoying that it doesn't behave the same way ORG does in every other assembler. In tpasm (and I'm pretty sure I've seen this in other assemblers, too, though I'm not sure which), there are distinct ORG and RORG directives. ORG sets both the program counter and output location (i.e., does the same thing ORG does in most assemblers); whereas RORG sets the program counter but keeps the same output location (i.e., what spasm's .ORG or brass's .RELOCATE does.) I've done the same in miniasm and Mimas.
150
« on: January 01, 2011, 10:56:39 pm »
I must disagree with the placement of Perl. I know many people who program in Perl (myself included), but I can't think of anyone who's particularly proud of it. 
Pages: 1 ... 8 9 [10] 11 12 ... 20
|
Show Posts