Show Posts

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 - MGOS

Pages: [1] 2 3 ... 23
Axe / Re: Axe Parser List issues
« on: July 01, 2014, 05:16:08 pm »
The curly bracket operator {addr} only returns the single byte at the address you want. Each element of the array ("list") is one byte large, so it can store numbers from 0 to 255.

Axe / Re: Zooming Graphics In Axe
« on: May 20, 2014, 09:22:22 am »
Zooming in steps of 8 (the width will be a multiple of 8 ) and with a relatively low speed can be achieved by pxl-Testing the sprite (directly from the program or from the backbuffer) and drawing a black square in the corresponding size at scaled coordinates.
Code: [Select]
Pic1 ... sprite you want to zoom in
F ... zooming factor (1 or greater)

Pt-Off(0,0,Pic1)r //draw it on the backbuffer
    If (pxl-Test(X,Y)r)  //read a pixel from backbuffer
      Rect(X*F,Y*F,F,)  //draw a square on frontbuffer

Axe / Re: Cut the numbers of a variable
« on: April 08, 2014, 09:48:17 am »
Ah, you want to get the decimal digits out of a number :D
The modulo operator (^) does exactly that for you. It returns the remainder of a division. Say 27/10 is 2 remainder 7, so 27^10 returns 7. There you have the first digit (units), then you divide the number by ten and do it again for the tenths and so on.
Code: [Select]
Pt-On(10,I*6+2,M^10*8+Pic0)   //units
Pt-On(6,I*6+2,M/10->M^10*8+Pic0)  //tenths
Pt-On(2,I*6+2,M/10^10*8+Pic0)  //hundreds
The original value of M is corrupted, you might want to save that before the calculation

Music Showcase / Re: Unfinished (new DJ song and single in the works)
« on: March 27, 2014, 01:08:49 pm »
Awesome to hear new stuff from you, DJ :) ! I really like the song, but I'll take the right to bear a bit of criticism. In my opinion, the composition is great and the lyrics are too, however, the result isn't probably quite what I want to hear. I think the "voice"/lead melody is too quiet. If the song is sung, it wouldn't be a problem, but at this instrumental stage it seems to be, well... unfinished. I really liked your last instrumental album with the louder lead melodies. Also 2:21 sounds quite a bit too much like 3:02 in "Ride Through the 4th Dimension" (my all-time-favorite of your power metal songs!).
Anyways, keep up the good stuff. :)

Axe / Re: Timer?
« on: March 15, 2014, 05:08:44 am »
Yeah, interrupts are the way to go when you need to measure a time. The slowest setting should be fine for a game, since you don't need it accurate. Inside the Interrupt Service Routine you increment a variable. Since interrupt speed "6" corresponds to 118 Hz on a 83+ or to 108 Hz on a 84+, you divide by 118 or 108 to get the amount of seconds elapsed (or by 12 / 11 for tenths of a second). It is important to put the calc back to normal interrupt mode before exiting, otherwise crashes occur.
Code: [Select]
... // initializing stuff
fnInt(TMR,6)   //turn on the interrupt
0->T   //say T is our timer variable, reset it when the game starts.
game loop {
...// Stuff
T->S  //save the time after the game finished
S/118->S //get the seconds elapsed
...// win display stuff
LnReg  // back to normal interrupt mode, this is important
LnRegr   //repair any damage done by the custom interrupt
Return //Exit

Lbl TMR //the actual interrupt service routine
T++  // increment the counter variable
Return  //it's a subroutine so we return as usual

We don't need to make sure it doesn't overflow if you reset it everytime a nee game starts. Since the counter is incremented 118 a second and can only hold values up to 65535, it can run 555 seconds before it resets, that's about 9 minutes. So if a game takes longer than that, you need to use multiple variables, but I guess that shouldn't be a problem right now ;)

Either way, good luck with your project - I'm looking forward to see it :)

