Denial

Here is a working demo program w/driver for using the NEOS mouse on the Vic-20. It shows a mouse pointer sprite on the text screen and runs on unexpanded Vic-20's. Here is a video to show what it can do.

Feel free to reuse the code if you want a 1985 mouse for your Vic-20. They are often found on ebay as part of the Mouse & cheese package for C64.

All links are updated as per August 2018:

VICE version (Unexpanded/3k Vic-20) - use Alt+Q to enable paddle input (Not used anymore as VICE was updated to support the NEOS mouse)

Vic-20 with NEOS mouse (Unexpanded Vic-20) - Also runs on VICE version 2.4.23 or later (a bug may end in swapped axes in VICE).
Source code here.

For testing in VICE: Go into Control Port menu and enable "Mouse (NEOS)". Use Alt+Q to start/stop grabbing PC mouse coordinates.

Edit: For a cut-down version which only shows coordinates (from post on page 2):

Here is a bare version of the NEOS mouse driver which shows x-coordinate and y-coordinate on screen, but no pointer/gfx. Its 360 bytes (from 7320).
Source code is here. It also shifts basic memory end to 7368, leaving you with 3272 bytes free basic mem.. Plenty for some smart assembly games

Edited: 19-Oct-2015, 2-Nov-2015

NEW VERSION UPLOADED 2-Nov-2015. Tested and debugged on a real Vic-20: NM.PRG

To do anything useful you need a 8K+ expansion for this.

I added a "menu" line at the bottom (for demonstration). You can leftclick at "LIST" and it will list the current program. "LOAD" will load the directory of device 8 and list it (I found the bug and removed it, so its working now).

I also fixed the mouse characters so that they do not get into the command/basic lines that are punched in. Scrolling also works, but there is still a bug if the pointer is left at the bottom line. Will fix that later.

You can run the demo it in the emulator, but the pointer will only travel accross the screen as VICE doesn't emulate any mouse.

There is still an interference with joy3 and keyboard between NEOS mouse and the Vic-20. This demo does not use the joy3 connection, so you can open your mouse and detach it to get the "2" and "4" keys back. I may put in a workaround later (e.g mapping "2" and "4" to function keys) if I can't find another solution. In some instances I can get the "2" key to work, but its not stable.

Update: The get both full keyboard and mouse working, I bougth a joystick extension lead on ebay and broke off pin4.

Groovy. Makes me dream of a VIC GUI.

Why dream?

http://sleepingelephant.com/ipw-web/bul ... 0&start=28

http://sleepingelephant.com/ipw-web/bul ... php?t=4374

http://sleepingelephant.com/ipw-web/bul ... f=2&t=4713

Maybe the mouse-driver could be adapted to VIC GUI

tokra wrote:Why dream?

Äck! …
Now I'm dreaming of more open–source stuff for the VIC. So much cool stuff gets forgotten too easily or cannot be reused. Sad.

pixel wrote:

tokra wrote:Why dream?

Äck! …
Now I'm dreaming of more open–source stuff for the VIC. So much cool stuff gets forgotten too easily or cannot be reused. Sad.

Open source is really not the issue. Open interface is what is needed. The real problem with all extensions out there is that they are more or less working as stand-alone-programs and fail to give any protocol on which to communicate or interact with them.

I was hoping to do something about that, but it takes a lot of time to get gfx streamlined with the kernal. Plus, it would be nice to have a STANDARD protocol to which all extensions/utilities/drivers could use to work together. So maybe we ought to start by writing a library for the kernal. Maybe it has already been done, who knows?

Open source is not the problem? The last time stamp reads 2010. You can't have a standard protocol without a bunch of people learning from each other's mistakes (EDIT: across all levels).

pixel wrote:Open source is not the problem? The last time stamp reads 2010. You can't have a standard protocol without a bunch of people learning from each other's mistakes (EDIT: across all levels).

Well, its assembly.. you can always disassemble it if you just want to modify his code. Try Ida.

Anyway, let my give an example:
-> kernal.library is an array of function calls:

word target = address in which function resides
byte noparm = parameters expected:
bit0= pass A
bit1= pass X
bit2= pass Y
bit3= pass Stack pointer
bit4-7= pass Stack (0-15 bytes)
E.g. each library function has 3 bytes.

A function call to library is like this:

Optional:
PHA stack bytes (0-15)
PHA stack pointer
PHA Y
PHA X
PHA A
Required:
PHA noparm
PHA function (0-255, library function number)
JSR library-start-address
Optional:
PLA stack bytes (0-15)
PLA stack pointer
PLA Y
PLA X
PLA A

The actual library calling is done by the library-code which is the "main" library handler (e.g. the only kernal addon). It takes the stack parameters and put them were they are expected, then pushes them back to the stack.

And so on..
------------------------------

So why all this fuzz to call the kernal? The answer is code interfacing! If you have an kernal extension/replacement and simply put in a new kernal.library, the program will still work with the new kernal extension! Not only basic but all assembly that uses libraries for function calls. So a first interpretation would probably be to make the "libraritize" program in which older programs can be forced to use the libraries. Not easy, but possible. Then you can start building a ecosystem on that.

For example: You have a GUI in which you use joystick for mouse movement. You utilize joyport.library to read a joystick-mouse. Now, a new mouse comes along and they all want it to work, so it simply replaces the joyport.library and magically the old GUI works with the new mouse.

Kakemoms wrote:Well, its assembly.. you can always disassemble it if you just want to modify his code. Try Ida.

If this is assembly I'm gonna eat a broom and put a video of it on youtube.

My programs on the VIC-20 work fine without that abstraction level bullshit.

Mike wrote:My programs on the VIC-20 work fine without that abstraction level bullshit.

D…dude… -=+< friendly >+=- computer. With sugar on top. *dug*

Interesting idea but my musings were merely philosophical.

At least things happen here constantly…

@pixel: PM sent

pixel wrote:

Kakemoms wrote:Well, its assembly.. you can always disassemble it if you just want to modify his code. Try Ida.

If this is assembly I'm gonna eat a broom and put a video of it on youtube.

Well, I wouldn't trust you gfx magicians on it being real, but it would be an interesting video.

Mike wrote:My programs on the VIC-20 work fine without that abstraction level bullshit.

Well, I would rather call it an unabstraction level to make a code interface standarized in a library. It would allow more people to understand and use the code as well.

Kakemoms wrote:

pixel wrote:Open source is not the problem? The last time stamp reads 2010. You can't have a standard protocol without a bunch of people learning from each other's mistakes (EDIT: across all levels).

Well, its assembly.. you can always disassemble it if you just want to modify his code. Try Ida.

You don't have to disassemble, just grab the code here and feel free to improve it: http://sourceforge.net/projects/vin20/
(Included is a preview of a dynamic loader called "LibTool65" and tools for the FE3)

As for the standard protocol:

The GUI is a prototype and just meant to demonstrate the possibility of having a GUI on the VIC 20 at all.
I personally use the diskmenu.prg every time I start my VIC-20 and it does all I need, so I never had the urge to add features.

For a real GUI you need a loader that is able to load drivers for your hardware and dynamically load and remove user programs. Having it all compiled into one big program would eat up too much of the precious memory.
And, of course, an interface or protocol to access the kernel functions.

Unfortunately, I did not have the time to program all that, yet.