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

Pages: 1 ... 5 6 [7] 8 9 ... 62
91
Other / Re: Types of USB Flash Drives
« on: September 11, 2011, 11:25:41 pm »
I have an 8gb kingston micro sd usb adapter that's as slow as hell but is insanely small. But for other stuff I use a 16gb corsair which i find to be very reliable. According to reviews you can throw them off buildings and run them over with cars with no data loss.

edit: Corsair now sells 64 gb usb 3.0 drives  O.O

92
This will start to become more profound as Prizm coders begin to use more low level to control the hardware in place of OS routines as we saw many years ago on the 83+. Think for example ionfastcopy and calcnet2.2  which in some cases are so hardware specific that they need to be modified for other 83+ series calcs. Porting these hardware routines would be very difficult or even impossible when going from the Prizm to the CX such as if the serial port is involved.

93
News / Re: Obliterate 1.0 released
« on: September 10, 2011, 10:46:13 pm »
Actually it wouldn't be a bad idea to increase portability between the Prizm and CX by writing some multi-platform libraries. One the Prizm scene there has been some talk of of porting newlib which is an embedded C standard library implementation. So a port of that to both the Prizm and CX would allow programs that use those capabilities to be more easily cross compiled. At the same time there should also be a multi-platform graphics library that provides a variety of functions and types that can be shared by CX and Prizm programmers alike.

94
News / Re: Obliterate 1.0 released
« on: September 10, 2011, 06:17:19 pm »
Now kerm needs to make it for the cx
Very unlikely to happen if you read this article by Kerm from a few months ago. Plus for the cx, obliterate would have to be programmed in Lua while the Prizm version was made in C.

95
News / Re: Only 2 weeks left to the Prizm contest!
« on: September 08, 2011, 09:27:27 pm »
I've hit a slight delay recently. My hard drive got corrupted last week (yes I kept back ups) and until i can get a replacement part I've been running from Linux Mint mainly. The problem with that though is that gcc has been outputting some strange compile time errors that I never had on windows. So until I get that figured out I can't make any progress so at this point I'm not sure if I'll have a submission or not by next week. I'm still pretty optimistic though that i'll get this figured out.


Edit: Well it turns out i was able to fix the issue and code will now cleanly compile and be built into a g3a even when on linux. The only problem now though is that Mint which I'm running is on a virtual machine which is on Fedora 15 which cannot properly transfer files between the Prizm which is a slight speedbump :P

Edit2: Okay well it looks like everything is fixed enough that I can continue with development of Plants vs Zombies. Unfortunately due to the delay DXT image compression will not be implemented however version 2 after the contest will use that to drastically cut the file size with almost no reduction in quality. My current set up though is quite complex. It involves doing coding and compiling on a Linux Mint virtualbox with of course wine running to use the custom gcc. The finished g3a file is then uploaded to google docs which it is then redownloaded but on the host OS which is the very buggy Fedora 15. The g3a is then sent to my flash drive which is sent to my super old xp laptop which lacks wifi. The xp laptop then sends the file to my Prizm where it can be fully enjoyed. It may sound complex but this is honestly the simplest way I can do development.  

Edit3: And the xp laptop has to run in safe mode to prevent it from BSODing but otherwise I'm doing just fine :P

Edit4: When will Acer finally send my replacement disk drive so I can re install windows?

96
Casio Calculators / Re: Prizm Useful Routines -- post here!
« on: September 07, 2011, 12:54:43 am »
You might want to run a test on those random routines due to a possible issue with the RTC. The problem is that the RTC ticks only 64 times a second so if you're calling that same routines multiple times in quick succession there may be some repetition. In Simon's random routine he used a static seed to contribute to the result which increased randomness. 

