News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_Bryce

Build your own AMX Compatible Mouse Adapter

Started by Bryce, 00:25, 24 December 09

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Bryce

Hi All,
       Everyone's getting all festive and coming up with Xmas games, Christmas Demos etc. And as a hardware person I felt left out :D So seeing as there has been a lot of discussions about AMX Mice and Atari ST adapters, I decided to use my time off constructively and have built a PS/2 / USB adapter that's AMX compatible. You can check out the plans at http://www.cpcwiki.eu/index.php/PS2Mouse and let me know what you think. The page is still a bit rough and the software needs cleaning up too, but it all works and might give you something to do before you get back to work in Jan. When I get around to it, I'll fix up both.

Happy Christmas,
Bryce.

Octoate

Wow, that is an awesome christmas present :-). Thanks a lot Bryce, at least I will build it for sure!

Happy Christmas,
Octo
--

Bryce

Your welcome,
            had an after thought about the Hardware last night... If you add a push-button between 0V and MCLR (Pin 4 of the PIC) this will allow you to reset the PIC, so that you could "Hot-Swap" the mouse without restarting the CPC. Might be useful? I haven't allowed for it on the PCB, but if the PCB is housed, you could just solder the leads directly to the back of the board. Maybe I'll do a version 2 board after all....

Bryce.

Gryzor

You're a god... could we pay you to make one for us or something? :)

Bryce

That's probably going a bit too far, but if so... Yeeeh today must be MY birthday :D Lol, but on a more serious note, I had mentioned before, that I was going to develop a few "Exclusive to CPCWiki" projects, and this is more or less the first complete one. I intend doing more, so suggestions are welcome. Like I said, I will try to concentrate on small, cheap circuits that even beginners should be able to build, rather than major Symbiface expansions.

I don't usually do "production runs", and my aim isn't to make money anything I build, I'm very much an Open Source person and just do the design stuff, but I may have a few working prototypes on offer later. I'll let you know...

Bryce.

fano

Thx Brice, this is a great present for Xmas  ;D
"NOP" is the perfect program : short , fast and (known) bug free

Follow Easter Egg products on Facebook !

Bryce

Morning All,
          due to the fact that I'm not a very "Christmas person" and the weather is too lousy to play golf, I have managed to find the time to finish the Firmware and add all the stuff I planned. The hardware hasn't changed, so the schematic and layout are still valid (other than the fact that I changed the label in one of the switches). The new firmware has added the following features:

1. Start-up - You no longer need to have the mouse connected at start-up, it will initialise any time the mouse is connected  (this may be useful to people who intend installing the mouse circuit inside the CPC?)

2. Plug & Play - It is now possible to dis-connect and re-connect the mouse without a re-start, including swapping to a different mouse completely (even between PS/2 and USB mice)

3. Auto-Detect - The firmware now auto-detects whether your mouse has a scroll wheel and enables the scroll wheel if present. If you have some fancy mouse that confuses it, the switch nearest the power socket will disable Auto-detect and force the mouse into non-scroll wheel mode (whether it has one or not).

