sadly, I'm no longer sure if this will be feasible as an SE. the code doesn't crash on calc, however without a mouse plugged in it drastically slows down the mouse movement. with a mouse plugged in you can't move the mouse at all, either by using the mouse, or by using the keys. my guess is that its because it has to reload and initialize the driver every mouse cycle.

anywho, its fairly small, so if kerm has almost any freespace (the module takes 326 bytes and it would take less if I hadn't had to be hackish to try and get it to work as an SE.

here's the code. if you want to compile it, plz to ask me for the include files.


Code:

In the most cramped version, the Spanish version, I have about 650 bytes, so there's a strong chance I'll include it.

So this means Spanish is the most efficient out of French, English, and French?

No, it means you can't read.

Firstly it means the oppisite. Secondly you listed French twice.

EDIT: Kllrnohj beat me to the post.

pwntastic.

By 5 seconds . I'd blame that on you pointing out his inclusion of French twice.

Whoa, you definitely don't want to be re-initializing the device and killing it on every call to this.

Is there some way for you to run certain SEs with a certain code at startup and shutdown so that this will know when to init, die, and then move the mouse? If not, I highly recommend it, like what Ion does with its modules.

you can, but there is no way to ensure the driver will remain uncorrupted in memory.

[edit]

I get 2 bytes of ram that can remain uncorrupted, 1 of them I use for storing which page DCS is on.

Perhaps the SE system should be re-written then to allow for such things. Perhaps a sort of malloc call for SEs. Not sure how feasible it would be, but SEs could have a header that says how much space they want/need and DCS could create an AppVar with that size, then upon SE execution a variable (register or predefined saferam word, for example) would point to the section of the AppVar's data that the SE can use. When a program is run, the AppVar could just be archived to free up that chunk of RAM while allowing the SEs to keep their data. Of course, this wouldn't guarantee the RAM isn't corrupted by a different SE, but still...

hmmm, perhaps I can redo it a bit to optimize it, I just had an idea.

You can figure out what page DCS is on with a simple in a,(6) when your 'running' section starts.

we'll come back to that, lemme do what I just thought of doing (this optimization *won't* work if its in an app, but the way I'm setup now, it should be fine.

Well, you did mention that you'd rather be corrected than reprimanded, so there you go.

As far as the code goes, Elfprince was kind enough to include entire header including the equates, so you wouldn't need to do much more than run it through an assembler to see how done it is.

I knew that that code didn't work I was wondering if any changes to that code had fixed the issues since he posted the original code.

when I have anything resembling improved code it will be posted. until then, please only post if you have feedback/code suggestions

http://jim.revsoft.org/SEmouse.8xp

It will overwrite a portion of user ram. I suggest to used this only as a test after a ram clear. The problem is there isn't alot of safe ram.

It needs 416 bytes of ram, and 250 of code(more for better acceleration).

My first thought was that it might be possible to use the extra ram pages, unfortunately this caused nothing but complications.

If you have 32, 128, and 256 bytes ram buffers lying around this might be doable without crash or corruption.

I was using the space starting from the end of the SE to the end of appbackupscreen for the buffers, but that only works if they can be overwritten between runs.

Definitely won't work.

I didn't see any reason why remapping portions of the ram wouldn't work. I turned on the pump so the USB hook "shouldn't" try writing to memory unless I say so. My original idea was to use a portion of another ram page to store the U_call, the driver buffer, and the descriptor buffer. When I needed them I would Block remap using port 28h. Problem is it didn't work.

Normally the hook occurs when the USB triggers an interrupt. Pump however disables USB interrupts, not the hook. When I worked with the MSD driver I had my own interrupts, everything worked as expected cause I controlled everything. This time though ti-os interrupts are running. I think for some reason ti-os set the hardware to trigger interrupts again, because thats what the behavior appears to be. I'm not sure. It might still be possible to implement this in the app, it would certainly justify Kerm's mouse interface some.

I don't know, the benefit of keeping the usb data on another page is that you could keep the mouse going even with other programs without any changes to their program's code to support it. Maybe warping around USB8x's hook so you could remap the ram layout prior to it's call would be possible. Either way this would be far more practical in the app rather than a module.

Yes thanks for not singling me out and bringing light to my poor spelling.