Never mind - I fixed it. Turns out that I didn't have the latest version of WabbitEmu - I was running 1.5.
That's ok, I had to poke Buckeye to get the changes in, so problems were to be expected when someone used old versions. Razz
now if only my School's "Vitrual Ti Emulator" could load this.
It worked on WabbitEMU for me just drag and drop... But, i was not impressed as it was only going to work with GlassOS stuff.
Here's the problem with the development of this.

Boring:
In order to release this OS as usable for testing, it needs to have file/program transfer. Now, here is where the fun starts. When you transfer a file, the PC talks to the calc over the File System Access service to cd to the directory and try to upload. (If there is no listening program, the OS simply ignores it and the PC just times out silently) When the PC wants to upload a file, it tells the calc to get ready. The calc does fopen(name, 'w'); and gets ready to write to the file. The PC sends the file over the FSA service and the calc keeps flushing to fwrite(f, data);

Interesting:
Once the file is transfered, the calc calls fclose(f); to finalize the file. AFTER this is done and the calc goes back to an idle state in the communication, the calc seg faults and dies. I have few ideas on what goes wrong. I have 0 ideas where this runaway happens.

So, this is why GlassOS seems to have been idle for a long time. I keep going back to this problem, and never find a solution, just get a few results from tests.
Couple of things...

Firstly, I have been getting ready to get a server prep'd to allow anyone to query GlassOS sources and request a build of an 8xu.

Second, I still want to redo the Launcher's doList function (click on a category, that screen). It is a hog for CPU time as it is very sloppy with loading .desktop files.

Lastly, arrow keys in the GUI. @KermM, doesn't DCS let you move button selection without the mouse? I am trying to think of a way to have the arrow keys move to the next physical widget. Right now, up/down is used to move in the widget array. Put something in out of order and your selection movement is out of order :/
Yes, Doors CS has the TabFuncs shell expansion, which is more like [tab] and [shift-tab] than the arrow keys. Even if Doors CS let you re-order items, it would still work, because it just tells Doors CS that you clicked on whatever icon the highlight is over when you press [ENTER].
How does it determine which widget to jump to?
MAJOR BUG FIX

After reviewing a hunch (probably caused by me using vim), I discovered that the only way that the program can crash after a method ends is due to the interrupt being trashed. I called filesystem routines, which does EI, from within gFiler's transfer's UVP callback. Since nobody knows what this means besides me or anyone who read the function list, you can create UVP server callbacks (any time a packet comes through on USB, it alerts all listening processes) which are called after a UVP packet is received. Now, this happens from inside the interrupt's call to BrandonW's Linky code (more pillows and cookies to you). Problem is, if I do an EI, the USB code executes again while inside of itself. This causes terrible things to happen.

Fixing this was quite easy, thankfully. The transfer part is just waiting for a key to quit. The UVP callback works on its own. Now, the key waiting will keep polling a boolean value to see if a packet arrived. If one did, it handles it (not in the ISR) and resets that value. Now, you can send data to the calc without crashing!!!

I will add file transfer back in very soon, and will be on my way for making a release to GlassOS again.
AHelper wrote:
MAJOR BUG FIX

After reviewing a hunch (probably caused by me using vim), I discovered that the only way that the program can crash after a method ends is due to the interrupt being trashed. I called filesystem routines, which does EI, from within gFiler's transfer's UVP callback. Since nobody knows what this means besides me or anyone who read the function list, you can create UVP server callbacks (any time a packet comes through on USB, it alerts all listening processes) which are called after a UVP packet is received. Now, this happens from inside the interrupt's call to BrandonW's Linky code (more pillows and cookies to you). Problem is, if I do an EI, the USB code executes again while inside of itself. This causes terrible things to happen.

Fixing this was quite easy, thankfully. The transfer part is just waiting for a key to quit. The UVP callback works on its own. Now, the key waiting will keep polling a boolean value to see if a packet arrived. If one did, it handles it (not in the ISR) and resets that value. Now, you can send data to the calc without crashing!!!

I will add file transfer back in very soon, and will be on my way for making a release to GlassOS again.

Yay!!!!!!! Now we can actually send programs to GlassOS! Glad you fixed that bug, AHelper!