3. Minor reaction time improvement - There was a 20µs second delay at certain times (Yeah I know, it only detectable on an oscilloscope, but I'm fussy about these things!)

These changes also remove the need for the Reset switch I mentioned above.
I have updated the Wiki page to reflect these changes and I might add more about how to program the PIC and possibly a layout for USB only (ie: USB socket instead of PS/2 socket) if it is requested.

Happy New Year, frohes neues Jahr, bonne année, etc...

Bryce

Bryce

Oops, just spotted a mistake on the Schematic. In case you have already downloaded the one on the Wiki, the Schematic shows the part 74LS244, it should be a 74LS240 ! The parts list was correct though.

Bryce.

nocash

Nice project - only one thing is missing: it'd be nice if you'd explain how it works! I mean, what is a AMX mouse, and how does it transfer the data to the CPC?

I've had a look at the original AMX Art software. At first glance, it seems to be joystick compatible... so my first question would be:

Is that all about it? It works like a simple joystick? Or did I miss something important? Like a mouse-detection which switches between special-mouse-protocol-mode and normal-joystick-mode?

If it's really simply using the joystick-style protocol. What I've found out is that it seems to check the joystick port once every 300Hz, and seems to treat joystick up/down/left/right signals as mickeys in the corresponding direction(s). So I guess, on vertical movement, the mouse interface generates a LOW pulse of 1/300s duration (per mickey) on UP or DOWN joystick input.

Oh, and how does the scroll wheel work exactly? The document says it connects to "5" (joy2up) and "6" (joy2down). First of, isn't that vice-versa? 6=up, 5=down?

And, concerning scrolling, the terms "up" and "down" are rather confusing... If you move UP-wards in a document, then text scrolls DOWN-wards on the screen. So "Move DOWN" could have opposite meaning as "Scroll DOWN". I guess "turn wheel away from user" and "towards user" would be much more precise.

Finally, a lisz of the buttons would be nice, like
Joy1Fire2 (X) = which button
Joy1Fire1 (Z) = which button
Joy1Fire3 (-) = which button (middle?)

Whereas, looking at the documentation (pdf file) for the original AMX mouse, left and right buttons seem to have been arranged/used confusingly. There's a strange drawing that looks as if the Right Button is used as Execute Button... ie. much like PC mouse in left-handed mode? Although, the drawing is top-down, so the right button is actually on the left side in the drawing... though I guess that wasn't the way how one should use the mouse, with the buttons & cable pointing towards the user? :-)

Bryce

Hi Nocash,
       I'm not sure exactly how much detail of "How it works" you'd like, but I'll answer your questions and if I missed anything let me know:

Firstly, I think that having read the original documentation you now know what the AMX is, in short, it was a mouse which connected to the joystick port and moving the mouse sent the corresponding joystick up/down/left/right pulses to the CPC, while the three buttons sent the three possible fire signals (As you correctly stated, it more or less pulled the particular pin to 0V), but obviously in sequence with the polled common pin, otherwise any of the keyboard characters could appear instead of the joystick arrows, as the joystick common is being polled as part of the keyboard matrix, merely connecting the "up" pin to ground will give you the series of other keys which are in the same column of the matrix if it is grounded while the other column is being polled. The 74LS240 has an output enable pin, which is connected to the common, this means, the pulses are only passed on to the CPC at the correct moment.

A PS/2 mouse needs to be initialised and configured by a host before it will do anything useful and after this has been done, it sends back a 3 or 4 Byte serial signal on the data line (4 if in scroll-wheel mode). The first byte primarily contains 3 bits for the three button states and 2 bits for the sign (+/-) of the relative movements of the x and y axis, the second byte is a two's compliment value of the x movement and the third is the same for y movements. The fourth byte, which is only sent if the mouse has been switched to scroll-wheel mode contains the Z movement (ie: the scroll-wheel), the PIC in my circuit  auto-detects the type of mouse and does all the required initialisation and then continuously polls the mouse and converts the two's compliment values into the associated up/down/left/right signals. It also has error handling, so that if the mouse is disconnected, it will wait for a new mouse and then re-initialise and re-start the polling.

Did you miss something important? No, probably not. The AMX software will work perfectly well with a 3 button joystick, but some people just like the idea of using the software with a mouse as it was originally intended. As well as that, modern CPC GUIs such as FutureOS and Symbos fully support AMX hardware and are much more comfortable to use with a mouse than a joystick.

The scroll wheel is a difficult one. Obviously it wasn't available on the original, so there is no standard to adhere to, but I thought, why waste a good scroll-wheel when it's there. As you also correctly stated (my confusing description of the scroll-wheel up/down signal) 6 is indeed up and 5 is down. The reason I swapped these, is because that's exactly what a PC scroll-wheel does, it swaps the concept of up and down, I could have just as easily used the signals the other way around, but I had to decide on one of them. To better explain the function: Rolling the scroll-wheel away from you (finger heading towards screen) will result in a 5, rolling your finger back towards yourself will result in a 6. If there's a compelling reason to reverse this, then let me know and I'd be happy to supply a new version of the firmware with the logic reversed. I will edit the project page and improve the description also.

