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 - Compynerd255
Pages: 1 ... 13 14 [15] 16 17 ... 24
211
« on: March 29, 2011, 04:03:37 pm »
How did we even get on this subject? Let's move this to Randomness if we aren't interested in talking about the gCn direct USB bridge anymore.
Having direct USB connection is quite awesome indeed. I can't use it, but I believe that this will popularize CALCnet enough to where one server won't be enough, and we can have other servers springing up.
212
« on: March 29, 2011, 04:00:24 pm »
Once I get this working completely, I'll probably convert this to an Axe Library or even an Axiom (although I'm not all that good at assembly, lol). I'll post it once I'm able to reliably transport ridiculously long and complex messages.
EDIT: And then I'll write it into Eitrix.
213
« on: March 29, 2011, 03:46:54 pm »
CalcNet and gCn Axioms would be super-fantastic.
And they aren't very hard, either. It's just a few subroutines and a few memory addresses. I could probably write one in my spare time. And gCn uses the same commands as CALCnet. Axiom that supports USB sound.
Or USB input (like a mouse or flash drive).
214
« on: March 29, 2011, 03:33:26 pm »
I'm necroposting on the forum because I redid the basic CALCnet code so that it WORKS!
ClrHome
0→{L3}
Fill(L3, 5
Asm(CD0942)
0→T→A
Repeat getKey(15)
T+1→T
If (L1+275}=0 and (T>A)
.SEND
Asm(CD0C42)
rand^256+128+T→A
Copy(L3,L1+270,5
T→{L1+277}r
2→{L1+275}
128→{L1+276}
Disp T►Hex,":SEND",i
End
If {L1+13}
{L1+14}r→T
Disp T►Hex,":RCVD",i
Copy(L1+7,L3,5
Asm(CD0F42)
End
End
Asm(CD1242)
In this code, two calculators will actually send and recieve frames to each other, synchronizing the T variable.
215
« on: March 29, 2011, 03:24:07 pm »
I am going to email ti i think.
I don't think they will do anything about it. The best solution would be to dissassemble the OS and recode it yourself. But it's worth a shot.
216
« on: March 28, 2011, 07:30:35 pm »
I totally wish I had an 84 Plus. But I don't. * Compynerd255 feels poor.  I am, however, planning on purchasing an Arduino to make a gCn hub for me and my friends. And one of the advantages of using an Arduino or a USBHID bridge is that not only can we connect multiple calculators to the same bridge, but we can also plug it in to a Windows computer without installing drivers, so we can have Calcnet parties at my school.
217
« on: March 28, 2011, 07:12:38 pm »
I really wish I could test this. I only have an 83+ Black Edition. * Compynerd255 feels poor EDIT: Although I could probably get sweet dough by making and selling professional looking gCn hubs for people with no electronics skills. Oh, and it would be sweet if this game was compatible with globalCALCnet. 
218
« on: March 28, 2011, 06:37:30 pm »
Have your calculator be a program. You could do all the normal things such as math from the front screen, except you would have certain code run differently.
For example.
-The graphing doesn't update the screen every frame, thus making graphing at least 5 times faster.
-Somebody should make a faster program scroller. Like jump to row, jump to end, etc. ive been scrolling through this bloody map for over a minute and i still havent gotten to the end.
- You could still run your programs as if it had No-shell running.
-and anything else you can think of.
Another suggestion.
Have a program that will change all your programs to "hidden","archived", or "unarchived"
Every time I get a ram clear, It will make all programs visible again  .
Another suggestion
A program that will defragment your calc as if you just deleted an app. (I have needed to make apps , just to delete them, before. Defragmentation can really help some problems  * Happybobjr winks at Builderboy * Happybobjr is remembering the time when all of his apps were named "Finance..." * Happybobjr was dumb and compiled and ram a subprogram instead of the main one. All of these problems could be solved by writing a new version of the TI-OS. We could hack the OS code in order to optimize the OS routines (such as replacing the slow graphing routine with SafeCopy, and fixing all them bugs). However, note that all of the entry points would have to be in the same locations in order for our programs to work properly.
219
« on: March 28, 2011, 06:31:12 pm »
I downloaded your Axiom and was looking at the ReadME for it, and I found that the program read from external files in archive. While it is still quite useful in this form, I have a feature request: could we read the compressed data inline so that we can package the whole program as a single file, under the 8811 byte limit? Thanks.
220
« on: March 28, 2011, 05:33:38 pm »
What's the hex for storing ports? I'd like to try this page switching thing in Axe.
221
« on: March 28, 2011, 05:31:25 pm »
It's because there is nothing in Str2. After you store the pointer to Str2 in A, you do nothing to it.
Also, what is the data in GDB1? Is it supposed to be in Hex, or Decimal?
222
« on: March 28, 2011, 10:27:17 am »
The idea of checking outside the CPU is actually not a bad guess. I do know that the Apple //e from 1980 used memory locations to reference hardware processes (e.g. you would preform "LoaD Accumulator $C030" to tweak the internal speaker). So, $C000 and beyond could be linked to a reset loop.
223
« on: March 25, 2011, 08:15:57 pm »
How does the calculator even detect that code is running in the "illegal" area? The only explanation that I can think of is that the last two bits on the address bus (the ones that must be on if code above C000 is being executed) are wired into a trigger that causes the processor to jump to the boot code. In other words, the detection is in the hardware itself.
Most likely it is. Remember that we are talking about all of this being in the processor. So the processor knows immediately if the pc is C000h or above.
Which probably explains why the Z80 processor is actually TI's modified version.
224
« on: March 25, 2011, 07:01:24 pm »
How does the calculator even detect that code is running in the "illegal" area? The only explanation that I can think of is that the last two bits on the address bus (the ones that must be on if code above C000 is being executed) are wired into a trigger that causes the processor to jump to the boot code. In other words, the detection is in the hardware itself.
225
« on: March 25, 2011, 06:53:40 pm »
EDIT: Another idea is to have a way to jump to program source from the axe compile menu. I have a lot of programs, so would faster to go through the axe menu to open up my axe programs for editing.
Maybe, when you click on the source program using [X,T, theta, n], you would be given a list of labels in the program, and you could quickly jump to one of those labels in the source (like we do with error handling). I also have another request: See all the errors in the program, not just the first one. Basically, what would happen is that when the compiler hit an error, the program would not compile, but would still go through the code as if it were compiling, looking for other errors. Then, when all was said and done, you can choose one of the errors to scroll to. This would be useful because one error might be the cause of several dozen or something like that. If this creates too much overhead, then it would be nice to have the compiler give you a choice of quitting, scrolling to the error, or running through the source to the next error.
Pages: 1 ... 13 14 [15] 16 17 ... 24
|
Show Posts