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 - AHelper
1
« on: March 04, 2014, 12:24:09 am »
Bump, FORTH isn't the only language, a form of LISP is in the making that will be cross-platform in C. Currently, it is being held back due to a lack of a tiny cross-platform floating point library. Neither are completed and GlassOS work is on hold due to other projects taking up my time.
2
« on: June 13, 2013, 08:29:54 am »
Just bumping a post here, anyone trying to build GlassOS from svn should be able to do so (I have finally added the missing tools). Also, the FORTH interpreter that was added is not yet in subversion.
3
« on: January 18, 2013, 11:35:23 am »
I should check your entry at some point. I didn't have much time to do so yet. Anyway glad to see this is still alive too 
Thanks, I am still here. I logged in due to the fact that searching GlassOS here didn't pull up this thread, so I was concerned :\ I can search it now, so I have no idea what happened yesterday (the search finished way sooner than it should have taken).
4
« on: January 18, 2013, 04:20:15 am »
Since I am working on my entry for the Cemetech Contest #9, I don't have any time for the next few days to touch any other code. Once I am done with this, I will resume working on gCAS3, a reworking of the function and algorithm system of gCAS2 in order to make it smaller and a bit easier to make functions. Once I finish gCAS3's new features, I will then work on adding it back into GlassOS and making another unofficial release.
5
« on: October 30, 2012, 04:57:26 pm »
Well, I started on working on the OS again after 5 months of silence. I have worked on gCAS2 in response to KermM's Graph3DP addin for the Casio Prizm and haven't touched anything else. Well, now I am getting back into the unfinished parts of the OS: the newGUI code, the USB, and package system.
6
« on: September 17, 2012, 01:00:13 pm »
Note: In the Protocol 7 page in the chm, I can confirm that you can indeed send commands over USB to and from the Prizm. It says currently that only IO was used.
Also, info on the OS update: According to the emergency OS updater, it reports a low OS version (0.02.0200). It may instead use this as the base OS version and could be confirmed by sending an OS with a lower version number. Also, the OS code version for the Get Device-Info doesn't report the OS version. For a 1.04.3200 OS it reports 1.02.0200.
Also, there is a change for the EditMBString* and DisplayMBString* commands. The unknown variable is int start, representing the first character drawn. This number will be used as the start of the string drawn, but the OS also does bounds adjustment. Passing 0 and the cursor set past the edge of the screen with cause start to be ignored.
7
« on: September 16, 2012, 01:07:15 pm »
Wow, I am going to have to look at that in a few days. Ty!
8
« on: August 26, 2012, 01:16:35 pm »
hmm... I will see about using the background VRAM as a second buffer. I don't know of anywhere that documents the required writes and such to copy the VRAM to the LCD. Do I need to play with the LCD at all before using the DMAC?
I am about to write some little assembler function, which will transfer any rectangular range from RAM to the LCD's GRAM via DMA. When it works well I will post the source.
That sounds great! Thank you for doing this. When you make the code public, would you like me to add it to http://prizm.cemetech.net/? Link to a post here?
9
« on: August 26, 2012, 12:24:03 pm »
hmm... I will see about using the background VRAM as a second buffer. I don't know of anywhere that documents the required writes and such to copy the VRAM to the LCD. Do I need to play with the LCD at all before using the DMAC?
10
« on: August 26, 2012, 08:04:49 am »
But is it possible to have the DMA run while the program continues? The program may have to use double-buffering in that case, but it sounds possible.
In fact syscall 0x0260 runs a simple wait-for-DMA-ready-loop while the DMA takes place,
only checking DMA0_CHCR_0.TE (Transfer End Flag) and DMA0_DMAOR.AE (Address Error Flag).
During this wait-loop, you could possibly do anything, which does not disturb the running DMA-job.
But that would mean to replace Bdisp_PutDisp_DD by some assembler function. Bdisp_PutDisp_DD itself does not offer any hook.
Ok, that sounds interesting. I will have to try this some time. What would disturb it? writing to the memory it is copying (or would it not mind this)? Using a syscall that tries to use the DMA?
11
« on: August 25, 2012, 06:51:28 pm »
But is it possible to have the DMA run while the program continues? The program may have to use double-buffering in that case, but it sounds possible.
*AHelper bumps this question.
12
« on: August 23, 2012, 08:01:20 pm »
Simon,, here's a question for you that I don't understand. Why is it that there is no noticeable GPS change when you use Bdisp_PutDisp_DD vs Bdisp_PutStrip_DD(1,2)? That makes me think that the delay is not in the actual copying of data. Any thoughts?
13
« on: August 11, 2012, 07:44:36 pm »
(bump'd)
I am having an issue. What causes the System ERROR exceptions to be triggered? I need to find a way to prevent these as I am reading addresses. I notice that Insight doesn't have this issue as it can read the address just fine, but I want to know how it does it. I didn't find anything obvious in the source for insight. Any help?
<edit>
Fixed it. Found out what ADDRESS(x) exceptions mean. I also found out how to override exceptions.
14
« on: August 03, 2012, 05:36:50 pm »
I was reading through the LCD documentation and am confused. How do I read and write directly to the LCD hardware? I can see the syscall to select the register, but don't know what address to use for read/writing.
<edit>
I now realize that the 0xB4000000 is where you read and write to. Maybe explain that in the chm so others don't get confused?
15
« on: August 03, 2012, 03:16:22 am »
Question, in PRIZM ASM and C, is there something special preventing people to use or convincing them to not use the 2nd key (like with ON on the TI-84+)? I am asking this because I noticed that most PRIZM games use F1 as confirm key instead of the standard 2nd/Enter and it tends to be rather annoying when you are used a lot to pressing 2nd. 
2nd/Enter is much more inconvenient than F1 or exe (because of 2 key presses :-) ) and also Casio uses F1 as confirm key very common (at least since fx7700GB)
I see. I guess it's because I'm just so used to using 2nd as confirm key and ALPHA or Clear as cancel. On the TI-83+ series, 2nd=confirm and ALPHA=cancel is pretty much the standard in gaming since the last decade or so, although some games still use ENTER (the equivalent of EXE), some use the number pad and others the F1 to F5 keys (annoying)
I can understand that. I, sadly, don't have the same experience running many games on my ti84pse since I mainly use it for GlassOS ;-) . Do not forget the the Casio calculator line isn't the same as the TI line. Key conventions are different. I already made a topic on cemetech (which is also on wikiprizm) about the key conventions that Casio uses. The key usage is what Casio set the standard at in their OS. I am not saying that one key usage should be used and not the other, as I am not trying to debate. I am simply stating that the two companies have different visions for how their calcs are to be used and the key usage in addins are from observations of how Casio did it. @MPoupe, I believe DJ_O was referring to 2nd/Enter as either 2nd or Enter, not 2nd+Enter. @SimonLothar, tytyty. I haven't looked at this for a while and was very happy to see many things that the PrizmSDK has have documentation (especially PrintMini, PrintMiniMini (not in the SDK), Bfile_TellPos, and Scrollbar). Keep up the great work! (Also, I documented a parameter for DisplayMBString that the chm doesn't have.)
|
Show Posts