The buttons are mapped the same as the AMX mouse (yes the original AMX documentation went out of its way to confuse the user): Assuming a right-handed mouse... The left button (index finger) will return an X, the right button will return a Z and the centre button is fire 3 (this one doesn't result in any character).

Does that explain it better? If I left anything out let me know...

Bryce.

nocash

Hi, I've just added a new section, called "Mapping to Joystick Signals", on the PS2Mouse page. I hope it helps to understand how to access it by software, and that I didn't get any mistakes in there.

So the AMX hardware can handle max 300 mickeys per second? Don't know for sure, but I guess a mouse can send more than 300 mickeys when it's moved quickly... so you need to clip it to max 300...?

Looking at the AMX Art software, it seems to translate 1 mickey to 2 pixels (or maybe other values when using the SLOW and FAST mode), but without supporting double-speed threshold. I guess that feels "sticky". Anyways, that's a software problem, not a hardware problem.

Yes, up/down can be confusing concerning scrolling. And, no, don't change the firmware. Just make the description less confusing - towards user / towards screen should be better than up / down.

And, no! You CANNOT rename Joy2Up to Joy2Down. It's totally okay if you assign Joy2Up=ScrollThisOrThatWay, but how can you assign Joy2Up=Joy2Down? That's crazy! :-)

Btw. USB mice are really pin-compatible with PS/2 mice? Does USB have a CLK signal at all? I thought USB-to-PS/2 adapters would contain a microprocessor, too, for protocol conversion.

Bryce

Hi nocash,
           a PS/2 mouse connected to a PC sends a value between 0 and 255 for each direction and the PC reacts according to the value received, but it can do this much faster than the CPC requires, so to make things easy, I just ignore the value more or less, and just check the direction and that the value is above zero. So any movement will trigger a single joystick signal. I can also set the sensitivity of the mouse internally so that a small movement triggers the mouse immediately, I have reduced this to make the mouse less sensitive. The mouse is a little "sticky" and also accelerates logarithmically (ie: it gets faster with distance) I think this is a side effect of the key repeat function of the CPC. This has the effect that the mouse reacts differently to a PC mouse. If I move a PC mouse really quickly, the value will be 255 and the mouse shoots across the screen (255 notches). This is impossible with the CPCs joystick port speed, the CPC moves one notch (2 pixels in the AMX art package) every time the mouse direct signal is low, so the movement speed can not be relative to the mouse movement speed.

On USB mice and converters:

PS/2 mice have a small microprocessor to handle the settings and handshaking required. USB mice (at least the basic ones) have a software compatibility for PS/2, this means that if they receive a USB command (Request ID) at initialisation they will act as a USB mouse, but if the host sends a PS/2 command (reacts to the AA message from mouse), the mouse assumes PS/2 functionality. My circuit attempts to force a USB mouse to PS/2 functionality and if the mouse doesn't answer properly it will report an error by flashing the LED. As far as the hardware is concerned, they have exactly the same pins: 5V, GND, CLK and Data, just a different connector and protocol. Probably the biggest difference is that with PS/2 the mouse controls the clock signal, whereas with USB, the host controls the clock, the clock speed is also much higher with USB and more than one device is possible, because each device has a unique device ID integrated into the protocol packages. The little green PS/2 to USB converters are nothing more than two connectors soldered together. Cut one open and see for yourself.

Bryce.

redbox

This is incredibly cool and I will give it go after the success of building my parallel cable (!).

nocash

> PS/2 mouse connected to a PC sends a value
> between 0 and 255 for each direction
Yup. I know the RS232 mouse protocol, which is probably similar.
RS232 mice can send max 128 mickeys per 3-byte packet, and about 40 packets per second. So the total maximum would be 5120 mickeys per second.

