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

Pages: [1] 2 3 ... 28
Not sure if anyone has mentioned this but the For( speed bug only happens if the IF is the exact next byte after the for loop without the closing Paren.
Basically this triggers the bug
Code: [Select]
:If blah
and this doesn't
Code: [Select]
:If blah

Other Calc-Related Projects and Ideas / Re: TILP: beta-testing...
« on: March 19, 2013, 11:57:13 pm »
I've been working on a new driverless serial backend for libticables on windows please see this topic for details on testing. I'm posting here so that hopefully more people will see it and test as the number of people who have all the required prerequisites is fairly low and I would like as many testers as possible.

So for the past few weeks I've been poking at a replacement for the dhahelper based BlackLink/$4Link used by TILP. This new backend uses the native Win32 Comm API to toggle and read the pins meaning no need for an external driver. This means no chance of BSOD's from dhahelper, at least for BlackLink's and $4 Links. Sadly this won't work for the Parallel link but I shall look into that next, though I have a feeling that we have about 0 windows users of it left.

To test here is what you need.
  • A BlackLink or $4 Link cable
  • A computer running Windows XP or newer(Vista, 7, or 8 preferred*)
  • A way to attach said BlackLink or $4 Link to that computer

If you have all of the above here is what I'd like you to do.
  • Install the latest TILP II beta Do not install the BlackLink/Parallel Link driver when prompted
  • Download my test libticables2-6.dll
  • Once TILP II is installed replace the libticables2-6.dll in C:\Program Files\Common Files\LPG Shared with the one you just downloaded. (If on a 64bit OS it will be Program Files (x86))
  • Fire up TILP and try linking.

Report your results in this thread including OS, cable type (Blacklink or $4Link), port type (on Motherboard, addon card, or USB adapter), and how well it seemed to work.

* The current beta of TILP is broken on XP so you can't really test, yet.

News / Re: The TI-Nspire ViewScreen panel is a true TI-Nspire CAS+ !!!
« on: January 08, 2012, 06:41:17 pm »
Though it makes some sense when it comes to development speed and ease of testing. When the hardware and software were simpler there was less to debug and fewer things to go wrong, here with much more complex display hardware and wanting to support more complex configurations using tested hardware that already has all the requirements for their needs most likely saved development costs and time. They already had hardware that worked and could power that display and by using simpler links they don't need the hackish things they did so that you could connect any NSpire up to the display where with previous calcs you had to connect the teacher viewscreen models up or use the crazy hack of a device that was the USB Viewscreen adapter.

News / Re: GCC PrizmSDK v0.3!
« on: November 27, 2011, 03:01:57 pm »
Yes the normal and sane way is to compile binutils and gcc from source, I used as my base changing the target to sh3eb-elf, from there the current setup will work without much work as long as you put the compiled tools in your $PATH. I plan to simplify this in the future but as windows users are more common and I am nowhere near done I have aimed at supporting them more. The setup used in v0.3 is much cleaner than the older releases and should be much easier to use on other platforms.

News / Re: GCC PrizmSDK v0.3!
« on: November 25, 2011, 10:30:17 pm »
ephan, if you want to get my tools going under Linux just message me on IRC and I will get you started. I should really just make an automated script for it but its not to hard to do yourself.

News / GCC PrizmSDK v0.3!
« on: November 25, 2011, 01:24:56 am »
Crossposted from cemetech and my blog
I will try to check here for replies but ones at those places will be seen first as I check there more often.

So after a long overdue major overhaul of the makefiles and some additions to libfxcg I am ready to release PrizmSDK v0.3. The biggest improvement is to the makefiles and build system and it puts me one step closer to a much cleaner setup. Most of the changes are based on the makefiles used by DevkitPro and I plan to move to an installer based system similar to theirs in the future as well.

The most obvious changes visible to the user is the new project directory layout. It is now much cleaner and uses a convenient project layout with specific folders for source files and temp object and such. All the configuration is still in the Makefile in the project directory, which has been cleaned up and commented. All of the dirty work was moved to a separate Makefile in the common folder of the SDK and the project directory shall now house only projects. The end goal is to allow the project directory to lie anyway and have environment variables for where the SDK lies. In the process I also made the makefiles much more cross platform safe though it might still need more tweaking to get just right.

I still wish to clean up the headers quite a bit more and move to just one header for all the syscalls and have that header include the extra headers with the core typedefs. There is no reason to have the headers split up as they are and I intend to clean that up with the next SDK update, if I don’t sneak it into this one. (if you notice filemodtimes change, this would be why)

The next big step will be to include an installer which can optionally grab msys instead of me having to include chunks of msys and cygwin for make and friends to function properly for people without them installed.

Please respond with any bugs or issues and I will address them as soon as possible. With how long it took me to do this release I’m sure I forgot something or made a typo somewhere and the only way I can fix it is if I know about it.

Download links:
xz: (11M)
gz: (42M)
zip: (44M)

Casio Calculators / Re: FXTerm - VT100 terminal emulator for Casio fx cg
« on: October 27, 2011, 08:05:09 pm »
Juju, for this to work with USB one would have to emulate an well supported USB TTL chip, I know there was some talk on doing this on the TI-89T a while back but I doubt we know enough Prizm's USB controller to do this, but I'd love to be proven wrong.

Other Calculators / Re: Merthsoft?
« on: October 18, 2011, 04:19:00 pm »
myserverathome and point to the same site iirc, but he is in the process or moving so his server at home isn't up. When he is fully unpacked everything should be good.

Casio Calculators / Re: Compiling stuff for Prizm
« on: October 18, 2011, 04:17:14 pm »
What I think would be really cool is if we could somehow make it so the syscall and general routine library could be portable between the compilers. For syscalls the asm.h header just needs to use the proper macro for the platform, along with the asm source files but the C sources should easily be portable between them with a little clean up.

I already have libfxcg hosted on github so that is a start but many of simon's helper routines don't even compile with gcc due to header file case errors, syntax differences and a few other issues.

Casio Calculators / Re: FXTerm - VT100 terminal emulator for Casio fx cg
« on: October 17, 2011, 04:11:38 pm »
If you try fxterm with Casio serial cable, you may find, that stream PC->fxterm goes OK, but fxterm->PC doesn't. The problem is in DTR signal on COM port, which must be set ON. The cable (probably) uses it to get power.
I used following (and very dirty workaround):
Linux is running in vmware (which run on windows), it has serial port, which is configured as named pipe (\\.\pipe\seriak), vmware end is server,other end is an application.
On windows run proxy - attached application, which forwards data between pipe and real COM1 port. The proxy ensures, that DTR signal is ON, so it works.

This is very dirty solution, proxy is very dirty software, but at least it works for testing:-)
I hope there is a way to configure Linux to set DTR signal ON, I did a very quick research, but found nothing:-(

Very nice work! You may be able to use something like setserial on your nix machine to disable/enable flow control which should fix that issue. Or you may even be able to force power to that port to be on with it.

Casio Calculators / Re: Compiling stuff for Prizm
« on: October 12, 2011, 09:43:26 pm »
I agree that the numbers are generally useless, but I disagree with using the header file name as the organizational method, a simple category based method would be just fine. The issue with going by the header file name is that is one of the issues I have with simonlothar's SDK is the naming and setup of the headers. The stdlib related headers could be organizer as such but even there simon didn't follow the C standard and I really think that should be fixed.

Since we don't have official naming conventions from Casio I would see if we can standardize them, unless the naming we have been using is based off of the older Casio calcs. If that is the case then fine but it still irks me.

Casio Calculators / Re: Casio Prizm documentation
« on: October 07, 2011, 05:30:44 pm »
What would be nice is if we could get much of the documentation in that chm file onto the Prizm wiki. Maybe have a section for syscalls and organize them similarly to how they are in the headers.

I personally can never seem to find anything I need when working on the GCC SDK in it and a searchable wiki would help that situation greatly.

Casio Calculators / Re: Compiling stuff for Prizm
« on: October 05, 2011, 12:14:01 am »
I know this is a bit of a necro bump but I did release the "cemetech"(as Kerm so happily dubbed it) GCC PrizmSDK-0.2 a while back and would love to help anyone get it setup if needed.
As for using it on Mac OS X you would need to install xcode and then compile and install a gcc targetting the superh series processors. If you want I can help walk you through the process any time, just hop on irc, or use the chat box, and highlight me. You would just need some parts of my sdk and I have all those individual files available for download.
As to keeping this on par with Simons work I would really love to work with him on standardizing things a bit. I'm fine with the automated syscall generating and have written a script to duplicate its work for use with my SDK but the biggest issues I have are with the header and helper functions organization. As it stands right now you can't easily use the headers from one SDK with another or even reliably compile code written with one on another.
I'd like to fix that so that it is easier for the end users of either SDK to adapt them to their needs.
My first issue is the lack of clarity on whether or not C++ is really supported and why some headers and source files use hpp/cpp instead of h/c. IMO we should keep the SDK's and their API's pure C and leave it up to the users as to whether they want to use C or C++. Many of your headers are already encased in Extern "C" {} so why even bother having them use the .hpp extension?
My second issue also relates to the headers and it is the fact that you mix equates and structs used by syscalls with custom functions you have added. This increase the amount of work for me greatly and adds to user confusion because they can't tell what is a syscall and what is something you added to the SDK yourself.
My last issue is that darn chm file. :P Yes its nice that there is some documentation but damn is it a pain in the arse to find any of it in there. Omnimaga was kind enough to host the prizmwiki at we should use it. I have been trying to update it with some of the things I have found but its just not all that useful as it currently stands. I think the first step would be to start getting the syscalls on there. The documentation for them is scattered about this forum, your .chm file and our heads. Getting on in a centralized location would help everyone move forward and allow one to much easier find the information they need.

News / Re: Donations
« on: July 13, 2011, 01:07:54 am »
0.o that is friggin expensive to the point where I'd say you are getting ripped off to the extreme. I get way more than that and I pay a whole lot less. I don't know why you guys moved from 1and1 but surpass has served me and Kerm very well over the years and is hella cheaper. But if you are gonna ask for donations you had better be trying to get by without as best as possible first and it sure doesn't look like that.

And I still feel like asking people to pay for Nethams VPS is wrong, and IRC bot should not need a VPS and if he wants members to pay he should be looking for the cheapest way possible to host it, not be getting massive overkill.

Pages: [1] 2 3 ... 28