Miscellaneous / Re: Metaphore about programming
« on: March 05, 2014, 01:10:23 pm »
Nice one, matref :)
However it isn't considered that collecting all the treasures makes the program better and not only the programmer happier :D

TI Z80 / Re: GPS for Graphing Calculators
« on: February 14, 2014, 12:42:24 pm »
so... funny enough - two weeks before Kerm posted this - I ordered GPS module from a Chinese ebay shop. Well, after the three weeks of shipping to Europe, I could play around a bit with it and decided to do the same (sort-of) myself.

However, I don't have a 84+ where this works, neither the program nor the USB power supply. Having no idea how Kerm pulled it off to make the serial interface that good, I started from scratch, using my TI-83+ and Axe. I faced several problems though, mostly with syncing the GPS module to the calc to do not miss the start of the protocol on the one hand, and keeping both serial interfaces in sync on the other hand - which turned out to be way more difficult than I expected for such long protocols (just less than a kB for my module). I guess it is easier on a 15 MHz calc where you have fast enough interrupts to handle it. The 500 Hz interrupt just isn't sufficient for a 9600 baud port.

Keep both devices in sync is a different problem. These are four ways I could think of:
  • 1. Check the port in the main loop -> Bad for adding further functionality later
  • 2. Check the port in an interrupt -> interrupts are also to slow for this (catching the start bit)
  • 3. Request data when you need it -> I don't have a datasheet of the module so I don't know if this is possible at all
  • 4. Use a hardware asynchronous serial interface with a buffer -> I'm quite sure the TI-83+ does not have such a thing.
Eventually, I used the two latter solutions, inserting an ATtiny2313 in the serial line. It features a hardware serial port and is pretty idle so it can watch it all the time. What I did:
  • The AVR listens for any incoming GPS data on the asynchronous port and buffers the RMC string -> The data is stored so it can be called at any time
  • At any time, the calc can pull the signal lines low to request the buffered data -> The calc knows where the packet starts
  • The AVR transmits the RMC string using a synchronous (that means using two lines - clock and data - instead of one) interface -> save transmission
  • The calc only manipulates the ASCII string and displays it -> it has plenty of time to do other stuff
Furthermore, I used a Nokia battery to power it (you probably know that one - I use it in plenty of my projects). That is in a manner useful since the module draws with ~80 mA at 3.7 V quite a lot of power and would suck the calc batteries empty in no time - having it to be rechargeable is a nice feature I guess.

Some drawbacks I will fix later:
  • The AVR has only 128 bytes (!) of RAM, so it can only buffer the RMC string, not other information (such as altitude or # of satellites)
  • The code is pretty messy at the moment - I'm too ashamed to upload it ;)
The direction data only works when the ground speed is high enough.

Web Programming and Design / Re: Prefered Browser
« on: February 04, 2014, 12:22:58 pm »
I have IE, Chrome, Fx and Opera installed but the latter is the one I use most. I really like the simple and clean user interface and the mouse gestures which are a great working experience and when you get used to them they really improves browsing speed. Same with Opera's auto-login function. Opera is also my favorite mobile browser.
Fx appears to me as a bit buggy and crashes sometimes (not often but far more frequent than any other program). It also wants to be updated every now and then and that then wants to adjust/ensure compatibility of the plug-ins etc. With Opera, updating happens is only a matter of seconds (less than 10).

Else, it would almost imply that every recent ASM game on send gameplay data/calc content to the NSA if you play them while the calc is connected via the USB port. :P
lol :D

TI Z80 / Re: AudaciTI - 4 channel music player and editor (in the works)
« on: February 02, 2014, 06:57:16 am »
Wow that looks indeed pretty fancy awesome!

Attack/Decay/Sustain/Release (short ADSR) are parameters defining the envelope curve of a note. Every basic synthesizer has 4 pots - one for each value.
Attack is the time the tone needs to go to full amplitude. Decay is the time the amplitude drops to a certain Sustain level, where the note rests until it is being released. After the note is released, the Release time specifies how long the tone needs to fade away.

This diagram (from Wikipedia) illustrates that quite nicely:

Just put them in HL (Axe's Ans) - that is usually the last value you worked with. Just write the expression (or the single varibale) in the line before the routine. The same way (with the sto-> operator) you can retrieve the value returned by the routine.
Code: [Select]

Other / Re: SID synthesizer with MIDI
« on: January 11, 2014, 08:43:15 am »
That sounds awesome! Great job Keoni :)

TI Z80 / Re: zStart - an app that runs on ram clears
« on: December 31, 2013, 12:40:58 am »
Sure there is with the help of asm, it can be done the same way like RawKey just a little more complicated. Give me some time... ;)

