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 - Galandros
Pages: 1 ... 20 21 [22] 23 24 ... 84
316
« on: May 19, 2010, 03:22:17 pm »
Wow, I installed dictionaries to Firefox and was surprised that German had a new reform. For French, I knew before because of DJ Omnimaga talk in the forums.
Anyway, we can use both the old and new grammar and orthography reforms for French?
I started to help a bit in French section, and is curious how I exchanged the ´ and ` accentuation in "très" and did not know "intéressante" had accents. French has more accents than even Portuguese (and we have a good amount). Some books of Eça de Queirós have French expressions and words so I already know some. French was very influential in Europe education and in Portugal, English started to have more influence only after my parents finished their academical education.
317
« on: May 19, 2010, 02:55:47 pm »
Très intéressante.
318
« on: May 18, 2010, 03:50:52 pm »
I instantly noticed his appear in ticalc. He showed his projects in UTI. He has some nice utilities, check it out. 
319
« on: May 18, 2010, 03:48:23 pm »
Growing activity is going to stay.
I have a doubt regarding international forums:
Is there any guidelines about using translators to reply sometimes?
I will participate in Portuguese or Spanish talk if that ever happens. I might try to participate in any online forum or chat in German or French in long term future.
EDIT: I think the "Other" languages sub-forum needs a pinned topic for giving an idea of what active talkers we have in other languages than French and Dutch. It might even later have rules, brief descriptions and guidelines for showcasing projects.
I did not know about Dark Stone ban... Does that demotivated him for calculator projects?
320
« on: May 17, 2010, 04:52:38 pm »
Interesting. Assembly power, ftw.
The first code looks much better (smaller, less repetitive, flexible to changes) to me even if I don't know what those C++ functions are doing exactly.
321
« on: May 17, 2010, 02:48:47 pm »
I just shamelessly copied of James Montelongo graylib2.inc. Wow, I can now see how the scanlines are done.  Interleaving can be used in assembly to easily access the dark and light layer of 8 pixels quickly before copying to the LCD. It achieves better speed but you have to change your sprites routines and data.
322
« on: May 17, 2010, 02:37:10 pm »
If you are using SPASM, I have a nicer set of macros. (justified for each case bellow) There is relocate.inc for relocating easily code. You don't need to use the macro in every jump... relocate($4000)
relocatedcode:
;code as usual
ret
end_relocate()
And var.inc for variables allocation. You can use it anywhere in your source code and detects overflows. varloc(savesscreen, 768)
player_x = var(1) ; 1 byte var
player_y = var(1)
saveHL = var(2)
; another place
varloc(tempswaparea, 323)
array = var(500) ; triggers a error
You can see other useful macros in my macros package here.
323
« on: May 17, 2010, 02:22:13 pm »
Making DJ text a little more visual, alternating
10101010
and
01010101
produces greyish to our eyes if is alternated fast enough.
EDIT: DJ shows a screen shot...
For 4 level grayscale the patterns used are:
.db %11111111
.db %11111111
.db %00000000
.db %11111111
or
.db %11011011
.db %10110110
.db %01101101
.db %11011011
The first looks better, I think, with scrolling. The second with more still images.
324
« on: May 17, 2010, 02:14:25 pm »
For larger tasks like a tile mapper, you can let your tile mapper work during the delay. You actually gain speed by not wasting time in doing nothing between writes. (Note that normally a good tile mapper like dwedit's, jim_e's or calcmaniac84's copy the old screen to lcd and compute the new screen that will be copied in the next frame.)
How do you do something during the delay? Is it natural, or does it involve interrupts or another process
Simply put some code before the write. For example dealing with one tile gives more than enough delay. It does not matter exceeding the delay. One interesting use is output a byte to the LCD and right after clear that byte in the plots screen. It is used in one of the routines here: http://wikiti.brandonw.net/index.php?title=Z80_Routines:Graphic:FastcopyIt avoids to do this: call fastcopy call clearbuffer If the LCD was accessed directly, would this cause cross-compatibility issues between each hardware revisions of the 83+, 83+SE and 84+? I think the used LCD is different over the time
Yes, the compatibility issue is the amount of delay. Ion fast copy is not safe because it assumes a certain time between writes (less than 60 T-states or clocks, I think) some bad LCDs need more time than usual and go funny if you force them. To make it safe you wait for a flag of the LCD that indicates if it is busy or ready to receive the next byte. Contrast is also different between calculators but does not pose such a great problem.
325
« on: May 17, 2010, 01:07:49 pm »
DJ Omnimaga actually found that link a few weeks ago.
It only had a wabbitemu build. Now it is complete.
I have some bugs of spasm to report. >_> I will put there ASAP.
Good to know.
But I like to scavenge some files in the Internet...
326
« on: May 17, 2010, 01:04:33 pm »
First, I hope you got good results after all that hard work. And is good enough to know you are back. Progress can come later. 
327
« on: May 17, 2010, 12:59:02 pm »
I understand that when working with the LCD drive on the Ti-83+ directly, you get immediate updates. Is there a way to control when these updates occur (meaning the screen doesn't update everytime you draw a single point)? If not, what's the advantage to using the RAM over plotsscreen?
No, there is not command to that of the LCD driver. We control when the LCD updates by copying plotsscreen to the lcd ram when we need. plotsscreen can be seen as a back buffer and the lcd ram as the active buffer. The only advantage is you supposedly you do not need to use plotsscreen as a graphics buffer. We can make routines that display graphics directly to the LCD instead to a buffer. This is not done for pixels, sprites and text because it is slow to wait for the lcd after copying a byte. But for larger tasks like a tile mapper, you can let your tile mapper work during the delay. You actually gain speed by not wasting time in doing nothing between writes. (Note that normally a good tile mapper like dwedit's, jim_e's or calcmaniac84's copy the old screen to lcd and compute the new screen that will be copied in the next frame.)
328
« on: May 17, 2010, 09:41:29 am »
For written documentation you can have luck in WikiTI, ask Brandon Wilson and as last resource, see the source code of some 3rd party OS (maybe some source code is well documented and explains what you want). At least have fun with the experiment.
329
« on: May 17, 2010, 04:45:40 am »
I also included a list of some of my macros since I think I use a few of them in my routines.
I especially liked the min and max macros. Mind if I release some of the macros and routines in a z80 library? (I put credit in the source code and readme, it is my habit) The adding and multiplying hl by constants can help out some beginners (drawback of some not understanding exactly what are doing) or copy/paste to spare time.
330
« on: May 17, 2010, 04:36:41 am »
Well done. The tree is symmetrical? To get get the missing half, mirroring it is enough?
Pages: 1 ... 20 21 [22] 23 24 ... 84
|
Show Posts