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 ... 7 8 [9] 10 11 ... 20
121
« on: March 26, 2011, 12:28:43 am »
The protection is associated with "physical" memory locations, not with Z80 addresses; it works the same way regardless of the memory mapping ports. If you try (say, on an 83+ SE) writing 80h to port 6 and then jumping to 4000h, that will crash; conversely, writing 1 to port 5 and then jumping to C000h will not crash (assuming there's some valid code there.  ) As for how it's implemented, it's presumably part of the "glue" circuit that connects the CPU to the memory and other hardware devices; this circuit is part of the ASIC used in newer calculators, but in older calculators, it's a separate gate-array chip. This chip can be thought of as the equivalent of the northbridge and southbridge chips on a PC motherboard.
122
« on: March 26, 2011, 12:09:14 am »
That was me.  And, no, it doesn't take 10 minutes, it takes less than one minute for normal-sized apps. See http://ourl.ca/7447/149857Ducksign lets you send applications from one calc to another (unsigned apps will refuse to do so), but the expiration count will still exist unless Axe changes or unless you sign in on the computer.
That's also not entirely correct. DuckSign signs the application; once it's signed, it's perfectly valid, just as if you signed it using RabbitSign or Wappsign or whatever. The expiration count is not part of the application; it's something that's set by the OS as part of the normal installation process (I don't remember whether it's set at the beginning or end of the transfer, but anyway...) And it doesn't have anything directly to do with app signatures. If you write an application directly into Flash - regardless of whether or not it's signed - without also setting the expiration count, the app will expire after 16 runs. As far as Axe goes, I believe Quigibo has said that he doesn't want to do this in Axe because of the risk of corrupting the calculator certificate.
123
« on: March 21, 2011, 09:57:33 pm »
It means there are 10 bytes there that you might have to back up and restore. I'm pretty sure Mirage has a limit of 10 folders.
124
« on: March 21, 2011, 09:51:48 pm »
Yep. Asm(215AA522BE85) should prevent ram clears. However, it will probably (never tried it) remain in effect until you next turn the calc off, so when you exit your program you might want to Asm(21000022BE85), although it shouldn't doesn't have any nasty side-effects if you don't.
That's an interesting feature, I never knew about that. You are missing some important details, though; while it certainly appears simpler than computing the correct checksum, it also has some weird side effects. For example, you also need to initialize (statVars-2) with the desired boot-time stack pointer. I wouldn't recommend doing it unless you understand the implications. And I myself don't understand all of them. Bear in mind that, whether you use the actual checksum or this A55A trick, you need to ensure that memory actually is in a safe state. If you're writing a RAM assembly program, for instance, you need to free the allocated memory first (or else go through some horrible contortions to arrange to free yourself after the reset.)
125
« on: March 20, 2011, 04:21:22 pm »
FolderBytes = StatVars+5 ;(10) Holds one data byte for each folder, which
; contains the number of progs in the folder,
; (99 Max), and then Bit 7 is used to notate
; if the folder is either Open or Closed.
That's probably what's causing your problems. I don't know why that couldn't have been stored somewhere else (e.g., in cmdShadow, and use statVars for the cached appvar settings instead) but there you have it.
126
« on: March 19, 2011, 04:02:50 pm »
I don't know about Mimas, but when I have a lot of code to write, I'll generally make a program to write it for me.
Exactly. In this case, there's a Perl script to generate the instruction patterns and rules from a simple text description (which I could have done by hand, but writing a script was easier, and probably less error-prone), and another script to compile the built-in symbols (which involves compressing and sorting them, and there's no way I could have done it by hand.) Since the results are generated automatically, I don't think those files count as part of the source code.
127
« on: March 19, 2011, 12:42:07 am »
Mimas is currently 16040 lines, not counting auto-generated files. That's by far the largest assembly program I've ever written. How do you people deal with source code when it starts getting over 4000 lines long? I feel like once it starts reaching this length, I start losing time by searching through the code for routines. At these sizes, the scroll bar is almost useless.
etags. And occasionally grep. And yeah, I'd say 4000 lines is too long for a single source file, no matter what language or editor you're using.
128
« on: March 14, 2011, 12:11:15 am »
... a happy Einstein's Birthday. Oh, and I think there's some other geek holiday happening today, too.
129
« on: March 02, 2011, 10:49:33 pm »
Or maybe all their best Z80 programmers are gone, so there's nobody left who can write a new OS for them.
Or maybe they've decided they're not going to make any more improvements to the Z80 line because they've run out of numbers. What would they do next, a TI-84 doubleplus?
Seriously, it's nice that the past few models have (more or less) preserved backwards compatibility, but I'd like to see something really new.
130
« on: February 21, 2011, 07:34:10 pm »
I don't see anything obviously wrong with that code, though it's a little hard to follow. B7 is 'or a', by the way, not 'cp a'. It would be simpler just to use system routines (e.g., LoadDEIndPaged) to read from the archive. I can't seem to reproduce the problem you're seeing, though. Is that the same version of BatLib that you uploaded here?
131
« on: February 21, 2011, 05:38:17 pm »
What about FindVarNameArc? How does that work exactly?
132
« on: February 21, 2011, 04:17:07 pm »
Certainly after creating a variable, ChkFindSym ought to be able to find it (although that isn't generally necessary, since the routines that create variables also return the VAT and data pointers.) Assuming, of course, that the variable name is valid and unique.
What's the exact code you're using?
133
« on: February 21, 2011, 03:56:32 pm »
Those are good ideas. I'd add that in this case, since there are only 3 possible values, you can save some space immediately by encoding the most common (white) as only one bit, while using two bits for the other two possible values. In the more general 4-level case, you'll probably still see some benefit from Huffman coding (encode the most common value as one bit, the second most common as two bits, and the two least common as three bits.) Also, consider using a more flexible RLE format, since there are many runs longer than 4 pixels. For instance, 0xx to represent a run of 1 to 4 pixels, or 1xxx to represent a run of 5 to 12 pixels (not saying this is optimal - I haven't done the math - this is just to give you an idea.) In the example, the white runs are generally longer than the gray runs; the black pixels are predominantly isolated, so probably not worth using RLE at all. Looking at it from another angle (as it were), you might find it beneficial to encode the difference between one row and the next, rather than encoding each row separately. Try a lot of methods and see what works. Also: ...black, which seems to show up mostly in a single pixel wide, form-defining barrier around the outside of your sprites... This raises an interesting point: if every sprite follows the rigid pattern that each non-empty row begins with n white pixels and one black pixel, and ends with one black pixel and m white pixels, you could take that into account, and encode the beginnings and ends of your rows specially.
134
« on: February 17, 2011, 10:39:18 pm »
I'm glad you guys like it. Bug report:
Mimas sets bufferOnly (in plotFlag3) but doesn't reset it when quitting. Are you sure about that? It shouldn't - it never uses that mode. I've just noticed, however, that it leaves the plotLoc flag set. Maybe that's what you're seeing? (I guess I just assumed that plotLoc would be reset by the OS. Turns out that isn't the case. bufferOnly, however, is reset automatically, so even if Mimas did leave that flag set, it wouldn't cause any problems.) I'll fix it as soon as possible, but just out of curiosity, what sort of problems does this cause?
135
« on: February 14, 2011, 11:37:04 pm »
I don't know about a BE, but for an SE, there are 5 clips holding the case together: one on top, two at the sides of the LCD, and two near the Log and * keys. It doesn't take much force; just stick something thin (a guitar pick works well) in between the two halves of the case and push them apart until the clip pops open. Once you have 4 of the 5 clips open, the case will just fall apart.
Also, for an SE, be sure to remove the keypad cover first.
Pages: 1 ... 7 8 [9] 10 11 ... 20
|
Show Posts