Other Calculators / Re: [AXE] Little contest :D
« on: December 30, 2013, 09:06:52 am »
Did you mean x . 2n-1 ?
No, I meant x . 2n-1 ;)

Other Calculators / Re: [AXE] Little contest :D
« on: December 30, 2013, 08:29:49 am »
Is axe fusion allowed? If so, I've got 264 bytes. Otherwise, I have 416 bytes and have to find an other way of doing this.

BTW: Does ^64 compile to " and %0000000000111111" ? (and being the 16-bit and instruction (plot style dot),and % being the pi character) Both have the same size when compiled.
I think axe fusion isn't allowed, that's cheating - or you add the Axe app to your program size ;)

x^2n compiles to x . (n-1) to x . 2n-1 AutoOpts is a really useful reference for the size of each instruction.

Edit: fixed that math

Axe / Re: [Tutorial] Key hooks in Axe
« on: December 28, 2013, 04:32:57 am »
Hook chaining is done by calling the already existing hook within your own hook, I guess. Remember to put the right value in A though.
Seems doable, so you have to somehow get the address of the other existing hook and then call it.

Haha... Well... to be honest that was my initial intention which lead me to explore this whole thing....
Not just blocking it, but rather open up a menu that looks and behaves visually the same but doesn't do anything... ehhhrmmm I better stop talking now...  ;)
That is pretty cool, good luck with that!
Actually that seems to be more than scratching the edge of legality in schools... "attempt to deceive" is what it's called when it gets busted.

I'm already doing some cool stuff with that code. I made it so that whenever enter is pressed it displayes "do it yourself". This is so going on my friends calculator XD
Actually there might be another (maybe more convenient) way to achieve this: The hoomscreen hook. It is run when one of the following things happen, what happened is specified by the register A so you can check that in your routine:
  • A = 0: Displaying a result - hack here to change the result. It is stored in OP1. When the Zeroflag is reset on return, then nothing is displayed.
  • A = 1: Key press - keycode is in B, you can change that here. When the Zeroflag is reset on return, then the key press is ignored.
  • A = 2: Expression is entered. When the Zeroflag is reset on return, the operation is cancelled.
  • A = 3: Edit/changing context -last context value is in B. Return with zeroflag set!

Interesting is A = 0. We can actually recycle almost the whole code from before, except the bcalls and "cp a"

Code: [Select]
; address in HL
 in a,(6)   ; current rom page
 _bjump(_JForceCmdNoChar) ; Quit

 ;Hook itself:
 add a,e  ; 0x83 required to be identified as legal routine
 push HL
 push BC
 push DE
 push AF

 ld l,a     ; load a to l to make it usable in axe
 ld h,00

 ; function goes here

 pop AF   ; restore the registers we might have messed up
 pop DE
 pop BC
 pop HL
 cp a    ; set zeroflag


Code: [Select]
:Lbl Hook
:!If ->A
://Do some crazy stuff like _bcall(_Random) store some random stuff in OP1:
://Disable the hook:
://restore and cp a
:Asm(F1D1C1E1BF)   //note the BF, otherwise things get messed up badly

Hope that helps

Pages: [1] 2 3 ... 23