merthsoft wrote:
I think between the three of us, the PC-side will be very straight forward (especially with TheStorm's help).
I hope so. As it stands now, the C gCnClient will be able to interpret the messages from the calculator more or less as-is; only the to-calc part will require any modification, I think.
Ok so I have reimplemented Merth's send anything and receive stuff programs in C but they both currently use blocking functions so either we use a short timeout and constantly call them as needed or we dig into the libusb-1.0 asynchronous I/O api, which is not a small task. The asynchronous api will allow much more freedom it would allow us to do things like prepare a send and a receive at the same time without threads and the nastiness that entails.

The other issue we have is support the libusb0.sys driver backend is still experimental and buggy and does not support the filter driver yet which means no TI-connect coexistence, at leas not in C. As for Merths C# version, the filter driver may work with the blocking api but I have a feeling the bugginess of the libusb-0.1 library will raise its head when we move to non-blocking/asynchronous. In either case the WinUSB driver backend seems to be stable and working well though not quite as robust as the libusb0.sys equivalents it would work with both C and C# versions but have the disadvantage of not working alongside TiLP or TI-Connect in their current forms.


I don't think there is anything I am forgetting so without further adieu...
http://jonimoose.net/calcstuff/gCnUSBstuff.zip

enjoy.
TheStorm wrote:
As for Merths C# version, the filter driver may work with the blocking api but I have a feeling the bugginess of the libusb-0.1 library will raise its head when we move to non-blocking/asynchronous.
My thing is asynch already, or am I misunderstanding something?
merthsoft wrote:
TheStorm wrote:
As for Merths C# version, the filter driver may work with the blocking api but I have a feeling the bugginess of the libusb-0.1 library will raise its head when we move to non-blocking/asynchronous.
My thing is asynch already, or am I misunderstanding something?
Really? Then I must be missing something. The libusbdotnet people must have done some fancy coding to avoid the fun that is libusb-0.1's async api. I really wonder how many code paths they must have then to support all the different configurations they support. Or maybe they have a build of libusb-1.0.dll with better libusb0.sys support IDK. I guess I'll have to poke around and see if I'm missing something here.
Maybe it hides it all and it's not, but I assumed it was. I just pass it a function to call when it gets data.
Jonimus, great work, thanks for that! I couldn't remember whether my USB HID functions for the USBHID/$10 Bridge were programmed asynchronously or synchronously, so I went and took a look at the source code just now, and it looks like the USB calls I was using just fall through if nothing is buffered with a return size of zero. As I recall, they do indeed block on send until the send completes.
Well then we're probably in the clear with that. Just set a time out and we're good-to-go.
Most excellent, then we just need to figure out what I'm missing that's making USB sending crash, hopefully something silly instead of a fundamental misunderstanding on my end, then add receiving.
*bump* It seems like the following code is making the calculator crash, but I can't seem to track down any reasoning behind it (notice that this has been derived from working backwards towards maximum code to not crash:
Code:
in a,($05)
push af
    ld a,3
    out ($05),a
    pop af
out ($05),a
This makes no sense at all. I tried to use CalcSys to manually set Port 5 from 0 -> 3, then 3 -> 0, and everything was fine. Sad Any ideas?
Why exactly are you writing a value of 3 to port 5, and then just switching it back in the first place? Something to do with link assist or pages?
graphmastur wrote:
Why exactly are you writing a value of 3 to port 5, and then just switching it back in the first place? Something to do with link assist or pages?
Port $05 controls which page is mapped to $C000 to $FFFF. Notice that I said that's minimum code to replicate the problem; before I pop af \ out ($05),a, I copy data from RAM Page 0 (ie, between $8000 and $BFFF) to RAM Page 3 (now mapped to $C000 to $FFFF). I then go back to normal mapping and call a USB call that requires data be on Page 2 or Page 3 (called Zone 1).
KermMartian wrote:
graphmastur wrote:
Why exactly are you writing a value of 3 to port 5, and then just switching it back in the first place? Something to do with link assist or pages?
Port $05 controls which page is mapped to $C000 to $FFFF. Notice that I said that's minimum code to replicate the problem; before I pop af \ out ($05),a, I copy data from RAM Page 0 (ie, between $8000 and $BFFF) to RAM Page 3 (now mapped to $C000 to $FFFF). I then go back to normal mapping and call a USB call that requires data be on Page 2 or Page 3 (called Zone 1).

Ah, I see. So it's not likely to be a delay issue. And this causes it to crash? What happens if you force page 0 to be the one that goes back.
I haven't tried that, for the dual reasons that I don't want to have to do that in case a game calling the Cn2.2 interrupt has RAM Bank B remapped, and that I was hoping it wasn't something that silly. And since this is an interrupt, it can't interrupt itself in the middle causing that problem. I might as well try that, though. The annoying thing is that it works fine on an emulator when I force it to think there's a USB cable plugged into WabbitEmu, although I of course can't actually send/receive.
KermMartian wrote:
I haven't tried that, for the dual reasons that I don't want to have to do that in case a game calling the Cn2.2 interrupt has RAM Bank B remapped, and that I was hoping it wasn't something that silly. And since this is an interrupt, it can't interrupt itself in the middle causing that problem. I might as well try that, though. The annoying thing is that it works fine on an emulator when I force it to think there's a USB cable plugged into WabbitEmu, although I of course can't actually send/receive.

Yeah, port monitor helps there for wabbit. I don't know since I can't see your entire code, but it sounds like wabbit isn't emulating some quirk about the hardware.

Okay, just tested rapidly changing port 5 back and forth. Try a small delay between remapping the ram pages.
And did your test yield success or failure when you rapidly changed it back and forth on a real calculator?
Changing port (05) with Calcsys also causes my calculator to crash. :/

EDIT: Running this:

Code:

ld a,3
out (5),a
ld a,0
out (5),a
ret

doesn't cause my calculator to crash. :/
souvik1997 wrote:
Changing port (05) with Calcsys also causes my calculator to crash. :/
Wait, really? That didn't immediately crash my calculator. Did it crash the instant you changed it, or did you quit CalcSys without switching it back?
I quit Calcsys without changing it back.
souvik1997 wrote:
I quit Calcsys without changing it back.
Oh snap.

Oh snap.

Oh snap.

You just helped me figure it out. I am SUCH an idiot. Oh god.

The stack is on that page.

By the way, if it's unclear how you helped: I was about to explain to you that the VAT is on that page, which is why it crashed when you quit CalcSys: the VAT was suddenly completely gone. As I started to type that, I realized I also should also mention that the stack was on that page. Voila.
KermMartian wrote:
souvik1997 wrote:
I quit Calcsys without changing it back.
Oh snap.

Oh snap.

Oh snap.

You just helped me figure it out. I am SUCH an idiot. Oh god.

The stack is on that page.

By the way, if it's unclear how you helped: I was about to explain to you that the VAT is on that page, which is why it crashed when you quit CalcSys: the VAT was suddenly completely gone. As I started to type that, I realized I also should also mention that the stack was on that page. Voila.

I feel special. Smile How close is this to being completed?
  
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, 4, 5, 6, 7, 8  Next
» View previous topic :: View next topic  
Page 4 of 8
» 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