Of course, where can we find glassLink? I don't see it anywhere with the SDK.
glassLink is part of the GlassOS project, located under trunk/glassLink. Will need to commit things soon and finish the file transfer stuffs.
Congratulations on the bug fix. I certainly know the ecstasy that comes with finally tracking down a frustrating, hard to find bug. Glad to hear that you'll be adding file transferring back, now that this is fixed.
Thanks! I re-enabled the transfer code, but will need to actually sit down and muck with it because it stops the transfer on the first frame :/

Other than that, things to look forward to: Progress on all file transfer operations; Package installation; receiving and running fs-based programs.

<edit>

glassLink is getting some updates to its file browser to better handle directory changes and such.
AHelper wrote:
Thanks! I re-enabled the transfer code, but will need to actually sit down and muck with it because it stops the transfer on the first frame :/

Other than that, things to look forward to: Progress on all file transfer operations; Package installation; receiving and running fs-based programs.

<edit>

glassLink is getting some updates to its file browser to better handle directory changes and such.

Question: With GlassOS, will you be able to connect your calc to your computer and install all required package updates at once, in standard Linux fashion?
I can't say as I haven't thought about that.
Removed the PHP script from the build system, I will commit this as it should help everyone out, especially cygwin users (I had to do this as there is no php-cli in cygwin).

Please note that the svn is out of date. I need to go and commit things from my desktop's copy in order to get the OS to build and run properly.

I have also been brute-force testing sdcc versions. I am currently seeing r6750 is ok for using for GlassOS, but not r7000. I will test the latest.
Fun fact, GlassOS's build system is dumb and was failing to rebuild all files Sad
Fun fact, SDCC is dumb. Load (_data) into hl and bc. inc hl, then load (_data) back into hl. It then makes sure that bc keeps the right value. At the very end, it uses it once along with hl, which gets reloaded again. :S
Well, consider this my very first asm program that I am writing (GlassOS doesn't really count, I mean really...). gF79, or glass FORTH 1979.

Yes, Merth, I am sorry. I am talking about FORTH. Essentially, I wanted to get writing some sort of language on-calc. I wrote a FORTH-like interpreter already for gCAS3, but that was replaced with a newer one that executes in a binary form and not as text. Since it is already low-level, I didn't want SDCC to muck it all up, I am hand-writing it. Sure, C parts will be around to speed up development and converted later, but it works.

Take this: 817B018204D2017E
When ran, that prints:
123
1234

In a source form, it is: 123 . 1234 . <EOF>

Literals are specified with bit 7 set. If bulk data is given, bit 6 is set and 0-5 are the size. If bit 6 is 0, then bits 0-5 are the bytes to push to the stack (odds are auto-evened by pushing a 0 first) (stream is big-endian).

If bit 7 is reset, then 0-6 are an internal command name.

For the above, 817B pushes the 123 to the stack. 01 is the command id (for now) for . (print number). 8204D2 pushes the word 1234 to the stack. 01 then prints. 7E means return from subroutine (in this case, it ends).

I will keep both a C and z80 asm version written. If I want to continue learning SH4 asm, I will get it on the prizm in asm Very Happy

<edit>

Actually have a nicer system set up for making asm built-in words. 8102810381040805097E, which is "2 3 4 - + . <EOF>" runs flawlessly and prints 1. Fun things will happen when I get looping up and going.
Major progress on my forth interpreter, with help from Runer112 Smiling Cat

I can run the following forth code right now:
Code:
s" Input: " TYPE CR TIB TIB 10 ACCEPT CR DUP #TIB ! 0x31 WORD DUP 1+ SWAP @ 255 AND TYPE CR HERE @ 255 AND . CR >IN @ . CR

Essentially, I print out "Input:" with a line break, read a max of 10 letters into the input buffer, manually adjust the buffer variables, read the first chunk in the string using 0x31 ('1') as the delimiter, then print out the copied string, print the string length `word` saved, then print out the position in the buffer (>in).

This is a 42 byte FORTH program running in an 800 byte FORTH system. Still working towards interactive and compile modes.
Just wrote an interpreter in FORTH, hand-compiled it, and it is running on-calc. Now I can write FORTH on-calc:

  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page Previous  1, 2, 3 ... 25, 26, 27, 28  Next
» View previous topic :: View next topic  
Page 26 of 28
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement