Enterprise Forever
:UK => Hardware => Input devices => Topic started by: gflorez on 2014.September.23. 12:49:02
-
Sorry for intruding(I was spying with Google Translator...), but it would be interesting someone with a Box-soft mouse would try the new previously unknown driver (http://enterpriseforever.com/egyeb-temak/paintbox-mouse-xr/msg27260/#msg27260), MOUSE.XR version 1.1.
As I've read in that mentioned thread, it seems the interface (http://enterpriseforever.com/egyeb-temak/paintbox-mouse-xr/?action=dlattach;attach=8032;image)is pure simplicity, but the mouse itself is a rare early NEC brand and was first adapted to C64 by a second party company. Its protocol has some resemblance, but incompatible, to the Commodore official who was the Atari, Amiga, etc, joystick port, and so it isn't serial as Mészáros's mouse card.
I have found one Neos Mouse in Amazon and will receive it on Wednesday, then I will compare inside the Amiga and Neos mouses...
-
Note, I've only purchased the mouse, it lacks the interface...
-
It seems that Amiga mouses could be modded to be Neos compatible, as this Norwegian Guy (https://translate.google.com/translate?hl=es&sl=no&tl=en&u=http%3A%2F%2Fcommodore64.se%2Fforum%2Fviewtopic.php%3Ff%3D12%26t%3D985) claims to have made the opposite way in a far far past and he doesn't remember how...
The connector pins for the Amiga are soldered directly to the D/A chip, so can be Neos uses few more components(discrete) discarded for the modification.
-
The common Amiga Mouse has only two components, a NEC c339c and a condenser. But this is of the year 1992(Amiga 3000), and it could have some components integration. I have some old type ones(Amiga 500) with a look like the Neos. I must find them.
-
The Amiga 500 mouse has one similar chip than the A3000's, the CA339, but a lot of resistors.
I've read on some Amiga Blog that the designers of the Amiga 1000(before Comodore bought the firm) modified some cheap Neos mouses to work with their project...
-
It seems that Amiga mouses could be modded to be Neos compatible,
I do not understand what you would like to point to with these things ...
-
I want to make a Box-soft interface, as i have found a Neos mouse, but I want to spread the project to all who want it. "New" EGI from Nick seems to be cool with a mouse, and Neos mouses are scarcer and more expensive than Amiga mouses. The serial interface is out of my bound for now...
-
I want to make a Box-soft interface, as i have found a Neos mouse, but I want to spread the project to all who want it. "New" EGI from Nick seems to be cool with a mouse, and Neos mouses are scarcer and more expensive than Amiga mouses. The serial interface is out of my bound for now...
Yes, it is cool. Somewhere I predicted coming of mouse interfaces when I saw the EGI ...
You think that you could build the hardware devices for who would like a boxsoft interface ?
-
I'm just a fan of electronics, not a professional, but this scheme seems very simple, I've built things more difficult, but always following some scheme made from a expert.
I plan to build one for me and then, if it works,(very important....) I will spread the information here.
-
There is photos of the original interface:
[attach=1]
[attach=2]
[attach=3]
[attach=4]
[attach=5]
-
"New" EGI from Nick seems to be cool with a mouse, and Neos mouses are scarcer and more expensive than Amiga mouses.
I simply did not find a single NEOS mouse ...
But if somebody could make an amiga mouse to neos mouse converter,
then I think we could use an arbitrary usb PC mouse with a converter like this:
http://www.ebay.com/itm/Commodore-Amiga-PC-Mouse-Adapter-/141272136633?pt=UK_VintageComputing_RL&hash=item20e479bbb9
So that would be very cool, if I could use my wireless PC mouses with EP ... :)
-
Or we could use simply one of these:
http://www.ebay.com/itm/Amiga-mouse-All-Amigas-/141417764878?pt=UK_VintageComputing_RL&hash=item20ed27d80e
-
Or the possibilities would be endless:
http://www.ebay.com/sch/i.html?_odkw=amiga+pc+mouse&_from=R40&_osacat=0&_from=R40&_trksid=p2045573.m570.l1313.TR0.TRC0.H0.Xamiga+usb+mouse.TRS0&_nkw=amiga+usb+mouse&_sacat=0
-
We have to have an amiga mouse to NEOS mouse converter ... :)
But maybe that would be better having a direct device taking an amiga mouse for input, and serve the boxsoft's mouse interface's signals as its output ...
-
My Neos Mouse arrived today.
Seems it isn't so simple. Here are the two views of the inner plate.
To convert it to Amiga is only necessary disconnect the cables from the internal connector and solder the 1, 2, 3 and 4 pins of the sub-d connector directly to the 11, 13, 12 and 14 pins(respectively) of the MB88201 chip.
Modding one Amiga mouse to be a Neos mouse could(?) be made replicating the circuit from the pins of the chip to the internal connector, I though. But somebody more expert than me must do the search and find the differences....
-
And, it was made by Mitsumi Elect. like the Amiga 3000 one, not NEC.
-
We (on the hungarian thread) almost gave up the amiga mouse -> neos mouse + boxsoft way of mouse connecting ...
We would like to connect PC mouses to the EP now. If we can, wireless ones, too ... :)
Zozo is thinking about extending the boxsoft circuit with a PS/2 -> NEOS converter circuit,
and I am thinking about a microcontroller what could connect everything to the EP in a boxsoft's converter compatible way,
multi button joysticks, sega megadrive controllers, PS/2 mouses and even USB mouses ... and USB mouses can be wireless ... :)
-
I've mid-read already that thread(google translator...). That are good news!
-------------------
At the back of the mouse card is a TA7533F.
-
Inside of my mouse:
[attach=1]
[attach=2]
[attach=3]
[attach=4]
[attach=5]
[attach=6]
[attach=7]
-
Zozo is thinking about extending the boxsoft circuit with a PS/2 -> NEOS converter circuit,
Yes, the Neous mouse which are used with the BoxSoft interface using same protocol with the MSX mouses.
Then I found PS/2 -> MSX adapter (http://www.msxpro.com/ps2_msx.html), very simple circuit with one PIC microcontroller.
I think will be very simple project build on same PCB this adapter with Boxsoft interface then we will got a PS/2 mouse to Enterprise interface which are compatible with the old Boxsoft-Neos package.
-
Yes Zozo, it's the same mouse, at the backside is the a/d converter, a smd TA7533F.
I think the MB88201 is the controller chip(programmed) that changes from mouse to joystick behaviour. And could be who do the protocol, so an Amiga to MSX converter probably needs that chip, preprogrammed.....bad news.
I have an Amiga trackball connected to the internals of a striped USB Mouse(not optical). The Amiga mouses(Atari type) are very simplistic, as they give directly the movement of the disks-optocoupler pairs to the sub-d pins.
---------------------------------------------------
PS/2 to MSX!
I have a tactile surface Mouse from an old laptop PC....
-
Here (http://synpro.heimat.eu/mousecon.htm) is a page describing ps/2 and Amiga protocol converters to MSX mouse.
---------------------
Attached below are the schematics of a MSX Mouse from Phillips. the same preprogrammed MB88201 microcontroller but few more components.
Observe the pinout of the sub-d connector, 8 is STOROBE, +5 is on 5, ground is on 9, Left sw is at 6 and Right sw is at 7. Too much different to the Boxsoft mouse.
According to this page (http://www.faq.msxnet.org/connector.html) STOROBE is necessary for a MSX mouse as the joystick port acts as a serial port(?)
Is the Boxsoft a re-re-modified mouse?
-
Viewing the schematics: convert Neos mouse (MSX like) to Amiga: remove wires from the Left/Right/Up/Down outputs of controller then connect these to the XA/XB/YA/YB inputs (output from the sensors). The controller totaly not used in Amiga mode.
When opened the Amiga mode Neos then connected the wires to the controller input pins?
Then I think just needed to put back these to the connector. Because the controller not used then possible it is contain the original program. Probably lot of original Neos mouse are unsold then these converted to Amiga by the simple wire replacement?
-
Please, re-read the last post as I've edited it some...
-
I don't have the modified Neos mouse I only extracted the pictures HI-res from that web (http://commodore64.se/forum/viewtopic.php?t=985&p=4868). The Amiga mouses are simplistic and the computer does all the work, so here our Boxsoft Neos mouse does it by a micro controller. But is some different in its pinout than a MSX mouse.
-
According to this page (http://www.faq.msxnet.org/connector.html) STOROBE is necessary for a MSX mouse as the joystick port acts as a serial port(?)
For the strobe signal used one wire from the serial port. It is connected by jack plug to the main adapter. When it is inserted then Mouse mode, if not inserted the Joystick mode can be used.
Is the Boxsoft a re-re-modified mouse?
Yes it is a C64 version, I think some wires reordered. But the communication protocol same with the MSX. Will be interesting found MSX one and open it...
I will measure my mouse wires, and write down the pinout with wire colors.
-
I don't have the modified Neos mouse
Which Neos you have? You wrote you bought one from Amazon.
-
I "only" have the UNmodified one of the last two pictures in this post (http://enterpriseforever.com/hardware/re-paintbox-mouse-xr/msg40869/#msg40869).
--------------
On one web page they warn to not connect an Amiga mouse to a MSX mouse port, as the +5 pin is on the wrong one... you can fire "some" the MSX computer...
It can be interesting to extract the firmware of the MB88201, only 512 bytes(or 1k x 4bits) according to its datasheet.
-
I "only" have the UNmodified one of the last two pictures in this post (http://enterpriseforever.com/hardware/re-paintbox-mouse-xr/msg40869/#msg40869).
I will document my mouse wiring and you compare on your mouse.
-
It can be interesting to extract the firmware of the MB88201, only 512 bytes(or 1k x 4bits) according to its datasheet.
Yes, will be interesting but it is a Mask ROM. Programed in the factory during the production, not with a external device :-(
-
Then, it can be the c64 Neos mouse has another firmware than a MSX mouse...... do We need to know that before doing more?
-
Then, it can be the c64 Neos mouse has another firmware than a MSX mouse......
I think it is same. When I started search about how working the Neos mouse, firstly search C64 things. Found some disassembly of the Cheese Paint (what bundled with the Neos). And finally found this is working same as the MSX protocol.
Anyway the C64 Neos Mouse are different, and not compatible with the other C64 mouses.
-
I'm talking abut that Phillips MSX mouse(or others). Can they share the same firmware with the Neos as both have the MB88201 controller? If not, that ps/2 to MSX converter couldn't suit us...
-
I'm talking abut that Phillips MSX mouse(or others). Can they share the same firmware with the Neos as both have the MB88201 controller?
I think yes. The protocol same, just the pinout different because different power pin location on MSX and C64 (and compatibles).
Lgb wrote the mouse emulation in Jsep by using MSX documentation, and working with the original Boxsoft driver.
-
Wire colors of my mouse (Pin numbers of the D-SUB connector)
1 Brown
2 Red
3 Orange
4 Yellow
5 --
6 Blue
7 Gray: +5V
8 White: GND
9 Black
Power at the C64 location.
-
Mine are the same, and go to the internal connector of the mouse in this order:
D-Sub color signal internal conn.
pin pin
---------------------------------------------
1 Brown Up 4
2 Red Down 3
3 Orange Left 2
4 Yellow Right 1
5 -- -- --
6 Blue R Sw-Strobe(RTS) 7
7 Gray +5V 6
8 White GND 5
9 Black L Sw 8
We have lost the R-switch in the c64 conversion and, at the end we have a spare pin...
-
We can separate the STROBE signal and the R-Switch inside the Neos and use pin5, as on the Atari-Amiga connector pin 5 is only used for Pot-y(no problem with short circuits inserting a joystick or other devices). Then we can use pin 5 only for STROBE and pin 6 only for the R-Switch(or vice versa).
With few modifications we can ignore the 3.5 Jack commutator. Only need a new cable(9 wires) and connector.
We are setting the new EP mouse standards.......
-
For backward compatibility, I think is better to leave STROBE(RTS) at pin 6 and the R-switch moved to pin 5.
In real EP I don't know how EGI reacts to the R-switch(I think it is unused, doesn't it?), but pressing it on the unmodified Neos mouse potentially interrupts the flow of data, as it directly joints pin 6(STROBE) with pin 8(0 v).
-
Only right button working in mouse mode, and only Left button working in joystick mode. And pressing Left in mouse mode stop the mouse.
-
Ok, I could have changed "some" wire, but one of the switchs short-circuit the STROBE signal.
-
but one of the switchs short-circuit the STROBE signal.
Yes.
-
But build the combined PS/2-MSX-Boxsoft adapter then possible to use two buttons.
-
I´ve bought a mouse adapter from PS /2 to MSX on Ebay. I'll change its pinout to be exactly as the Neos mouse but with the conflicting button L on the unused(by the Neos) pin 5.
The Boxsoft interface is still unfinished but I'm not in a hurry as actually only have tape to save or load files.
-
I will not combine the two adapters because the Boxsoft is still useful as a joystick port.
But ....... I can do the Boxsoft with two D-Sub connectors in parallel. I have to think how to do it, but I think, if the mouse is not used, does it interfere with the joystick switchs? Does it keep sending data?.
On the other side, an unused joystick without autofire isn't seen by the computer.
Some sort of switch will do...
-
I still need the Strobe(RTS) signal from SERIAL port so it will do the selection mouse-joystick as in the original, but without the embarrassing commutation of the left button.
-
I still need the Strobe(RTS) signal from SERIAL port so it will do the selection mouse-joystick as in the original, but without the embarrassing commutation of the left button.
Yes. The problem with the shared line come from the C64 wiring of the Neos.
-
I still need the Strobe(RTS) signal from SERIAL port
I just realized, you know the name of the "Strobe(RTS)" signal of the boxsoft <-> EP communication ...
Do you know all of the details of the boxsoft <-> EP communication ?
Where can I find those details ?
-
You have all the details yet, Zozo assured Neos has the MSX protocol as he had read the Mouse-Cheese disassembly of the C64 . But you can see the disassembly of the mouse.xr version Hisoft (http://enterpriseforever.com/egyeb-temak/paintbox-mouse-xr/?action=dlattach;attach=7915).
It's a four bit parallel protocol with a strobe signal and, as the JOY ports of the EP can only read but not send data, the boxsoft uses RTS from the sparsely utilized SERIAL port.
On the other side, I found the schematics of a MSX Phillips mouse (http://enterpriseforever.com/hardware/re-paintbox-mouse-xr/?action=dlattach;attach=10999) and there they name "STOROBE" to that signal.
-
Zozo assured Neos has the MSX protocol
Is the MSX protocol achived on joystick connectors, too ?
As far as I know EP can only read 3 bits on a joystick port, and not 4.
So how does it read the 4 bits ?
How does exactly the strobe signal work ?
On what pins does the EP want and which bits of the values of MSX protocol ?
I would not like to read mouse.xr dissassembly or such things ... If somebody already did that ... Nobody did that, yet ?
-
Then, in this MSX faq page (http://www.faq.msxnet.org/connector.html) they say this about the protocol:
"The system works as follows:
The MSX Mouse sends 2 signed bytes to the computer, X and Y. This byte must be added to the current X and Y location, so it is a relative movement. So X=0 means X is the same, X=1 means X=+1 and X=255 means X=-1. This is very easy to implement, however it poorly supports mouse speed control, because it's a digital signal. Well, anyways, those 2 bytes are transferred in 4 parts. The computer reads pins 1-4 four times, afterwards signalling the mouse to ready the next 4 bits by complementing pin 8."
------------
The protocol needs the signals to be in a specific pin, as uses combined the wires Up, Down, Left, Right(pins 1 to 4), to send a 4 bit number four times to do two signed bytes. And then Strobe(pin 8 on MSX but pin6 on Neos) is needed to do the transaction.
The problem with C64(new Atari standard) was it had the 5v pin at pin 7, not at pin 5 as MSX do so, to make the Neos work on the C64, they rearranged some pins of the standard to avoid a short circuit....
-
This is okay, but this does not specify the strobe sign, and the 4 bit partition either ...
And the bit partition must be different on EP, because EP will not read 4 bits paralell ... I think ...
-
MSX mouse protocol (http://synpro.heimat.eu/docs/msx_mouse_principle.pdf) (don't care with pin numbers)
-
In fact EP reads five pins in parallel if you count fire....
-
This is okay, but this does not specify the strobe sign, and the 4 bit partition either ...
And the bit partition must be different on EP, because EP will not read 4 bits paralell ... I think ...
But these are questions, still ...
-
But these are questions, still ...
What is the problem? Read one and one and one and last one.
-
In fact EP reads five pins in parallel if you count fire....
As far as I know, unfortunately it does not.
It can read only 3 bits PARALELL.
In fact, when somebody read the five "input" of a joystick on EP,
they read that on a single bit, in SERIAL way.
-
What is the problem? Read one and one and one and last one.
With a serial way ? Like PS/2 ?
Wich will be the first bit ? In the stream ? In a message ?
-
No, you read all switches in one row with an "IN A, (port)". isn't it?
-
Wich will be the first bit ?
What you want.
Mouse put 4 bit to the joy 4 direction wire.
4 bit is stand.
You can read 0,1,2,3. Or 3,2,1,0. Or 0,3,2,1 Or 2,3,1,0 Or...
-
No, you read all switches in one row with an "IN A, port". isn't it?
No, with one "port out" and one "port in", you can read 3 bits.
In practice, games read the 5 joystick input in SERIAL way,
with 5 port out and 5 port in.
-
No, you read all switches in one row with an "IN A, (port)". isn't it?
No, you can't do this on Enterprise.
-
What you want.
Mouse put 4 bit to the joy 4 direction wire.
4 bit is stand.
You can read 0,1,2,3. Or 3,2,1,0. Or 0,3,2,1 Or 2,3,1,0 Or...
Do you think mouse or boxsoft ? Cause I speak boxsoft<->EP ...
But okay, I will know which direction (bit) EP wants from me from 4 bits (without the order, I would not like to probe all combinations ...:)),
But how do I know which 4 bit is the actual one ? Which 4 bits of which byte in the message ?
-
I will not have a real MSX mouse, converting the 4 bits only ...
My mouse will be ps/2, I have to give the "bytes" in the protocol, too ...
-
Ok, ok I've mistaken the System joystick call(that returns all the bits in a row) with the real joystick reading. Sorry
-
Do you think mouse or boxsoft ? Cause I speak boxsoft<->EP ...
Boxsoft don't do anything conversion with the mouse signals, just electricialy interfacing it. If anything output on 'Left' wire on mouse you can read as 'Left' direction of EP joy port.
You can also connect Amiga or Atari ST mouse to the Boxsoft interface, will work. (Just need a full CPU power for handle it, then practicaly not useable with EP)
-
Boxsoft don't do anything conversion with the mouse signals, just electricialy interfacing it. If anything output on 'Left' wire on mouse you can read as 'Left' direction of EP joy port.
You can also connect Amiga or Atari ST mouse to the Boxsoft interface, will work. (Just need a full CPU power for handle it, then practicaly not useable with EP)
Okay ... but see from my side ...
I am the microcontroller connected to the EP,
I have relative mouse coordinates from the PS/2 mouse,
EP wants from me 4 bit of the information at once (responding to the direction wires),
but how do I know wich 4 bits of the X,Y relative mouse coordinates required just now ?
-
Z80System. Now I understand. You need how and where the information flows, the protocol inside.
Then you must read and understand the Mouse.xr disassembly.....
-
I've disassembled the PIC16F628A code of the ps2 to MSX proyect (http://www.msxpro.com/ps2_msx.html), but I hardly can understand it....
-
As far as I can remember (when I wrote the support for JSep to emulate boxsoft mouse interface): writing to port B7 bit 1 should change its value, which triggers the interface to provide the next "half byte" (that is, 4 bit), since MSX mouse seems to support this 4 bit thing stuff. The order is something like this: high nibble of X motion (motion = 8 bit signed value of the motion since the last read or such, provided in two 4 bit chunks/nibbles/half bytes), low nibble of X motion, high nibble of Y motion, low nibble of Y motion. With the mentioned "strobe" signal, you can "step" which one you want to read. Now, how you can read your 4 bits then? Use port B5 you would use as with keyboard too to select the bit within the current "half byte" you want to examine. And then, read port B6. It will give the state of the selected bit of the current 4 bit of the 8 bit movement of the X/Y :D Madness, I must to say. So, reading B6 port, bit 0 is the final result. Bit 2 gives the state of the mouse button, for me it seems it does not depend on the selection but always (?) but I am not sure. At least I emulate button this way in JSep and it seems working.
I am not sure this is what you are interested in, or not and I should go back to sleep :)
-
I am not sure this is what you are interested in, or not and I should go back to sleep :)
Yes, I was interested in this,
and more.
I think you left out wich bit (or value) in a b5 port write (alias joystick direction) is wich bit of the 4 bit "half byte" ... there are many combinations,
and I do not know an other thing, too:
You specified the order of the "half bytes" like XHigh,XLow,YHigh,YLow ... but its a looped thing ...
When I'm a microcontroller, I know the order, which one to send after which one, okay,
but I do not know "when the first is", or "which are just now" ...
So, I just turned on the EP, mouse.xr starts run, reading XH,XL,YH,YL again XH,XL,YH,YL again XH,XL,YH,YL again XH,XL ...
and NOW, I connected the converter (the boxsoft, or my microcontroller thing), mouse.xr will want to read YH next, because that is the next in its order,
how will I know which one is wanted by mouse.xr ?
When I know it, I will know the next one from the order ... But what is the current, at the connectiong of the interface ?
-
So, I just turned on the EP, mouse.xr starts run, reading XH,XL,YH,YL again XH,XL,YH,YL again XH,XL,YH,YL again XH,XL ...
and NOW, I connected the converter (the boxsoft, or my microcontroller thing), mouse.xr will want to read YH next, because that is the next in its order,
Please think in 1980' years: everything needed to be connected before computer power on! These not a USB plug and play days :-)
-
I think that pic disassembly has all the clues you need. Is very short but it contains the PS/2 and the MSX parts, and how they interact.
It is worth to study some pic asembler.
And don't worry for the EP part, as Mouse.xr already knows how to read a MSX mouse.
-
Please think in 1980' years: everything needed to be connected before computer power on! These not a USB plug and play days :-)
Are you sure about this ?
There can be a simple way to signal a "message start", for example two strobe signal close to each other in time, or such ...
In your case anyway, when you connect the boxsoft stuff into a working EP (with a running mouse.xr), the mouse have to work wrong ...
-
It is worth to study some pic asembler.
I am not really a reverse engineer type of guys ... I do that only when I have to ...
If lgb knows the answers, those will be good for me ... :)
-
Please think in 1980' years: everything needed to be connected before computer power on! These not a USB plug and play days :-)
The cartridge hardware was designed to be hot-swappable - that is why the power "fingers" on the edge connector are longer than the others (power is connected first/disconnected last). But because BASIC ended up using the cartridge this turned out not to be useful :oops: But you have probably noticed when at the "ok" prompt you can unplug the cartridge and plug it back in again and then just continue as though nothing had happened (as long as you have nothing else in the cartridge ROM with interrupt code!)
-
The cartridge hardware was designed to be hot-swappable - that is why the power "fingers" on the edge connector are longer than the others (power is connected first/disconnected last).
I also guess it is hot swappable, because the power pins. Now it is sure, thanks for the info!
But you have probably noticed when at the "ok" prompt you can unplug the cartridge and plug it back in again and then just continue as though nothing had happened
:shock:
I will try it!
-
But you have probably noticed when at the "ok" prompt you can unplug the cartridge and plug it back in again and then just continue as though nothing had happened (as long as you have nothing else in the cartridge ROM with interrupt code!)
Wow!
I do not think anybody tried that thing, before now ... :)
-
I do not think anybody tried that thing, before now ... :)
I tried but with German cartridge, with the additional BRD extension, then the system froozen :oops:
Now try again with UK only :-)
-
I tried but with German cartridge, with the additional BRD extension, then the system froozen :oops:
Now try again with UK only :-)
I don't think it will work if anything in the ROM hooks into EXOS, but with the the original plain BASIC cartridge and EXOS internal ROM it should. It works because when it is at the "ok" prompt it is inside the editor device executing 100% from the internal ROM, and only returns to BASIC when you press a key (or maybe you can even type and it just returns to BASIC when you press ENTER?)
-
In this (http://www.msx.org/forum/msx-talk/hardware/use-10eu-connect-modern-mouse-msx) page someone has made yet the PS/2 to MSX mouse adaptor with an Arduino, and the code is there.
-
Even it seems to work with USB mouses.
Edit: No, only if they work in PS/2 mode...
-
From the page:
Usually USB-mice that are produced before 2010 support PS/2 protocol out of the box.
I think real usb mouses will not work with this ...
-
This is redundant, but here (http://www.msx.org/wiki/Mouse/Trackball#Direct_usage_of_mouse) is a routine to read directly a mouse on a MSX computer. It can be adjusted to work on EP, but we already have Mouse.xr.
; A routine to read the mouse:
;
;
; LD D,&B10010011 ; Use these values for a mouse in port 1
; LD E,&B00010000
;
;
; LD D,&B11101100 ; Use these values for a mouse in port 2
; LD E,&B00100000
;
; Read the mouse. Input: D/E=.... Output: H=X-offset, L=Y-offset
; Note that the routine will output H=L=255 if no mouse is present!
GTMOUS:
LD B,WAIT2 ; Long delay for first read
CALL GTOFS2 ; Read bit 7-4 of the x-offset
AND 0FH
RLCA
RLCA
RLCA
RLCA
LD C,A
CALL GTOFST ; Read bit 3-0 of the x-offset
AND 0FH
OR C
LD H,A ; Store combined x-offset
CALL GTOFST ; Read bit 7-4 of the y-offset
AND 0FH
RLCA
RLCA
RLCA
RLCA
LD C,A
CALL GTOFST ; Read bit 3-0 of the y-offset
AND 0FH
OR C
LD L,A ; Store combined y-offset
RET
WAIT1: EQU 10 ; Short delay value
WAIT2: EQU 30 ; Long delay value
GTOFST: LD B,WAIT1
GTOFS2: LD A,15 ; Read psg register 15 voor mouse
OUT (0A0H),A
LD A,D
OUT (0A1H),A
XOR E
LD D,A
WAIT: DJNZ WAIT ; Extra delay because the mouse is slow.
LD A,14
OUT (0A0H),A
IN A,(0A2H)
RET
-
This is my ugly attempt to build a Boxsoft mouse interface. It seems to work, at least as joystick interface. I'll load Mouse.xr and try it with the Neos.
-
Not bad to the eyes ! :)
With what kind of tool did you do the cuttings on this type of PCB ?
-
Good work! :smt038
-
The board is of fiberglass. I begun to cut the tracks with a knife, but is easy to slip. It's better with a Dremel or simmilar.
-
I thought of the wires actually, not the whole of the PCB ... Some of the cuts of the wires of the board are nice and even ...
When I cut a wire, it is usually not a straight even line ...
-
It is not a secret. I weld the components and bend some the wires until they broke.
Then usually I re-weld. That´s why you don't see the cooper.
This all in the middle of checking, checking and checking.
-
Okay, maybe we did not understand each other,
so I think of this on the picture.
That vertical cut of the wires of the PCB is made by you, isn't it ?
When I cut a wire of the board (usually I scratch the wires through with a knife or scissor) that will not be such straight and even at the edges of the cut.
-
Ok, then it is the first answer. I used a Dremel steel point with a conic shape the point that size. Then you only have to tilt the Dremel and drag and dig the track like writing. The 7134 in this picture:
-
Ahhh ... I see now ...
I thought these "dremels" are more like saws ...
Probably I have to get one in the (not too far) future ...
-
I've made some test with the interface. The various versions of Mouse.xr all load and install. The driver is visible with :help. on the other side Paintbox hangs at loading...
I've tried then with the basic program inside the instruction booklet, but it stops when intents to open the mouse channel. "Device not found" or something similar.
The original schematics have been followed except for the switches, they seem to be swapped in the table.(RTS needs sw2 be ON and sw1 OFF)
If I disconnect the RTS jack and put a joystick in the D-SUB port it works fine( for example: 10 print joy(1): 20 goto 10), the four directions and fire.
And about the mouse, they(Neos instructions) say it has a joystick mode when you power on with the left button pressed. Mine not, it only returns 16 with fire and 1 or 2 with the directions movements when in that state.
-
Still I have not tested the PS/2 to MSX conversor. I think my Neos mouse has some fault.
-
I think, may be the two modes(mouse, joystick) are interchanged, as if the normal mode(without pressing left switch at the start up) could be the joystick mode.
I will test this and the PS/2 adapter at night.
-
Which MOUSE.XR used?
-
I have loaded almost all, including Hsoft and the version coming with EGI.
-
*** Device does not exist.
Do you know what checkings do the Mouse.xr driver to return this error?
Some more testings:
The only mouse.xr that seems to allow open the mouse channel is the 3352 bytes version. I can see the pointer flashing randomly by the screen in the two modes.
Hsoft driver hangs at loading.
I must test RTS output at serial port with "out (0xB7),2" and then 0.
-
RTS output is working. The error was on the short piece of wire, regained from a broken power suply... Now I know it was what was broken...
More tests this night.
-
I've changed the wire but still not working.
I have yet redirected the pins of the PS/2 to MSX adaptor, but it doesn't react.
The problem here is, I think, the RTS on/off state doesn't reach the STROBE pin of the mouse. All the Mouse.xr drivers test this before let open a channel, all except the 3352 bytes version.
RTS is 0v or 12v(here the reference is 0v), but seems STROBE needs 0v or 5v. May be the signal is to much weak due to the the resistor's tolerance. The values(colours) match, but I will test physically if they are right.
-
The modified switch(normally open) of the jack 3.5 base was the offender....
Now it works.....but only with the 3352 bytes version of mouse.xr(I'm loading them with EPTE, so could exist some error with the tape files). The Neos mouse has some fault and only throws horizontal coordinates(?). But it is smooooooth....
On the other side the PS/2 to MSX converter works like a charm. The two PS/2 mouses tested have a high dpi and so are excessively fast, but I can manage them.
I have used this little program for the test:
100 GRAPHICS
110 SET 180,101
120 SET 181,30
130 SET 182,1
140 SET 183,255
150 OPEN £1:"mouse:"
-
Only a little drawback: the directions from the converter are mixed:
Up is Left.
Down is Right.
Left is Up.
Right is Down.
May be another modification of the Neos or bad programming inside the adapter?
-
MOUSE.XR versions:
2842 bytes: come with Paintbox 1.0, inside the file MOUSE version 1.0, but don't see in the HELP list. It is only works with NEOS mouse. If no Mouse then the cursor going to right bottom corner
3352 bytes: also MOUSE version 1.0 and displayed in the HELP list
It is have the 189 EXOS variable which used for select the input device: 0 Internal Joy, 1 Ext1 Joy, 2 Ext2 Joy, 3 Neos Mouse. Under the paintbox the selection works with F keys.
Then this version also works with joystick and mouse, but I can't press fire :oops:
3178 bytes: same with the previous, but fire working :-)
3196 bytes: lates find from Nick disks. MOUSE version 1.1, joysticks and NEOS mouse also working.
3072 bytes: come with the Hungarian release of the Paintbox, NEOS support removed, only works with joystick
3389 bytes: HSOFT modified the previous version, added support for Gyula Mészaros serial interface card with Mouse System serial PC mouse. (And no NEOS)
-
On the other side the PS/2 to MSX converter works like a charm. The two PS/2 mouses tested have a high dpi and so are excessively fast, but I can manage them.
Great news!!!
-
The Neos mouse always returned 1 or 2 on joystick mode too, left and right, so something in the vertical decoder is wrong.
As I don't see one evident fail in its electronics I´ve bought another one on Ebay (http://www.ebay.com/itm/281458548501?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649).
Patience, only a couple of weeks.
-
Meanwhile I'll adapt a serial trackball with a PS/2 ball mouse. Also I have a touch surface from a laptop that I can connect.
-
I've tested almost all PS/2 mouses I've found. Even the slowest ones double, quadruple or more the DPI of the Neos mouse, that have the best feeling moving "slowly" but accurately pixel by pixel.
All do strange jumps to the following position, then they seem to work like the internal joystick cursor, that jumps by character cell to character cell, but very fast.
That about velocity, but all have the wrong response to direction, as I described earlier.
Correcting the directions in a ball mouse is easy, but I don't know how to do it on an optical mouse.
Better could be to modify a Mouse.xr driver especially for that PS/2 to MSX converter, dividing the resolution and correcting the directions in the software.
But for me can be a hard work...
-
The russian MSX converter have a resolution jumper. And also support joy mode.
I try to build one, but currently don't detect the mouse :oops:
-
Mine is www.KMTech.co.uk from Ebay, and also has a resolution jumper, but without it the DPI is even greater....
-
I have the trackball almost finished, and today arrived the Neos replacement. At the side a PS/2 touch surface rescued from a broken laptop.
-
These things surprisingly goes well to each other ...
(Maybe this was a direct translation of a hungarian expression what does not mean anything in english...)
So ... these thing surprisingly pass to each other ... :) Or such ...
-
Yes, they mix and match like an orthopaedic leg and a false teeth...... Joke :lol:
If you expand view of the picture you can see the frame of the touch surface is indeed a chunk from a laptop, raw cut with a shaw.....
-
Ok, now the "new Neos" mouse(and all PS/2 device thrown to the adapter...) works fine but still only with the 3352 bytes driver. Why?
When I run the little test program, all the other usable versions(2842, 3178 and 3196) give the error:
*** Device does not exist.
150 OPEN £1:"mouse:"
Even when some of they show the driver loaded when you write :help.
Zozo, I've seen the 3352 bytes version is a relocatable module, can you extract it to compare with the disassembly of the 3178 version?
Do the other versions work for you? May be the problem my "actual" configuration?
-
I've extracted it by myself. I will disassemble it and compare the code, but I'm not good at it....
Org is at 0x12DB(4827dec).
-
Try :PB command after loading MOUSE.XR then start the BASIC program.
-
I've tried several times to load Paintbox, but it freezes. So then I tried only with the Mouse.xr drivers. Maybe I have to execute :mouse then...
-
No, ":mouse" doesn't work on any case, neither ":help mouse". The info is only shown with ":help" alone.
Neither Kevin Mount, the author of the "PS/2 to MSX mouse adapter", answers me...
I think the only way is to modify the driver that works. First making "Fire" button work, and then doing two versions, one for the Neos alone, and the other for the adapter.
I'm yet disassembling.
-
Not a :MOUSE, use :PB! This is originaly command from the Paintbox to MOUSE.XR, which is add the MOUSE: device to the system.
Then you can open MOUSE: channel.
-
Ok, then. Now all versions applicable work for me. Curious, they load the driver but don't run it... and then the wrong command ":pb" produces "***Channel exists", but makes it work....
It could be interesting to know why this behaviour an how to fix it.
May be the relocatable extension does better the task and the others not?
-
Observing the two codes:
3352 bytes version:
label_12e4h: ld a, c
cp a, 4h
jr z, label_1312
cp a, 3h
jp z, label_133b
cp a, 8h
ret nz
call label_14ee
ld a, (1353h)
set 6, a
res 7, a
ld (1353h), a
---------
And the 3178 bytes version:
loc_C0A9: ld a, c
cp 4
jr z, loc_C0E9
cp 3
jp z, loc_C112
cp 2
ret nz
ld a, (de)
cp 2
ret nz
inc de
ld a, (de)
dec de
cp 50h ; 'P'
ret nz
inc de
inc de
ld a, (de)
dec de
dec de
cp 42h ; 'B'
ret nz
call sub_C2C5
ld a, (byte_C12A)
set 6, a
res 7, a
ld (byte_C12A), a
------------
It seems that only suppressing a few lines from the very first routine the driver auto-activates itself at the loading.
-
Only changing with an hex editor that "CP 2"(0xfe02) with a "CP 8"(0xfe08) and a row of "NOP"(0x00) the 3178 bytes version can be made auto-start.
-
I would like to make a mouse.xr version working with my PS/2 mouse hardware.
After your studies, will you have enough information to describe how I can modify the mosue.xr with my (approximately 4-6 instruction length) mouse reading code,
and how I can place the coordinates to the right places in mouse.xr, from where mouse.xr can give it forward to the applications ?
-
Sorry, I'm not a programmer. It only jumped to my eyes comparing the two codes, but I plan to study it more to find where I can invert the coordinates or make the movement more stable for the converters. I will inform if I find some important.
-
Here you have a 3178 bytes version Mouse.xr modified to auto-start. It lets you open a mouse channel without first send ":pb".
It works, at least on the partially approached mouse function of the emulator.
-
Great work! :smt041
-
Thanks. I hope it is only the beginning...
-
Kevin Mount has answered me. He said he doesn't have any more the object code of the adapter's PIC(an issue with an ex-employee...). But he said it is not protected and gives me permission to modify it if I manage to read into.
How can I read that code?
-
How can I read that code?
Need a chip programmer which are support PIC chips.
Anyway if you buy, then look one which are also support Flash ROMs, will be useful :-)
-
Wich one can be recommendable?
-
There is this Chinese programmer (http://www.ebay.es/itm/Programador-USB-memorias-EEPROM-UNIVERSAL-ADAPTADORES-Electronica-automocion-/231385464824?pt=LH_DefaultDomain_186&hash=item35dfa5fff8) on Ebay.es that claims to access up to 12.000 chips (http://www.autoelectric.cn/minipro/MiniProSupportList.txt).
It is more cheap if I buy it from China.
-
There is this Chinese programmer (http://www.ebay.es/itm/Programador-USB-memorias-EEPROM-UNIVERSAL-ADAPTADORES-Electronica-automocion-/231385464824?pt=LH_DefaultDomain_186&hash=item35dfa5fff8) on Ebay.es that claims to access up to 12.000 chips (http://www.autoelectric.cn/minipro/MiniProSupportList.txt).
As I see in the net it is very popular model. It is support lot of PICs, and Eproms and Flash Roms what used with Enterprise.
-
Ok, I opted for a HK based vendor that sells more adapters but arrives later..... min 15 days but max 30.....
-
Meanwhile I've been comparing the code of the Mouse.xr 3178 bytes version with the new found 1,1 from Nick's. They are almost the same, then I've inserted the supplementary code on the disassembly of the 3178 bytes version.
I have to study it to know what it does.
-
The modification made on version 1.1 doubles the movement readed from the mouse, but only in values greater than 1 or -1. Then it adds some "velocity" to the cursor.
-
The modification made on version 1.1 doubles the movement readed from the mouse, but only in values greater than 1 or -1. Then it adds some "velocity" to the cursor.
Good work! :smt038
-
I'm not totally figured out the driver, but in my humble opinion, it is very well created.
It has all its variables inside, doesn't need to allocate memory, but then it can´t be converted to a Rom unless it is rewritten.
Basically is an EXOS device, and what the routine does is to Link it to the system, providing a "Device Descriptor" as explained in the Kernel Specification chapter 6.2.
Then Mouse.xr has all the entry points of a device, although some aren't used.
The most important one is Interrupt, that executes a mouse read and a redraw every 50Hz, provided that a mouse channel has been Open-ed, another of the valid entries of the driver. To do the task in this little time, the different positions of the cursor in the screen coordinates have been pre-calculated for the three most used graphics modes, 1, 5 and 15. The other modes return the 221 error: *** Invalid video mode.
To use another interface, I've seen it's better to modify the sub_c3c8 call, as is there from where the computer synchronizes with and reads the Neos mouse.
sub_C3C8:
;Joysticks
ld a, (byte_C680) ;input device, EXOS variable 189, default 3
cp 1
jp z, loc_C32A ;go to external joystick 1 reading
cp 2
jp z, loc_C32F ;go to external joystick 2 reading
or a
jp z, loc_C325 ;go to internal joystick reading
;Here begin the Neos mouse reading, "byte_C680"=3
ld hl, byte_C685 ;first byte
ld a, 2 ;RTS low
out (0B7h), a
ld b, 8 ;long delay
call sub_C46E
call sub_C4A0 ; read four higher bits
rld ;push them in (HL)
xor a ;RTS high
out (0B7h), a
ld b, 5 ;short delay
call sub_C46E
call sub_C4A0 ;read four lower bits
rld ;push them in (HL)
ld hl, byte_C686 ;second byte
ld a, 2 ;RTS low
out (0B7h), a
ld b, 5 ;short delay
call sub_C46E
call sub_C4A0 ;read four higher bits
rld ;push them in (HL)
xor a ;RTS high
out (0B7h), a
ld b, 5 ;short delay
call sub_C46E
call sub_C4A0 ;read four lower bits
rld ;push them in (HL)
xor a
out (0B5h), a
in a, (0B6h)
and 4 ;state of the alternate Fire key saved on "byte_C67F"
srl a
srl a
xor 1
ld (byte_C67F), a
call sub_C4B1 ;this is the "corrections and drawing" routine where the "velocity" 1.1 modification was made
ld a, (byte_C685)
ld c, a
ld a, (byte_C686)
or c
ret
Then, if you put some value in "byte_C685" and "byte_C686" they are added to the actual position of the pointer. I think if I swap them I can fix the bad orientation of my PS/2 to MSX mouse adapter. I will try....
-
I'm thinking that since the PS / 2 mice reading gives too high values to be pixel accurate and, as PS/2 mices have already the velocity built inside, I could divide the data by two, the inverse of what the modification 1.1 does.
But, how can I fast divide by two or four a twos complement?
I have planed it preserving bit 7 and doing one or two right shifts pushing at the left some 0's on the positives or 1's on the negatives.
-
But, how can I fast divide by two or four a twos complement?
I have planed it preserving bit 7 and doing one or two right shifts pushing at the left some 0's on the positives or 1's on the negatives.
You need SRA r - that's exactly what it does! (Shift Right Arithmetic). Compare with SRL r, Shift Right Logical, which always shifts zeros in.
-
Ok thanks...
-
Disassembly of ALL MOUSE.XR versions.
-
Great!, it gives me more clues to understand how it works. For me the best is the 1.1. I'll modify it soon to work with my PS/2 adapter...
-
The only drawback I see to Mouse.xr: it hardly can work with turbo machines, the delays on the reading routine must be modified.
-
The only drawback I see to Mouse.xr: it hardly can work with turbo machines, the delays on the reading routine must be modified.
Yes, it is true.
-
I've made three modifications to the 1.1 driver, auto-link, swap coordinates and two SRA,a instead of ADD a,a. Now it is completely quiet in its behaviour...... except when I move it excessively quick, as it loses track.
But I think it is a problem of the PS/2 converter, not from the driver nor my "fixes", it acts the same with the unmodified driver.
Still waiting for the Eprom programmer.
-
I forgot to put an auto-link Mouse11.xr. For the Neos mouse only.
-
At last I got the PIC programmer.
Now I have the code from inside the PS/2 adapter and...... surprisinly it's exactly the same as the Brasilian project, modified from the Japanesse one.....
So Kevin Mount lied me and he borrowed that code and project as his.....? I don't know.
Now is time to study some PIC assembler....
-
I possibly could(?:oops: ) change the content of my adapter, but I wonder: will not be better to use the adapter described on the MSX.org (http://www.msx.org/forum/msx-talk/hardware/use-10eu-connect-modern-mouse-msx?page=9) blog?
It is a super easy project based on a very small and cheap Arduino, and it has support for wheel and four more buttons. In addition the programming is already made according to the standard created by Prodatron and Nyyrikki in MSX.org.
The basic Boxsoft+adapter can be rapidly accessible for all and then everybody will enjoy SimbOS better...
-
I forgot to say that the protocol is backwards compatible with the original MSX standard, so EGI and Paintbox will continue working.
Edit: Mouse.xr has to be modified to be able to read the adapter but SymbOS will read it directly.
-
I've found that the Neos mouse was very popular in MSX computers but with other faces:
http://www.old-computers.com/museum/hardware/Yamaha_Mouse_s1.jpg
http://www.old-computers.com/museum/hardware/Yamaha_Mouse_s2.jpg
http://i.imgur.com/Vkosc.jpg
http://i.imgur.com/qhAMz.jpg
http://www.bastilborghs.nl/images/Hardware%20pictures/VZ1931.jpg
Even the buttons of the Roland Mu-1(also a MSX mouse) or Phillips SBC 3810 reminds the Neos:
http://myweb.tiscali.co.uk/clouzeau/s760/images/mu1.jpg
http://www.bastilborghs.nl/images/Hardware%20pictures/SBC3810.jpg
Once upon a time the CPCs had a MSX mouse adapter like the C64(Mouse Cheese) and the Enterprise(Boxsoft):
http://fotos.miarroba.com/fotos/4/2/4267f422.jpg
-
It's funny. Here (http://www.cpcwiki.eu/index.php/CPC-Mousepack_2.0) is described the protocol of the CPC-Mousepack 2.0.
(other names:Gerdes Mouse, Centaure mouse, ASS Reis-Mouse or Reisware-Mouse)
It is exactly the MSX protocol but they(the people who wrote the page) don't know it. The four nibbles are read from one adapter that mimics pressing the keyboard rows. Almost like the Boxsoft adapter on the Enterprise...
-
Now I have the Arduino nano. At the end it is a Chinese clone... although the picture of the advert was of an original... but it has some quality. It comes with an USB lead to program it with a computer(Win,MAC or Linux, in my case with Win7)
The only difference appears to be the USB drivers. It doesn't work with the official ones given by the Arduino page, but I found the proper drivers(CH341SER.ZIP).
I installed the Arduino environment(Arduino IDE at the official page) on a directory named only Arduino, no mater the place. This is important so the libraries can be found.
Then extracted as instructed the PS2.zip library file inside arduino/libraries. I opened the file arduino/libraries/ps2/ps2.h and replaced "WProgram.h" with "Arduino.h"
I placed the Ino file provided by Nyyrikki on the MSX.org page on a place near the arduino directory. I modified that file only to show the Boxsoft enterprise pins on its DB9F connector.
I've finally been able to end the preparations, and clicked on Arduino.exe.
First of all I had to select on Tools menu the type of arduino board. I pick "Arduino Nano w/ATmega328".
On Serial port the app selected automatically com9:, the one the drivers choose.
On Programmer the app selected automatically "AVRISP mkII".
Then I opened the Sketch (Ino file) and then the app asked to open a folder and move the file. I agreed.
I selected the Archive/Load menu (or clicked the "white right arrow inside a blue circle" icon), some led blinking and all was done.
Ok not all done, now I have to carefully weld the Arduino pins to the PS/2 and DB9F connectors....
Very important if somebody follows this explanation: Never, never, never use the MSX pinout on a Boxsoft connector. They use different pins and you may potentially fire "some" your loved Enterprise.
-
Now I have the Arduino nano. At the end it is a Chinese clone...
Just in case you are not aware: there is an FTDI chip on board that does the ATMega serial to USB conversion, and FTDI have recently updated their driver software so that it does not work with clones, and furthermore this new driver is part of Windows update!
-
Thanks. Is for that I put the Chinese drivers....
-
This Arduino adapter worked on the Boxsoft interface at the first time!!
I welded the Arduino pins to the Boxsoft d-sub9 as this:
d2-----pin1---up
d3-----pin2---down
d4-----pin3---left
d5-----pin4---right
d6-----pin5---l-sw
d7-----pin9---r-sw
d8-----pin6---strobe
+5v---pin7---+5v
gnd---pin8---ground
And this for the PS/2
d10---pin1---data
d11---pin5---clock
+5v---pin4---+5v
gnd---pin3---ground
This is the same information contained in the MSXmouse.ino.
Again: don't mistake the Bosxoft pins with the MSX connector ones...
With this adapter the movement still is "square" and jumpy as it gives higher resolution, but at least I don't lose the pointer when I move fast the mouse.
As the script has some selection of the resolution(the wheel movement is used to do it) I think it can be easy to change a parameter or two to fit it to the Enterprise. The Neos Mouse moves very smooth so mi first goal will be to achieve the same.
-
I think finally possible create a direct connection to the Enterprise, just need more software modifications.
-
Yes, but no great modifications and only in the Arduino script. For us is more compatible to let the Boxsoft driver intact. Prodatron can read directly the mouse port the same he does on MSX computers with the same Arduino adapters. I think the resolution can be scalated easily by SymbOS if necessary.
-
Yes, but no great modifications and only in the Arduino script. For us is more compatible to let the Boxsoft driver intact.
Yes, it is looks as Boxsoft interface for the sw, but more simple hw.
Currently the direction and button bits are output. These needed to used as input, and the sw do the logical operations instead the 74LS32 ICs and diodes.
-
Aha! I misundestod you. You say you want to discard the Boxoft fase and do it directly. Good idea... But still you need to output Strobe to trigger the lecture of data. Still another connector to the serial port.
-
But still you need to output Strobe to trigger the lecture of data. Still another connector to the serial port.
Yes, but lot of other components removed.
-
And, have you choosed that "attiny" Russian project?
-
One obvious question: in reality, what the Boxsoft interface does?
I think it only inverts the electrical values of the 0s and 1s on the EP joy1 connector (releases mean 0 and pulsations mean +5v).
On the rest of the computers of its age the voltages are the reverse. This is why on the EP the autofire doesn't work at all, does it?
-
On other computers the 4 directions plus fire are input, which are connected to gnd when active.
On Enterprise these are output, and the common line the input.
The program select on the B5h port which direction needed to read, and the state of selected direction can be read on one bit of the B6h port.
In a simple wired joystick adapter the common line connected to joy GND. It is work for simple mechanical switchs. But when autofire or or other circuits use as power GND then not working.
In Boxsoft interface, the 9 pin joy connector use standard pinout, the GND are GND.
The 74LS32 are OR gates, make OR operation with the EP direction outputs and Joy outputs. For example the EP want to read Left the the Left output are 0. If the Joy Left also 0 then the result are 0. If any of them then the result are 1.
The diodes make a AND operation with the all directions, if any of them are 0 then send 0 to EP common input.
The extra thing on EP: not only one common line, it is have a 3! (Keyboard J,K,L)
Then totaly 5*3=15 directions/buttons can be readed in one Control socket, totaly 30 on the two socket. For example 6 standard (4 dir + fire) can be used...
The Boxsoft interface use the standard 5 bits, and another one for the second button.
-
It is not a simple task of inverting the voltages then...( 0s by 1s and 1s by 0s in the Arduino script). I was only thinking aloud.....
-
I`ve received a nice SD adapter and have managed to load from it both EGI and SymbOS. It`s funny to be able to move a mouse pointer over the EP screen now. It brings a sensation of it be complete at last...
I don`t know which of the GUIs I like more...
A darker mouse can match better the Enterprise...
-
It`s funny to be able to move a mouse pointer over the EP screen now.
I also enjoyed this feeling in the Saturday Enterprise party. :D
-
A darker mouse can match better the Enterprise...
Wow! Very nice!
-
It is not mine although I would like to try if it is true that the Neos is exactly like a MSX mouse....
By the way, what graphic package went with the original(patkány) Enterprise mouse? Had it some utility?
-
By the way, what graphic package went with the original(patkány) Enterprise mouse? Had it some utility?
It has a very primitive drawing program.
-
This is the Joystick counterpart:
http://www.ebay.es/itm/MSX-ML-50JY-JOYSTICK-Mitsubishi-Japanese-Controller-Excellent-NEW-BOXED-/331160150811?pt=UK_Controllers_Attachments&hash=item4d1aaee31b
It has a point... And the shape is similar.
-
Now I got a Phillips MSX mouse to test.
-
I've found another microcomputer that used a MSX mouse. Exelvision was its name. I remember that was sold in Spain.
This (http://www.ti99.com/exelvision/website/index.php?page=dispositifs-de-pointage) is a good page abut it.
-
And now I've found in this page (http://www.amibay.com/showthread.php?36258-Which-system-is-this-C-mouse-for/page2) that the Commodore 1350 mouse was exactly a Neos inside. The owner claims that it works as a joystick on a C64. Obviously it doesn't have a MSX pinout.
-
I've made a pin converter to connect the MSX mouse to the Boxsoft, and the result is discouraging. The mouse interacts at the movement but the pointer moves randomly and doesn't obey the button. (Isn't as easy to do a Boxsoft interface and use a MSX mouse instead of a Neos....) May be looking into the MSX mouse reading code (http://www.msx.org/wiki/Mouse/Trackball#Direct_usage_of_mouse) gives us the key of what is wrong.
The next thing I'll do is to play with the two jumpers inside. In the schematics (http://msx.hansotten.com/uploads/msximages/sbc3810tech.gif) they say "JP1 ON:MSX OFF:OTHERS JP2 ON:JOYSTICK OFF:NORMAL".
Seems the Mitsumi MP01 A01 processor is a clone of the MB88201 (http://www.datasheetarchive.com/dl/Scans-052/DSAIH00041985.pdf).
Searching that code I've discovered here (http://www.cdinteractive.co.uk/forums/cdinteractive/viewtopic.php?t=2802&p=13610) that the CD-I series of CD-players made by Philips and others also worked with a MSX mouse.
-
Maybe my estimations are wrong but...
According to the MSX mouse reading routine, the first long delay (that triggers the lecture sequence), is of 95667 ns (429 ticks with a Z80 at 3,58Mhz). The following delays are of 35011 ns (157 ticks), 37687 ns (169 ticks) and again 35011 ns (157 ticks).
But the Neos needs 135500 ns(542 ticks with a Z80 at 4Mhz), then 119250 ns (477 ticks), 114500 ns (458 ticks) and again 114500 ns (458 ticks).
I doubt a MSX mouse can work directly (with a Boxsoft interface) on an EP128 as only the reading routine needs 239 ticks each nibble....
On the other side, the Arduino(16 Mhz) adapter can be easily modified as it doesn't care about EP or MSX times...
------------------------------
I think, and possibly I'm wrong, that the delays of the Neos where stretched to fit the lower features of the C64 and other computers...
-
Turbo EPs can be adapted to the MSX mouses modifying the mouse.xr driver or writing a routine in SymbOS. The problem is: recollecting the direction bits from different rows surpasses the necessary delays on basic EPs.
I think, in my humble opinion, a better solution would be to create a new MSX mouse port on one of the expansion bays, and then take advantage of that cheap Arduino adapters to be able to use PS2 mouses. It could have the benefit of freeing that surplus processor time that is needed to read the Neos. Another benefit can be to free the joystick port and bring homogeneity in an aspect(mouse on EP) that is new to almost all of us.
-
I've cut the JP1 but...I have not noticed any effect, still works just as bad....
So I've welded it again.
-
Searching some MSX schematics I've found the joystick ports are attached to the AY-3-8910, a version of the "universal" sound chip with a 8 bit input/output general purpose port.
But here isn't necessary something so complicated, only 6 bits(four directions and two buttons) in a row on a Z80 IN port and only 1 bit OUT on for Strobe signal.
-
I've found the original C64 subroutine to read the Neos mouse:
3C00 AD 00 DC LDA cialporta
3C03 48 PHA
3C04 AD 01 DC LDA cialportb
3C07 48 PHA
3C08 AD 02 DC LDA cia1ddr_a
3C0B 48 PHA
3C0C AD 03 DC LDA cia1ddr_b
3C0F 48 PHA
3C10 A9 10 LDA #$10
3C12 8D 02 DC STA cia1ddr_a
3C15 AD 00 DC LDA cialporta
3C18 29 EF AND #$EF
3C1A 8D 00 DC STA cialporta
3C1D A2 08 LDX #$08
3C1F 20 37 3D JSR $3D37
3C22 AD 00 DC LDA cialporta
3C25 0A ASL A
3C26 0A ASL A
3C27 0A ASL A
3C28 0A ASL A
3C29 85 0F STA zp_0f
3C2B AD 00 DC LDA cialporta
3C2E 09 10 ORA #$10
3C30 8D 00 DC STA cialporta
3C33 A2 05 LDX #$05
3C35 20 37 3D JSR $3D37
3C38 AD 00 DC LDA cialporta
3C3B 29 0F AND #$0f
3C3D 05 0F ORA zp_0f
3C3F 85 0F STA zp_0f
3C41 AD 00 DC LDA cialporta
3C44 29 EF AND #$EF
3C46 8D 00 DC STA cialporta
3C49 A2 05 LDX #$05
3C4B 20 37 3D JSR $3D37
3C4E AD 00 DC LDA cialporta
3C51 0A ASL A
3C52 0A ASL A
3C53 0A ASL A
3C54 0A ASL A
3C55 85 0E STA zp_0d+1
3C57 AD 00 DC LDA cialporta
3C5A 09 10 ORA #$10
3C5C 8D 00 DC STA cialporta
3C5F A2 05 LDX #$05
3C61 20 37 3D JSR $3D37
3C64 AD 00 DC LDA cialporta
3C67 29 0F AND #$0f
3C69 05 0E ORA zp_0d+1
3C6B 85 0E STA zp_0d+1
3C6D AD 19 D4 LDA paddle_x
3C70 C9 FF CMP #$FF
3C72 F0 05 BEQ $3C79
3C74 A9 00 LDA #$00
3C76 4C 7B 3C JMP $3C7B
3C79 A9 01 LDA #$01
3C7B 85 63 STA zp_63
3C7D 68 PLA
3C7E 8D 03 DC STA cia1ddr_b
3C81 68 PLA
3C82 8D 02 DC STA cia1ddr_a
3C85 68 PLA
3C86 8D 01 DC STA cialportb
3C89 68 PLA
3C8A 8D 00 DC STA cialporta
3C8D 60 RTS
-------------------------------
3D37 EA NOP
3D38 EA NOP
3D39 EA NOP
3D3A CA DEX
3D3B D0 FA BNE $3D37
3D3D 60 RTS
Some parts where untouched writting it from 6502 to Z80 assembler. Especially the looping delays between reading nibbles, 8,5,5,5 where the same.
-
I'm still trying to make work the MSX Arduino converter, but have little time...
Now I know where to adjust the X and Y increments(dividing by 4 or shifting right x 2) so the pointer doesn't jump, but still have problems with correct reading, something related with the so different delays, I think.
Also the two buttons remain stuck on the pressed position. Every correctly read nibble the program inside the Arduino clears the direction bits involved (like the Neos effectively does, try to read Joy1 in Basic while Mouse.xr is working), leaving the buttons bits intact. But something in the routine leaves garbage in the register involved so the "noise" is sent to the Enterprise part. Or can be the reading is wrong (maybe because the incorrect delays truncate the operation) and then that four bits remain with the values that where tried to send.
-
I'm near of completing the adaptation of the converter program, today I have fixed the stuck buttons but.... the USB-serial adapter of the Chinesse Arduino died in my arms...
The adapter retains the last load of the code, but refuses to appear on my PC so I can't program it anymore.
I've ordered an original Arduino Nano.... about 35$ from USA.
-
I read few months ago: driver update from the original USB-serial converter chip manufacturer kill the chinese clone chips.
-
Not in this case, only it died connecting and disconnecting so many times. It lights the power led but the PC doesn't find it. Not a matter of drivers as I haven't changed them.
I think that clone Arduinos aren't made sturdy enough for my hard testing....
-
In the Arduino documentation it is recommended to use only one of the +5v sources, the USB(PC programming side) or the host(the EP). But the adapter still works connected to the Enterprise so, I have left both the EP and the USB connected and then I've heard the familiar sound of Windows finding a new device...
At the end the Chinese Arduino is not completely dead. I still can program it....
-
I do not know if due to my own ignorance:smt102 or that I am trying to run two adapters in a row, but I can't fully tune the operation of the mouse.
I have a glitch in the movement of the cursor. It perfectly responds to the movement in all directions, but if I move the mouse down it goes left-down.
I have tested the Arduino side and the mistake is at the interpretation in the EP, probably due to some form of bouncing in the signals.
So.....I will attempt the direct connection of the Arduino....
-
I was thinking of optocouplers, as them will give us total isolation of the Enterprise side, then it can see mere switches connected to its Joy1 port.
The program needs little modifications to light the leds, it can run almost the same.
I remember a Midi adapter with optocouplers I made for my Amiga 500+, and Midi operates at 31250 baud, fast enough for this project.
For the STROBE signal(RTS) it can be connected directly as it can be referenced to +5v or 0v the same with the 10k and 82k resistors like in the Boxsoft's.
Then I need 6 optocouplers(4 ways and two buttons), but I need advice to select the best type for this task.
-
This CNY74 (https://raspiugv.raudasoja.com/_media/documentation/hardware/6523.pdf) is used in the Raspberry projects to move motors. It triggers at 1.25v, no problem, I can add a resistor, but better one that triggers higher to save components.
-
Zozo please, what optocoupler can I use to do it?
-
Zozo please, what optocoupler can I use to do it?
Unfortunately I don't know, never used it :oops: :-(
-
Ok, thanks. I will search the best option.
Another option, the PS2501 (http://www.sparkfun.com/datasheets/Components/ps2501.pdf).
Or the pc817 (http://mkpochtoi.narod.ru/pc817_ds.pdf).
Or TLP521 (http://javascript:openreq('http://pdf.datasheetcatalog.com/datasheet/toshiba/2233.pdf')).
-
OK. it seems that all the optocouplers at hand have similar triggering voltage so I will opt for the Sharp PC827 or clones.
In reality, I think Tim Box could have done a better mouse interface if there had been optocouplers at that time. His interface does the same task.
-
Here you have the work in process of a mini-Boxsoft made with optocouplers.
-
As a first attempt I have used three Sharp PC825, but they had proven too sensitive to (normal) noise. From the six buttons to simulate only three were stable, the other oscillated quickly even at idle....
This chip has a "Darlington" output, a regular transistor is aided to trigger by the optical sensitive transistor.
Today I bought what I wanted at first, three clones of the older Sharp PC827, fitted only with plain optical sensitive transistors.
Now it works as planed.
(edit: the 2 signifies 2 PC817 joined in a eight pin chip)
-
This is the simplified schematic of my project.
Observe that in the case of the second fire button I am using "Keyboard K" on pin A2 of the Control 1 port instead of "Keyboard J" on pin A1.
-
Wow! It is looks very simple!
-
Yes, it is.
It doesn't need logical gates and the uncommon EP side is perfectly isolated.
The operation as a joystick port is working.
I have limited time but I'll try putting a D-sub 9 pin connector to test the Neos mouse on it this night....
-
Today I bought what I wanted at first, three clones of the older Sharp PC827
This is which type?
-
The K827P (http://pccomponents.com/datasheets/VISH-K847P.pdf).
-
And the resistors are of 220 Ohm.
Apart of the required 10K and 82K for the DTR line.
I have refused to do any commutation here... the 3.5 jack connector is to re-use the old lead from the Serial port to the Boxsoft adapter.
-
Now I see why it doesn't work..... 8.2k, not 82k.
Tomorrow more tests.
-
I fixed that resistor but the mouse still doesn't receive the STROBE(RTS) signal.
In the real Boxsoft interface the RTS signal pass trough one of the OR gates fixed to ground but I can't understand why. Is it to get exactly 5v necessary for the Neos mouse?
My next test is to check that signal with a multimeter in the real Boxsoft's while executing OUT 183,2 and OUT 183.0. May be this signal also need to be isolated.
-
The two resistors drop the voltage from 12v to 3,35v. Then the OR gate raise it to 4,45v, enough to trigger the response of the Neos mouse.
So without the gate I need to reach 5v with only the resistors.
-
Now I understand why the OR gate. The pair of resistors are a voltage divider(12v to 5v) that works fine for fixed loads, but the Neos adds resistance and some volts. This system can't work without the OR gate, that isolates the two sides.
I will put one more optocoupler to do this job. Here we need exactly 5v or 0v for the STROBE signal and we have them at hand at the controller port.
On the other side this can allow the use of other type of mouses(MSX) with, may be, different capacitances.
-
Or at the end I can put an OR gate but then it isn't so neat....
-
It is only half Or gate so I can do the same with only a transistor like this:
(http://hyperphysics.phy-astr.gsu.edu/hbase/electronic/ietron/or4.gif)
-
Ok. This is the theoretical schematic. Tomorrow I will test the real thing if I find that transistor.
Edit: It has been modified. This is the working one.
-
At last it works!
I've redraw the schematic above. Now it's even more simplistic.....
I was obsessed in getting 5v for the STROBE signal but I've found that it's more important to get the 0v. Precisely because is that state what initiates the reading process.
The Neos still sends movement with only 2,2v and 0v.... But for compatibility with unknown devices(MSX mouses, Arduino adapters, etc) I've managed to reach 4,70v.
RTS unloaded oscillates between 0v and 12v, but with the original Boxsoft(OR gate) it drops to 7,7v. With the present project(transistor) it even drops more to 5,5v... Could it be harmful eventually for the EP? I think not, it is protected inside with a 10K resistor.
I have to do one more test with this "Optoboxsoft" adapter. In the past I have experienced errors of direction with some games when playing with a joystick plugged in Control2 when still connected the original Boxsoft adapter and Neos in Control 1.
I haven't my joystick at hand... a pity. But it must work(theoretically....).
Also, now is easy to make work an auto-fire joystick on this new adapter. Except for the Fire button moved to pin5 of the D9 connector, it is a real Atari type connector with 0v as common.
No more excuses for not having mouse on the Enterprise with this easy and cheap project.... if you find a Neos mouse on Ebay.
Now I can continue with the Arduino adapter...
-
Today I've found what is wrong with all the MSX related devices, Neos and Boxsoft.....
MSX triggers the reading when STROBE is POSITIVE, and the Neos Triggers when NEGATIVE.
So the Boxsoft adapter can read perfectly one MSX mouse, only the RTS signal must be inverted.
-
Wow! Great discovery!
-
Then, only changing two lines of the Arduino script and now I have the PS/2 mouse adapter working perfect....
I think I can add a switch for MSX or NEOS mode in my OptoBoxsoft....
-
OptoBoxsoft....
I like the name! :-)
-
Yes! It caused a shift in the nibbles and so the jumps, 1 or -1 was received as a 15 or -15...
-
I must go, tonight I will post the modified script and will begin detailed instructions.
-
I'm back again.
First of all we must think about a way to invert the STROBE signal. I have a nice Phillips MSX mouse, so I can do test with it.(Lab rat, never better said.....)
I've found this on the same web page:
Tomorrow I can buy the components and try. Then I'll put a selector.
-
I can use one more resistor and a triple commutator like this:
(http://www.stewmac.com/freeinfo/i-1611/1611_dia5.gif)
Then I can weld its pins as this:
-
Holly Week and no electronics store open on Saturday....
Then I un-welded the pins of the transistor and put the 220 Ohm resistor to the +5v side.
I have a pin converter already made for my MSX mouse so it has not been necessary to change the pins on the OptoBoxsoft's D9 connector.
Of course it works!
Now we have three ways of effectively connecting a mouse to the Enterprise.... if we don't count the fated "Patkány".
This is the working MSX OptoBoxsoft interface schematic:(Observe that the pins are according to the MSX pinout)
-
According to the MSX mouse reading routine, the first long delay (that triggers the lecture sequence), is of 95667 ns (429 ticks with a Z80 at 3,58Mhz). The following delays are of 35011 ns (157 ticks), 37687 ns (169 ticks) and again 35011 ns (157 ticks).
But the Neos needs 135500 ns(542 ticks with a Z80 at 4Mhz), then 119250 ns (477 ticks), 114500 ns (458 ticks) and again 114500 ns (458 ticks).
I doubt a MSX mouse can work directly (with a Boxsoft interface) on an EP128 as only the reading routine needs 239 ticks each nibble....
Now I have no doubts about that Neos and MSX mouses protocols are the same, but then the Enterprise doesn't need all that time to read the mouse.
May be we can make the Mouse.xr driver less processor-time hungry if we shorten the delays to the minimum possible.
-
One question more: Why the different triggering(positive or negative) of the two mouses?
Can be because the resting state of the pin6 of the C64 Joystick port is +5v, an then the active state is 0v. Much like the resting state of the RTS signal is +12v.
----------------------------------------------------
Now I want to explain the modifications I've made to NYYRIKKI's script to work with the Enterprise+Boxsoft.
Here (http://api.viglink.com/api/click?format=go&jsonp=vglnk_142816824953611&key=1db07c1ca961fda47c3134a69129438d&libId=i83adcdz01000i8e000DAjs9wtru9&loc=http%3A%2F%2Fwww.msx.org%2Fforum%2Fmsx-talk%2Fhardware%2Fuse-10eu-connect-modern-mouse-msx%3Fpage%3D14&v=1&out=http%3A%2F%2Fmsx.fi%2Ftemp%2Fmouse_draft.zip&ref=http%3A%2F%2Fwww.msx.org%2Fforum%2Fmsx-talk%2Fhardware%2Fuse-10eu-connect-modern-mouse-msx&title=Use%20~10%E2%82%AC%20to%20connect%20modern%20mouse%20to%20MSX%20%7C%20MSX%20Resource%20Center%20(Page%2014%2F14)&txt=http%3A%2F%2Fmsx.fi%2Ftemp%2Fmouse_draft.zip) you can download the script and instructions.
His project lets the user to simulate various legacy devices on the MSX computer with a standard PS/2 mouse: mouse, extended mouse, extended mouse + joystick, Joystick, trackbal, and touchpad. Obviously only mouse simulation is important for us. Also the script has an option to transfer a program from PC-side to the MSX, but it can´t work on the Enterprise without re-writing the resident program.
First change:
void sendMSX(char c)
// Optimized for Atmel328
// NOTE: Fixed pins!
{
while (digitalRead(JoyPin8)==LOW) {if (millis()>time) return;};
DDRD = ((DDRD & 195)|((~ (c>>2)) & 60));
while (digitalRead(JoyPin8)==HIGH) {if (millis()>time) return;};
DDRD = ((DDRD & 195)|((~ (c<<2)) & 60));
}
To:
void sendMSX(char c)
// Optimized for Atmel328
// NOTE: Fixed pins!
{
while (digitalRead(JoyPin8)==HIGH) {if (millis()>time) return;};
DDRD = ((DDRD & 195)|((~ (c>>2)) & 60));
while (digitalRead(JoyPin8)==LOW) {if (millis()>time) return;};
DDRD = ((DDRD & 195)|((~ (c<<2)) & 60));
}
Second change:
*/
void JoyHigh()
// Optimized for Atmel328
// NOTE: Fixed pins!
{
DDRD=(DDRD & 195);
}
To:
*/
void JoyHigh()
// Optimized for Atmel328
// NOTE: Fixed pins!
{
DDRD=(DDRD & 255);
}
The first change is to match the negative triggering of the Neos, and the second is to leave the pins of the port in its rest state. If you leave it with 195 decimal, the buttons are always pressed.... But if you leave at 0 then the pointer always goes up.
-
I was wrong with the calculation of the delays. Both the Neos and the MSX mouses do a first delay of aprox 135000ns. Then the following three delays must be of at least 70000ns aprox because it works on the MSX mouse.
But the Enterprise driver exceds that three delays on 45000ns each, time that is lost.
This time can be reduced some. I will test tomorrow how.
-
The driver puts 8, 5, 5 ,5 delay cycles, but is enough wth 8, 1, 1, 1 for a 4mhz Z80.
Edit: I have checked it , if I SPOKE the values 8, 1, 1, 1 the driver works exactly the same. But Prodatron have already the old values....
-
Even more. How to convert a Neos mouse to a MSX mouse and back?
We know yet that the pins at the D9 connector need to be rearranged so this isn't the quiz.
The two are equipped inside with the MB88201 processor but the Neos has the pin 5 of the chip directly connected to its STROBE pin at the D9 connector.
On the other side the MSX mouse has inside an inverter made....with a transistor and a resistor and then connected to its STROBE pin at the D9 connector.
Exactly a 2sc2405 marked "S.R", a smd NPN transistor, and a 4.7 resistor like in the image below.
So, on a MSX mouse we can disable the inverter when necessary. On the Neos we may add the transistor and resistor to make the inverter.
--------------------------------
The MSX mouses also have the Joystick mode if we press the left button while plugging.
-
This is the finished pulse selector I'm going to put in my OptoBoxsoft interface.
I've decided to insert the transistor between the pins.
Then it only has four leads, 5 and 0 volts, RTS(in), and STROBE(out).
Edit: The weldings where wrong. I'ill put new images when fixed....
-
Sorry my weldings are ugly.... please follow the drawing (http://enterpriseforever.com/hardware/re-paintbox-mouse-xr/msg45910/#msg45910) if you want a selector.
This is the final aspect of my Boxsoft clone. An used box of course. N and M stand for Neos and Msx. I can't plug two mouses at the same time, they not short-cut but their signals interfere.
-
This is the final aspect of my Boxsoft clone.
Wow, it looks cool! So many mice.
Anyway, you shouldn't play Caesar the Cat or Garfield with so many mice, I think. :D
-
Sin problemas, estos ratones han crecido bastante duros...
-------------------
No problem, these mice are grown quite tough...
-
Sometimes a mouse refuses to move the pointer on one of the axis, it may be caused by a misalignment due to impacts caused by falls to the ground....
I've found an English language web page (http://cyborgyn.blogspot.com.es/2014/12/repairing-commodore-1351-mouse.html#uds-search-results) where a Magyar guy realises it after a hard search and two resistors replaced on the mouse's inner board.
At the end he fixed it only leaving loose a screw of the mouse's housing....
-
Nice find! I will look at the partialy dead mouse that you sent me!
-
I said you, it can be only misalignment of the diodes and receptors... I followed the same steps, tested the diodes with my phone's camera, but for my Neos mouse tests I needed a working one.
My experiments are like banging my head against the wall, my head always is harder...
-
Here are two evidences that the Commodore 1350 mouse and maybe some of the first 1351 are Neos mouses in other housings.
One of them is in this web page: Translated to English (https://translate.google.es/translate?sl=es&tl=en&js=y&prev=_t&hl=es&ie=UTF-8&u=http%3A%2F%2Fwww.retrocomputacion.com%2Fe107_plugins%2Fforum%2Fforum_viewtopic.php%3F80555&edit-text=&act=url) and in Spanish (http://www.retrocomputacion.com/e107_plugins/forum/forum_viewtopic.php?80555).
The translated page doesn't lets download the very big pictures(limitations of Google translator).
Observe the size of the plastic of that connector. Inside the mouse is a Neos chip MB88201, but in the underside of the board it has cuts on some tracks and added four leads that take the direct readings to the D9 connector.
Can it be a retrofitting at factory? It is a 1350 or a 1351? The first is always in joystick mode and the second has the option if you press the left button while connecting, like the MSX mouse and the Neos, but is not tested in the web page.
The other is inside a web page (http://www.amibay.com/showthread.php?36258-Which-system-is-this-C-mouse-for/page2) that I brought here on a previous post.
Observe the same odd shape connector, and here you can see the sticker with no model nor "Made in", but serial number begining with YQ. Inside the same Neos chip, but alas, no underside view. Fortunately the owner has tested it only works in joystick mode, so it is definitely a 1350.
The main-boards are exactly the same as the Neos mouse, so can be that removing the leads and re-welding the cooper tracks they end being Neos mouses....
To probe it I've bought on Ebay one mouse exactly like those, but must wait to test this.
-
Another Neos mouse (http://www.tcocd.de/Pictures/Peripheral/NCE/nce860pc.shtml) but this time for Pc with serial connection.
The housing is the same but the board inside is different. It also has the typical MB88201 chip but may be with different firmware to work with serial.
-
I received this today, an unusual FM Towns Marty (http://en.wikipedia.org/wiki/FM_Towns_Marty) mouse.
It has the MB88201 chip inside. It works as a MSX mouse as it also inverts the STROBE signal with a transistor(TR1) and resistor(R3) .
I like the black ball.
-
Sorry this picture doesn't show the component's part due to glare, but they are those at the right side.
-
Look at this trackball. The design is similar to the Enterprise's but in clear plastic.
It was a serial one but I've adapted the electronics of a two buttons PS/2 mouse. It still has space to put the Arduino Nano converter inside.
-
Dear Mr. Gflores,
why is your green buttons so shiny? Are they custom-made keys?
-
Long time ago the letters were fading so I applied a varnish to protect them . It also served to fix the Castilian signs (Spanish) I have glued on some keys....
-
It was long before that I found this web page. My father bought me the EP for printing the bills of his business. I had a Riteman+ printer(Epson) and that keys on the WP where equivalent to the Castilian symbols once printed. So I created my own character set. I loaded it every session, from tape of course. At that time I though I was the only one neglected Enterprise owner in Spain.... A situation similar to you the Magyar users...
Then the Amiga computer (with floppy) appeared, and my EP was forgotten some....
But this little computer had brought to me more satisfactions than Amigas or PC,s, so here I am again.
-
I dont't know the Espanol Situation that time, Espania was not on the side of the Soviets, I guess there was no COCOM list so you could buy any computer you want. (Of course if you have the money for that.)
The time of the Enterprise (1985) there was the chance to buy a Amiga 1000 computer, with sophisticated Motorola 68000 CPU, which already 16 bit capable, and the graphics performance was really impressive. According to my friends, this computer was really popular in west-germany. Unfortunately in the East (like Hungary) we couldn't buy such computers, because the CPU was on the COCOM list, that means, we coudn't import that.
Note: This list was good for the western Companys, because of the list, the unsuccessful and overproduced computers and parts could be sold later in East Europe.
-
In Spain, although the dictatorship had passed ten years by the 1985, high tariffs on imports remained, so the situation was similar.
-
At last I got the Commodore 1350 mouse... It has an unmodified Neos-Mitshumi board inside(no cuts on tracks nor welded leads), but until evening I can't test it on the Boxsoft.
I must first test the pins if the signals are in the same position. This mouse works only in joystick mode, so it must have a modification to have the left button pressed at connecting time, I guess.
Which where first, Neos mice or C64 mice?
The shape of the case is of a regular Commodore tank stile. Here you have some pictures to compare it with the real Neos:
-
In a preliminary view I've seen that STROBE is unconnected...
-
In a preliminary view I've seen that STROBE is unconnected...
Probably it only works in joystick mode?
-
Yes, probably it has a resistor or something to emulate the left button pressed and then always initialises in joystick mode.
-
It's even simpler, a lead from pin 4 of the MB88201 to ground initiates it in joystick mode. It can be seen on the picture. In the Neos is one of the three white leads to the contact of the left button. On the 1350 is that loop marked with arrows in the plate. At the side a little cut of wire, the STROBE signal. And at the underside it lacks a little resistor marked 103.
The 1350 has screened its lead, that fat wire with a ferrite ring.
-
And probably the 1351 are fully Neos compatible?
-
I'm not sure, only those with that big connector I think.
I've cut the loop and connected the STROBE signal to the left button pin and now it works. May be that selecting the joystick mode is not possible until welding the white leads.
-
Searchig the web you can see that some 1351 are not like this inside.
-
Look at this 1351 mouse, the fat connector, the same case, different sticker and different board inside:
http://www.nightfallcrew.com/gallery/commodore-1351-mouse-for-c64128/
The chip is not a MB88201( I can't see it here but I've seen it on another page).
I bought my 1350 on Ebay named as if it were a 1351 so better is to search for this sticker:
http://i693.photobucket.com/albums/vv298/luki1979/IMG_0787.jpg
-
In this (http://www.tcocd.de/Pictures/Peripheral/Commodore/1350.shtml) page another 1350 manufactured by mitsumi but without the NEOS chip.
-
Even Apple Macs have a Neos mouse!
http://www.ebay.es/itm/RARE-Vintage-Apple-Macintosh-128k-512k-Mac-Plus-NEOS-Mouse-UNIQUE-/281687620083?pt=LH_DefaultDomain_0&hash=item4195e3f9f3
-
Part of the thread about the EnterMice interface has been moved (http://enterpriseforever.com/hardware/entermice-joy-ps2-mouse-interface/).