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 - thepenguin77
Pages: 1 ... 7 8 [9] 10 11 ... 108
121
« on: May 07, 2013, 04:35:04 pm »
Not sure if this has been asked for before, but would it be possible to bring omnicalc's line-clearing behavior to the program editor?
What it does is if you go to the middle of a line and press clear, it only clears after the cursor.
That probably isn't that hard to implement. In fact, I believe the OS first does an omnicalc clear, and then backtracks the cursor. So I could probably just use the first part of their clearing routine.
122
« on: May 06, 2013, 11:59:55 pm »
I've found that some of the ion routines don't quite work as i thought, for example ionPutSprite doesn't seem to be drawing to the gbuf. I think it's because you have ld de,$FE79 (TilEm2 calls it symTable+19) instead of ld de,($FE79) in the putSprite routine. I haven't tested out the 83+ version yet, but i'll do that soon  Thanks for the update!
Oops, fixed that. Tomorrow I'll probably upload the version to ticalc.org, so that will have the update.
123
« on: May 06, 2013, 11:45:31 am »
Nice idea, and how did you restore your impossible game files 
I disassembled it with IDA almost immediately. Since I had just written it, I was able to get all of my labels and variable names back to what they were originally, but the formatting of the whole thing was a mess. About a year later I wrote a program to remove all of the stupid comments and put it back in the format that I write programs in.
124
« on: May 05, 2013, 06:58:52 pm »
A long time ago, I accidentally deleted the source to my Impossible Game with a batch file. Since I did it with a batch file, it didn't go to the recycle bin and was gone forever. This is a backup technique that would have prevented that from happening. This won't protect you from hard drive crashes and the like, but it's so simple that you really have no reason not to do it. Step 1: Make a folder somewhere far away from your sources folder My sources are C:\Asm\Sources so I made C:\Backups (a different drive would have been better, but oh well) Step 2: Edit your asm.bat (or whatever you use) to include this line to copy whatever source you are compiling into that folder Mine looks like this: @echo off
copy c:\asm\source\%1.z80 %1.z80 > nul
copy %1.z80 c:\backups\%1.z80 > nul -- this is the new line
spasm %1.z80 c:\asm\exec\%1.8xp
del %1.z80 > nul
time /T -- displays the current time, also a good idea
Done! What this protects against: - Deleting a source file
- Weird .bat file mistakes
- Deleting your source folder (!)
- Saving over your source file (as long as you don't assembling the new one)
What this doesn't protect against: - Deleting everything in the file, saving, assembling
- Hard drive crashes
- Losing your computer
So, while this isn't the most thorough option, it would have prevented me from losing my source.
125
« on: May 03, 2013, 05:25:05 pm »
Ok, so an easy way to determine what the calculator is doing when the screen is off is to press some buttons.
Boot into the calculator with battery+DEL and then:
1. Press any button besides ON - if the screen turns off, then the boot code is immediately throwing a link error
2. Press ON, then press any button besides ON - if the screen turns off, then the boot code is indeed waiting to receive an OS
3. If no amount of button mashing can get the screen to turn off, then you've got some serious problems (or you incorrectly entered battery+DEL)
When I do step number two and mash a couple of buttons the screen turns off. What does this mean?
maby low baterries...
no just fun
you turn it on and send a new os (ti connect is in sending os better then TiLP)
I let the calculator said about a week without any batteries including the hidden one. I bought all new batteries and place them in and I get the black screen. I don't know how to fix this. What do I have to do?
Taking it back to the store seems to be the best option, assuming you still have the warranty. This looks like a hardware problem.
Just so we can get some clarification. Is this what happened? 1. You have the same black screen issue 2. When you followed my instructions, you were greeted with a black screen that could be eliminated (calc turned off) by pressing a few buttons If this is the case, then everything on your calculator works except the screen. I don't think any amount of software fixes are going to correct your problem. So yes, find some way to get money for it. (Store, warranty, ebay (people buy broken calcs), etc.)
126
« on: May 03, 2013, 12:07:42 pm »
Just caught up on the last 9 pages and updated, looking good
Tho it might be worth changing the text in-app for the version number 
Oops, I thought I changed that. So are there plans to integrate/do something similar to xeda's MenuKey? On+# doesn't do anything in the program editor anyways.
You know, what I should do is have a separate set of shortcut keys for the program editor. This shouldn't be too difficult. It'll be a little sketchy when you save them, but other than that, I don't see any major problems.
127
« on: April 29, 2013, 09:13:18 pm »
Well, I spent all day on this. But here's what I came up with:
ld a, $98
ld ($9900), a
inc a
ld i, a
ld h, a
ld d, h
ld bc, $100
ld l, c
ld e, b
ldir
ld a, e ; e is 1
bcall(_setXXOp1)
bcall(_decO1Exp)
ld hl, data
ld de, $9898
ld bc, dataEnd-data
ldir
im 2
bcall($4744) ; basic getkey, stores it in op2
in a, (04)
and 8
jr z, isOn
bcall(_zeroOp1)
isOn:
bcall(_fpAdd)
bcall(_stoAns)
ret
data:
ex af, af'
bit 1, (iy + 8)
jr nz, $+4
im 1
;$$:
in a, (04)
and 1
jr z, noProblemHere
xor a
out (03), a
ld a, %00001011
out (03), a
noProblemHere:
ex af, af'
rst 38h
ret
dataEnd:
If you wait a couple hours, someone will make this a lot smaller.
The way it works is that you call the program (attached) just like getKey, everything works exactly the same except that if ON is being pressed, it adds 0.1 to the number. You only have to call it once to block the ON button. It will unblock itself when your program quits (and it may even unblock in input, though, I haven't tried).
(The reason it took all day was because I had a rather fatal error in zStart that prevented this from working.)
128
« on: April 29, 2013, 09:06:19 pm »
Kind of update:- fixed the issue with it freezing on inputs
- fixed crashing when trying to install on the wrong OS
- fixed (probably) the C000 issue a few people had on 83+BE's
- fixed an issue involving interrupts and port (07)
Stuff I intend on fixing later: I came across this "bug" multiple times now:
When you turn off the calculator while you're editing an archived program (the copy of one), and zStart wants to store the edited version and GarbageCollect appears, the LCD turns off and and it doesn't react on any key presses (calc behaves like turned off, but it isn't) before you can do a GarbageCollect. You need to remove the batteries and lose the current progress which is kinda annoying :/
Is there someway you can prevent the calc (or its peripherals) from turning off when the program isn't saved yet?
Can we have find|replace?
I found another bug with Axe compilation. Unlike Axe, zStart doesn't check whether a program is compilable or not, so you can accidentally compile another source file (e. g. a file with subroutines etc.) which is not meant to be compiled as the main program by Axe. It causes Axe to crash or compile another program (like the one directly above or below (?) in the program list). Of course you can avoid this by not doing the On + Sto-> in the wrong place but it happened multiple times when I didn't watch out.
If after a few days, there are no glaring mistakes in this, I'll upload it to ticalc.org finally.
129
« on: April 16, 2013, 12:34:17 pm »
Ok, a question for people who know a lot about TiLP on 32 bit systems. Where are the .inf files stored? CalicoZac's problem was that he didn't delete the old .inf's and for whatever reason, they were overriding the Ti-Connect ones (in hindsight, I think this is because he used some power uninstaller on TiLP). But, the problem where you get "locate libusb0.sys" is definitely caused by those .inf files remaining. In other news, since it is hard as hell to find, I'm going to link and attach for download a zip with tiehdusb.sys and silvrlnk.sys in it. It's off of TI's web site, but, unless you try really hard, you'll never find it. Link: http://epsstore.ti.com/OA_HTML/csksxvm.jsp?nSetId=68549(Awkward wording above was to try to match people's searches on google)
130
« on: April 10, 2013, 04:14:18 pm »
Oh, ok. No need to look, I'll just explain it. There's this register called r, and it actually has a really complex use, but don't worry about what that is.
You can read it with "ld a, r". The low 7 bits (numbers 0 - 127) will be essentially random. The upper bit will be whatever was last written to r. But the idea is that as long as you aren't in a tightly looped routine, r will be kind of random. (Though, there might be a pattern)
131
« on: April 10, 2013, 03:46:26 pm »
I made one of these a while ago, it was a good time and now I know how to solve them. Anyways, since it looks like you're new to programming, I have some suggestions: 1. bcall(_runIndicOff) - just add this to the top of your program and you'll be happy 2. A scrambler won't be too difficult to make . Since I believe there are unsolvable positions in this game, you should just make a scrambler that simply fakes a bunch of random key presses. I think I used 25. This way, the board is randomized, but still solvable. (Since you probably learned using 28 days, why not give the "r" register a go for your randomizer) 3. If you end up playing your game a lot, you might get tired of moving the cursor around. So as programming practice, and just to make the game easier to play, you should link each square to a button on the keyboard. Just pick a 4x4 grid of buttons and hardwire them to squares. 4. Also Light's out had a 5x5 grid I believe Also, congratulations on making your first assembly game. Making games is the best way to get better.
132
« on: April 06, 2013, 01:16:45 pm »
Yay, an actual question about assembly! (I love answering these) 1. You do not need to reset the port back to $FF. I know at one point I had trouble with this, but that was ages ago (I don't think I was timing it right) 2. You absolutely do need a delay. At 6.5 MHz, you might be able to sneak by every now and then, but honestly, just throw a "ld a, (de)" between your out and your in. It's only 1 byte and gives you 7 t-states. For 15MHz, you'll need more than that. I've historically used 16 t-states for 15MHz so to keep with the optimized delays, you might want to do a "push af \ pop af" or something. 3. Simple, bit 3 of port 4. ( WikiTi)
133
« on: March 24, 2013, 10:23:24 pm »
If you really want to see how to write to flash, you should take a look at how the boot code does it. (Attached) (The random sub_48c5 runs the routine that IX is pointing to in ram).
The boot code does a pretty good job of flash writing, so, you don't have to copy the code line by line, but, in the end, yours should look pretty similar.
And like xeda said, reading from flash is no different than reading from ram. Just swap the page in and go. (Using ports 06 and 07 of course).
Before you get too far in your OS, I would definitely suggest you disassemble the boot code and at least disassemble the boot path through the OS. There are a few reasons I say this, and here they are:
1. You need to see what happens in the boot code before your OS gets control
2. Doing all of this will teach you a bit more about the hardware of the calculator
3. You can learn quite a bit from the different routines in the boot code (and you may actually want to use them)
4. Seeing how TI-OS handles the boot sequence could guide you in writing your own.
Now, you don't have to disassemble these two. But I would highly recommend you do the boot code. I learned so much when I did that and I think it would really help you.
134
« on: March 24, 2013, 04:38:22 pm »
If I personally were doing this, I would probably just write my own linking routines using port 0. However, if you go on wikiTI and go to the bcall section, almost anything that starts with "get" or "send" is what you're looking for. Two that come to mind are Get4Bytes and Send4Bytes. (Though, just looking at them I don't know how to use them).
135
« on: March 09, 2013, 12:04:10 am »
You'll have to ask runer. I may have screwed up the axiom, but it might also be an axe problem.
Does zStaxe have to be last for it to work?
Pages: 1 ... 7 8 [9] 10 11 ... 108
|
Show Posts