> to make things easy, I just ignore the value
> more or less, and just check the direction
> and that the value is above zero.
Uhm, you are ignoring it? You mean, for each packet, you are simply turning the joystick signal on or off? And if yes, how many packets are you getting per second? If it's not more than 40 packets (as for RS232 mice), then you'd have only 40 mickeys per second, right?

> The mouse is a little "sticky" and also accelerates
> logarithmically (ie: it gets faster with distance)
> I think this is a side effect of the key repeat
> function of the CPC.
Err. Yes. That would happen when accidently moving the mouse at the BASIC prompt. I hope you aren't using the Keyboard Buffer for reading the Mouse Data! That'd get you only 10 mickeys per second or so ;-)

> If I move a PC mouse really quickly, the value will be 255
> and the mouse shoots across the screen (255 notches).
Sorts of. The modern MSDOS/Windows mouse drivers are a bit more clever, and they'd typically step twice as far: 510 notches, since they use the double speed threshold thing (eg. if mickeys<10 then pixel_step=mickeys*1, else pixel_step=mickeys*2).

> This is impossible with the CPCs joystick port speed
But it is possible. At hardware side, everything up to 300 mickeys/second should be perfectly working as on PCs. The only problem is that the AMX can't handle bigger values like the RS232-maximim of 5120 mickeys/second.

Btw. you are aware of the 300Hz thing, aren't you?
(Just asking because I haven't seen it mentioned anywhere on the PS2Mouse page)
Ie. the AMX software uses the CPC's 300Hz interrupt to read the joystick port (of course via IN opcodes, not via BIOS). So, I guess, it would be extremly important that your PIC firmware follows that method, and updates the joystick signals exactly 300 times per second.

Hmmm, unless you are intentionally updating it much more often, like 3000 times...? So the AMX software would "randomly" read only every 10th value...? I guess, even if it the software misses 9 of 10 values, maybe that could somehow give statistically correct results...?

Gryzor

I guess I learned more than I ever wanted to know about cpc mice. Here's a toast for more similar discussion, with special thanks to Bryce and Nocash!

By the way: I haven't used my AMX mouse for a looong time, but I wanted to ask - does it support accelerated movement? Meaning, does the cursor moves according to the speed you move the mouse? I'd think it's an obvious 'yes', and the polling speed is there for that (although a bit slow), but somehow I seem to remember it being otherwise...

nocash

> By the way: I haven't used my AMX mouse for a looong time,
> but I wanted to ask - does it support accelerated movement?
Well, you are the only one here who DOES have AMX mouse. I've never had one, and Bryce said that he never had one, too. So, since we can't examine the hardware, we can only examine the software, eg. the AMX Art program.

If you could measure the AMX signals (on the joystick port side) with an oscilloscope would be great. A photo of the mouse interface would be nice, too. To get an idea what kind of chips it contains.

As far as I can tell, it seems to read 300 1-bit values per second, so, depending on how fast the mouse is used, it can produce 0..300 mickeys (mickeys = mouse steps) per second.

Most likely the mouse arrow is updated once per 50Hz/PAL frame, so there you'd have 0..6 mickeys per frame, depending on how fast the mouse is moved. So, yes, it should support different speeds. Though the resolution isn't too good (a RS232 mouse could handle ca. 0..100 mickeys per 50Hz frame).

If you say that it doesn't feel accelerated... maybe it can be blamed on the missing threshold support the AMX Art program (I'd be sure that it feels bad)... or maybe the AMX hardware interface is crap (though since the AMX software reads data 300 times/second, I would hope/expect that the AMX hardware does output data at the same speed).

The low-level signals for opto-mechanic mice consist of XA/XB for horizontal motion (YA/YB for vertical). That low-level signals are found used Atari/Amiga mice. And very-very probably the AMX mouse should internally have that signals, too. Ie. the signals passed from the AMX mouse to the AMX interface should look like so:


      <----------- One Direction------><-------Other Direction----------->
  XA _____----_______----___________________----__________----_______
  XB _______----_______----_______________----__________----_________