97
Casio Calculators / Re: Prizm Getkey
« on: September 05, 2011, 08:43:35 pm »
I wonder if adding multi key support will be easy? Does the Prizm allows direct input like on TI calcs? (where instead of returning the keycode, it checks if a specific key was pressed or not)
Yes the entire keyboard is hardware memory mapped so you can if any key is currently up or down without any difficulty. On the matter of multi key support that is easily done but I'm still working on the best way to implement the function in C that would be very simple for another Prizm coder to use.

98
Casio Calculators / Re: On-calc C compiler for 9860
« on: August 31, 2011, 02:35:38 am »
no probl
Thats cool. one prob, i cant do c (yet)
No problem. I'll check Simon Lothar's documentation on the fx-98 series so I can modify the proper files to work correctly. I will also rewrite mkg3a into a new mkg1a unless such an app already exists. Basically I will turn this Prizm exclusive project into a Casio calc harmony one instead :)

99
Casio Calculators / Re: [SDK] IsKey too slow...
« on: August 31, 2011, 02:28:30 am »
Do you mean Prizm key detection in ASM/C is as slow as in BASIC? O.O
That particular system call is as slow as its Basic counterpart because that's what the interpreter calls when its running a Basic program. There are other much faster system calls available such as one that will return a buffer full of the keyboard data or even a non system call based one that I developed that works directly with the hardware and is extremely fast.

100
Casio Calculators / Re: E-Math Suite
« on: August 31, 2011, 02:19:08 am »
cool. so luaFX shouldn't be hard to get on prizm. that would be nice.
Qwerty is actually already working on a lua implementation on the Prizm as part of the Khavi byte code interpreter which is currently being built with support for java, brainf***, and lua. Because the Khavi engine handles memory management, multi threading, and code parsing, there is no need to develop other byte code based languages from scratch. It might even be possible for anyone to add a language depending on how open and well documented the engine is. such future possibilities are python, ruby, and CLI which .net based languages such as C# run on.

101
Walnut / Re: Walnut Shell
« on: August 31, 2011, 02:09:28 am »
Now that this poll is just about expired it appears that ram data will be by default in virtual memory. This will hopefully allow in far future versions of Walnut for specially made programs to take advantage of multitasking capabilities. Simple programs that could benefit from multitasking that I've thought of are text editors, debuggers, command prompt, calculators, sprite editors, screen recorders, and most notably quadratic solvers :P

102
Casio Calculators / Re: On-calc C compiler for 9860
« on: August 30, 2011, 09:27:00 pm »
Now that there is the gcc SDK for the prizm someone should port it over to the fx-98 series first off. Then secondly the compiler can be slightly modified and recompiled for the the fx-98. i believe the only thing that needs to be done to have gcc for the fx-98 is write a new linker script and crt.s file which should be rather simple. Then for the on calc version the modifications are a little more intense. the linker script and crt.s file will stay the same but the compiler itself will require a partial STL library to be ported for file io and the console to work properly. it will also require that a new main function is created that allows the user to select the proper file and then calls the original main. I was going to attempt this on the Prizm soon but i could also make an fx-98 version too with only minor modifications

103
Casio Calculators / Re: How do 3d games work?
« on: August 30, 2011, 08:57:28 pm »
The math is the same regardless of language and if you know casio basic moderately well then it will be easy to port that example to lua. One thing you will have to add though is be able to convert plot points into screen coordinates but if needed I can help you with that part

104
Casio Calculators / Re: How do 3d games work?
« on: August 30, 2011, 08:52:03 pm »
I did write a rotating cube example a few months ago in Casio Basic and it was fairly simple. If you want I can upload the source and/or the program and it will run on you fx-98xx because prizm basic programs can be down converted.

105
Casio Calculators / Re: How do 3d games work?
« on: August 30, 2011, 11:37:13 am »
It is very in depth math and covers many concepts of 3d that you will not be implementing in luaFX but one book that really helped me understand a lot of 3d games including optimization for specific architectures was Real Time Rendering. I highly reccomend it to anyone who wants to learn a lot about 3d

Pages: 1 ... 5 6 [7] 8 9 ... 62