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 - Quigibo
Pages: 1 ... 63 64 [65] 66 67 ... 135
961
« on: August 03, 2010, 10:41:32 pm »
You didn't mention my other favorite webcomic: Cyandie and Happiness EDIT: Here's a recent one I thought was pretty funny:
962
« on: August 03, 2010, 08:34:18 pm »
I have no idea, but I changed the date stamp from 1999 to 2010 and it works now.
963
« on: August 03, 2010, 05:37:13 pm »
That was the problem I had with 0.4.0 and was fixed in 0.4.1. There is a bug in the TI-OS that thinks that pages starting with $FF are set for deletion and so it deletes the second page of the Axe app during defragmenting which contains a lot of the important data (like the menu backgrounds which you can see were missing). There is a patch to fix this, and I think that patch is required for TI-Boy to run for the same reason, but I just got around it by simply starting that page with a different byte instead. This couldn't possibly have happened with versions prior to 0.4.x since Axe was a single page app then.
964
« on: August 03, 2010, 05:30:28 pm »
By the way, I've found the source of this problem and all future versions of Axe should be Mac TI-Connect compatible.
965
« on: August 03, 2010, 04:42:39 am »
Well, those with Ndless might have access to a better emulator in the future so that could actually be an advantage. However, you can still link an Nspire with another Nspire if they're both running the same OS version since I think the speeds would be close enough in that case.
966
« on: August 03, 2010, 04:34:09 am »
The way I generally do appvars is like this:
;To read form the appvar:
call Routine_that_Gets_pointer_of_appvar_in_HL ld de,AppDataStart ld bc,AppDataEnd-AppDataStart ;Size of data ldir ;copy the appvar TO your data
;If appvar wasn't found, fill the data area with default values
ld hl,DefaultDataStart ld de,AppDataStart ld bc,AppDataEnd-AppDataStart ;Size of data ldir ;copy the default TO your data
;To write to your appvar:
call Routine_that_Gets_pointer_of_appvar_in_HL ex de,hl ld hl,AppDataStart ld bc,AppDataEnd-AppDataStart ;Size of data ldir ;copy the data TO the appvar
;This is how I hold my variables using this macro I made:
#define VAR(name,size) name: \ .org name+(size)
.org SomeFreeRamLocation AppDataStart:
VAR(MyVar1,1) ;A one byte variable VAR(MyWord,2) ;A two byte variable VAR(MyArray,100) ;A 100 byte array
AppDataEnd:
967
« on: August 03, 2010, 02:16:34 am »
Its a lot more than just the getkey routine. There are other things going on such as the run indicator, silent link checking, and some other OS stuff and that's in addition to what you already have in your interrupt. Its not terribly slow but its certainly noticeable when speed is really critical.
968
« on: August 03, 2010, 01:34:24 am »
Yeah, there are several bcalls for that, but one of them is way too complicated for Axe, the other one i might be able to add that basically just allocates X number of bytes to an OS variable. But every time you do that, you have to update your program pointer (and in fact all pointers n RAM if you're reading from many variables at once) since things move around during memory allocation.
The OS-getkey is definitely a possibility, but it slows down interrupts and produces non-uniform pauses. I think I will use fnInt()r for that eventually so you can choose.
969
« on: August 02, 2010, 10:13:42 pm »
Quite epic indeed, I LOVE it!
Raylin's idea would be cool, but its really hard to read scrolling text. You could make the period when neither level is on the screen longer to have the text scrolling, slowdown and pause in the center, and then continue to accelerate downwards as the next level comes into view, but that's really complicating things. I don't even know if Builderboy is planning to name the levels. It looks great already. I'm curious how a story could be working into this. Would it be like the shift flash game with little messages every so often and then some special levels?
970
« on: August 02, 2010, 09:21:01 pm »
Interrupts are probably disabled or you have a custom interrupt. You cannot use the OS's getkey routine unless the OS's interrupt is on. It's because the key detection has to run in the background.
971
« on: August 02, 2010, 08:02:53 pm »
What makes groups different than programs and the other variable types though? Because I'm pretty sure those can have headers on the page boundary.
972
« on: August 02, 2010, 04:11:34 pm »
Yeah, its E86D7 and E86D8. I'll eventually have useful addresses tokenized so you won't have to look them up manually.
973
« on: August 02, 2010, 06:41:49 am »
I just thought of something really useful that I can't believe I didn't think of before. Its the fact that 2563 = 644. The reason that's so important is that the labels, subroutines, and pointer names were all being stored as 3 byte entries. Once byte for the type and 2 for the characters of the name itself. But since I'm only using a few possibilities; letters, numbers, and theta, I can get away with storing that data in only 6 bits per entry instead of the full 8 bits of a byte. So now the 3 bytes I was using in memory can suddenly hold 4 entries! That means that all labels and pointers can now be up to 3 letters long instead of 2. That one extra character actually allows you to spell comprehensible pseudo-words like sub(BUF) or Lbl MOV. This wasn't a feature I was planning to add, but I just couldn't stop myself once I realized how easy it would be to do.
I don't think I will ever have enough RAM for the 7 character label names like I was planning unless I use the extra ram pages so this will have to do for now, at least its an improvement.
Also, I changed my mind about the Axe include files. They will need a special header beginning with 2 periods instead of 1. That way, you still have the Axe Tokens and eventually the Axe Editor to use when writing the subroutines. But the extra dot will conveniently make them invisible from the compile list.
974
« on: August 01, 2010, 08:13:52 pm »
I've finished the link routines, and they work very nicely but I know there are slight differences between the hardware and I need to make sure I am leaving enough room for variations. To make the routine as fast as possible and therefore usable in realtime games that have a lot of data to send, the routine is time based instead of confirmation based. There is a minimum threshold of 10 T-states (1.7 microseconds) which is enough to give me 100% error free byte sending on 2 linked 84+'s and should be enough between all z80 calcs, but unfortunately the Nspire emulation is too slow. Not sure if there's anything I can do about that.
Anyway, I just need to confirm that this works. If you have an I/O cable and 2 calculators, preferably 2 different types for example: TI-83+ and TI-84+SE, then please help me test this. The receiver should run program A which just relays to the screen and then have the other calculator run program B which sends a random byte. Make sure both the numbers are the same on both calculators and repeat a bunch of times and then switch the roles of sender and receiver.
If there is an inconsistency, let me know which calculator was the receiver, which one was the sender, and the numbers that show up on each screen, thanks!
975
« on: August 01, 2010, 06:28:21 pm »
Libraries might be possible very soon, I just need to make my code sightly more modular so I can read from multiple places at once. I realized a while ago how complicated it would be to implement library files, so it will instead be pretty much identical to the C #include feature that directly inserts the code at whatever position you put it. You can even put each subroutine in its own separate program. The include files will not need Axe headers and in fact should not have them so then it doesn't crowd your compiling list. If its not included in 0.4.2, it will definitely be in 0.4.3
The jumping idea is something I'm planning to add later. Much later. I'm planning on using hooks to add tons of new features to the BASIC editor (only for programs with an Axe header) like label jumping, sprite previews, calculator window without exiting, hex - binary - decimal converters, etc. Really cool stuff, but its something I'd probably write after 1.0.0 comes out.
Pages: 1 ... 63 64 [65] 66 67 ... 135
|