Looking at the AMX Art software, I'd expect that the AMX interface converts the XA/XB signals, and passes them to the LEFT/RIGHT joystick signals like so:


      <----------- One Direction------><-------Other Direction----------->
  RT ---------------------------------------______--------______-----
  LT -----______-----______------------------------------------------

          <---->     <---->                 <---->        <---->
          1/300s     1/300s                 1/300s        1/300s


A PS/2 or RS232 mouse internally has the XA/XB stuff too. But, instead of sending 1/300s pulses, it transfers a signed 8bit number, eg. -02h (or +02h) for two steps in left (or right) direction.

So I guess Bryce does (or should do) convert a value of -02h to a joystick left signal, like so:


  LT -----______-----______------------------------------------------

          <---->     <---->
          1/300s     1/300s


Or, to make things a bit more simple, one could probably group the two 1/300s pulses to single 2/300s pulse, like so:


  LT -----____________-----------------------------------------------

          <--------------->
                2/300s


In the PIC, that could be simply implemented as:

  If new mouse packet received then
    stop timer (if it wasn't already expired/stopped)
    If xoffset=positive then set JoyRight=LOW
    If xoffset=negative then set JoyLeft=LOW
    start a timer that expires after ABS(xoffset)/300 seconds
  If timer expires then
    set JoyLeft=HIGH
    set JoyRight=HIGH


Bryce

Ok, here's some more info on my Firmware. Firstly, a PS/2 mouse in standard mode, reports the movement at 100 Samples per second (up to 200 are possible) and the standard is also 1mm = 4 counts of the movement value, however, my firmware is not interrupt driven, so I have put the mouse into remote mode, this means that the mouse only sends it's info when I ask for it. This simplifies the firmware greatly, so that my flow diagram is more or less:  Ask the mouse what movement occured - Set the appropriate bits - go back and check the mouse again (The PIC is running at 4MHz and has a command cycle of 1:4, so I can easily outrun the 1/300s if the mouse could send me that much data). This can all happen much quicker than the required 300 times a second, so that if the mouse has no relative movement at the last request, the PIC still leaves the outputs ON long enough for the CPC to see them and then turns them off after 1/300 of a second. Ok, not exactly 100% true, because I am sending signals ON Joy2 for the scroll wheel, I leave the signals ON for almost 2/300 of a second, so that the one delay loop captures the scan of both Joy1 and Joy2 (they happen one after another), this simplifies the firmware once again.
To put it another way, while the mouse is moving the associated inputs are held low and go high approx. 2/300 of a second after movement has ceased. This means that any speed bottle neck will occur in the CPC depending how the software was written. I experimented with buffering the inputs, ie: leaving the outputs on longer than the 2/300 of a second if the mouse was moved faster, but this results in the mouse permanently overshooting the desired position and makes using the mouse very difficult and unpredictable.

The Joystick port (hardware) always scans at the same speed ie: 300Hz, but reading it through BIOS Routines means that not every sample could possibly be read. AMX software definitely doesn't read all 300 per second nor does it seem to buffer the movement. So that my PIC is sending data much quicker than the CPC actually needs. On top of this, because I am buffering the signals with the 74LS240, the circuit will always send data to the CPC no matter how often or how quick the CPC scans.

A simple test to see how fast the AMX software is actually scanning: Use a joystick to go all the way from left to right on the screen and see how long it takes to get there. The software is in mode 0 and takes steps of two, ie: it should have 80 steps across the screen. If it really sampled at 1/300 of a second, the arrow would travel across the screen in 80/300 of a second. It doesn't. And for good reason too, because this would make the software completely unuseable. I haven't measured it exactly, but it seems to be reading through the BIOS or at least using a similar speed. For this reason, getting my PIC to send 300 samples a second would not increase the speed of the mouse in the AMX software.

By the way, thanks (nocash) for adding the "Reading the Joystick" section to the page, I have moved it down to the "Using the mouse" section where it is more relevant than where it was.

Any further Questions? Let me know :)

Bryce.

nocash

> A simple test to see how fast the AMX software is
> actually scanning: Use a joystick to go all the way
> from left to right on the screen and see how long
> it takes to get there.
Good idea.

> The software is in mode 0 and takes steps of two,
> ie: it should have 80 steps across the screen.
> If it really sampled at 1/300 of a second, the arrow
> would travel across the screen in 80/300 of a second.
> It doesn't.
Whoops.
Then I've been wrong there :-/
No, moment!
Why 80? And what mode 0?

The AMX Art program that I am using here is Mode 1 (4-color, 320x200 pix). And regardless of the screen resolution, the 300Hz IRQ handler (at address 886Bh in my AMX Art version) clips the mouse coordinate to range X=0..639 and Y=0..199. Ie. internally, the resolution is 640x200.

So if the mouse is processed at 300Hz, then traveling from left to right screen edge would take 320/300 seconds. Which "almost-exactly" what it does. In practice it looks more like 500/300 seconds or so. The reason is that the program is crappy:

If the mouse (or joystick) is not moved, then the IRQ handler is executed 300 times per second, 6 interrupts per 50Hz PAL frame (100% sure). If it is moved, then the AMX Art thing executes only 4 or 5 interrupts or so per frame...

I'd guess that's because, the mouse-arrow-drawing function is very inefficient, and to the worst, the programmers seem to have disabled IRQs during the drawing period (stupid idea), so it misses some 300Hz interrupts.

Anyways, that's a "bug" in the AMX Art software. I guess/hope one doesn't need to recurse that problem at hardware-side. Of course the hardware should be working with the AMX Art software, but for other/better software it'd be nice if the hardware supports the full 320Hz resolution.

> it seems to be reading through the BIOS
No, it isn't using the BIOS keyboard/joystick scanning (that'd be done only at 50Hz rate). It's using the BIOS Fast Ticker, which calls the mouse driver at 300Hz rate (unless AMX Art when chooses to disable IRQs).

> thanks (nocash) for adding the "Reading the Joystick" section
> to the page, I have moved it down to the "Using the mouse"
Okay. Btw. my description "LOW for 1/300s" seems to be wrong for your hardware. Maybe you should change that... either the description... or maybe better... the hardware :-)

> I experimented with buffering the inputs, ie: leaving the outputs
> on longer than the 2/300 of a second if the mouse was moved
> faster, but this results in the mouse permanently overshooting
> the desired position
I think that would be a good idea. If you receive "n" from the mouse, the it to "n/300s". Of course, to prevent the overshooting effect, you'd first need to clip it to "if n>10 then n=10" or so.

Or, as suggested in my sample code (see previous message), you could stop the timer when receiving a new packet, that'd have the same clipping effect.

Well, at least it'd would have that clipping effect if the mouse DOES send a new packet (RS232 mice do send packets only if the mouse is moved, so with a RS232 mouse, the clipping wouldn't occur after the last packet).

Cu, Martin

arnoldemu

Quote from: nocash on 12:39, 04 January 10
> By the way: I haven't used my AMX mouse for a looong time,
> but I wanted to ask - does it support accelerated movement?
Well, you are the only one here who DOES have AMX mouse.
I have one.

I think the software in the AMX Mouse code, scans the joystick 6 times every frame, so does a scan every interrupt. It then uses this to determine the movement speed. all of this is from memory when I had a look at it once. I do remember thinking: this is poor.

I planned to sample the joystick inputs using code but I didn't finish this. So maybe it is time to do this to work out if it sends pulses or not on the joystick. We could then get an idea of how it is transmitting the information?

I believe the dk'tronics mouse interface (also called "Genius Mouse"??) actually has I/O ports you can read to get the x/y counters. read the values, take the difference and you then know the direction and speed it is moving. But I don't have this interface so I can't confirm.

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Bryce

Probably your best bet is to build my circuit and try it for yourself, then you can subjectively say whether it feels right or not. I may re-visit the firmware if people aren't happy with it. As I mentioned before it seems to be doing everything as expected, but improvements can only be good for it.

My AMX Art package shows 16 colours when I choose, I thought that's only possible in mode 0 ?

I may not have mentioned this before, but I have no idea about programming a CPC, nor the BIOS calls available or there speed. I am purely a hardware person and spent most of my time designing for other platforms (everything from Apple II to Atari XE/XL), so I never really got indepth into any particular programming. the nearest I ever got to programming a CPC, was typing in a few listings from Amstrad Action back in the 80s. The PIC firmware is however written entirely in PIC-assembly, this I can handle  :)

I will attach a scope or logic analyser to it when I have time and let you know exactly how often the data is being requested and sent. Any futher changes to the data sampling and sending rate can all be done in the firmware, so the hardware won't need to change no matter what. I'll adjust the project page to the real values measured.

I tried the n/300s and n=10 (I actually used 8 as it's easier in binary), but it gave me very unsatisfactory results for some reason, maybe I will try something similar again, but it also means splitting the button timing from the x,y,z timing :-\ (again)

Are there other programs that did things more effictiently that I could test it with?

Bryce

Didn't the DKTroniks mouse connect to the expansion port? Obviously a much better solution than the AMX one, but my mouse project had the goals of A) Being AMX compatible (because so much software supposedly supports it) and more importantly B) Being extremely cheap and easy to build.

As I said, the hardware is complete, but the firmware can be tweaked quite a bit, I will see what can be done to improve the responsiveness as much as possible.

Has anyone actually built it yet, so that I can get a second opinion on the real life experience?

Bryce.

nocash

> I planned to sample the joystick inputs using code
That would be great!

> My AMX Art package shows 16 colours when I choose,
> I thought that's only possible in mode 0 ?
Yup. It is. I seem to have a different version.

> Are there other programs that did things more
> effictiently that I could test it with?
No idea. I just meant that a serious program wouldn't miss interrupts.

> Being AMX compatible (because so much software
> supposedly supports it)
So much? The cpcwiki page lists only four programs (amx art, stop press, max desktop, amx 3d zicon). Are there more?

I came across the mouse when I were trying to figure out which mouse interfaces exist, and which are most popular.

> I may not have mentioned this before, but I have no
> idea about programming a CPC, nor the BIOS calls
> available or there speed.
Like all BIOS calls their speed is slow :-) don't use them, never!

And the CPC hardware: In short it's a Z80 CPU, some I/O ports, VRAM, and interrupts are generated at a fixed rate of 300Hz (in case you were wondering why I am talking of 300 all the time).

If you like hardware & asm, then programming the CPC should be easy. Well, the VRAM is arranged in a messy way, and accessing the keyboard/joystick isn't that easy because amstrad routed the signals through the PIO and PSG chips in a rather absurd way. So may it isn't that easy :-)

Bryce

Hi all,
      a small (major) correction to something I've mentioned several times above. I've just been checking some screenshots and have realised the the Art Package I have been using up to now to test the mouse is in fact OCP Art Studio and not the AMX Art package. I don't know how, but I somehow saved OCP on a disc with the label AMX Art and have assumed all along that this is what I was using. As I have never used either art package before, I had no idea that it wasn't what I assumed it was. This will also explain why "My version" had a different colour pallet / mode.
      So to correct myself: Yes it works perfectly well on OCP Art Studio, I will test it's reaction and "feel" tonight on AMX Art (and any other mouse software I can find)

Bryce.

Bryce

Ok, so I've found the REAL AMX Art package and the mouse responds exactly the same, ie: accurately, no overshot and fast enough to consider it more or less PC standard "feel". When I have the time I'll get SymbOS and FutureOS up and running and confirm that they are the same, but in need to throw together a ROMBoard for that, so it probably won't be till the weekend.

Bryce.

arnoldemu

Quote from: nocash on 12:39, 04 January 10
> By the way: I haven't used my AMX mouse for a looong time,
> but I wanted to ask - does it support accelerated movement?
Well, you are the only one here who DOES have AMX mouse.
Enjoy the pictures. (look on amx mouse wiki page).

New pictures showing mouse, interface, inside interface, inside mouse.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Powered by SMFPacks Menu Editor Mod