News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_Cwiiis

A simpler mouse adapter for the Amstrad Plus?

Started by Cwiiis, 14:34, 11 November 22

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

GUNHED

Remember AMX Stop Press! They showed how good a joystick compatible mouse really can do.
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

Bryce

Yes, but from a hardware perspective they didn't do anything different. It's the software on the CPC that decides how good the mouse feels.

Bryce.

GUNHED

Sure. That's what I always tell. Everything depends on the software.
Therefore I talked about a joystick compatible mouse (any!) and mentioned the particular software.
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

Prodatron

Like an acceleration parameter which works for joystick compatible mouses quite good as well.
It's probably one of the reasons why joystick compatible mouses could feel and be used like proportional mouses, if you are not experienced in the real difference and learn to handle them in this way.

You cannot view this attachment.

GRAPHICAL Z80 MULTITASKING OPERATING SYSTEM

Cwiiis

I've been debugging and trying to verify and understand more - as far as I can tell, everything is wired how I intended to wire it and behaving as I would expect. The chip select on the LS240 is being pulsed correctly and all the output pins go where I expect and are what I'd expect to see (pulled high, waiting to be grounded). Really, the only thing that isn't doing its job appears to be the PIC. It's receiving power and the clock looks good on CLKOUT (I assume it's meant to look like a sine wave and not a square wave?), but it doesn't appear to be communicating with the mouse at all.

So my thought is either I've not flashed the PIC correctly or that perhaps I've not understood the circuit and wired something incorrectly. Regarding the latter, it's not like there's a whole lot I could get wrong, so I'm still suspecting that it isn't flashed correctly or there's something wrong with the clock and I don't understand what it should look like.

Something I wonder about; I've tied RA4 on the PIC to ground - as I understand the circuit, this should permanently enable auto-detect. Though even if that was wrong, I'd have thought the side-effect would be no mouse wheel (which won't work until I connect X7 from the keyboard connector anyway, iiuc), not the entire thing not working?

I suppose I could try to make the flashing circuit and follow the exact steps from the wiki page rather than using MPLAB, but it feels like I'm clutching at straws somewhat now... Does anyone have any suggestions?

Bryce

Can't you read back the PIC content and confirm that's it's programmed? The HEX file doesn't lock the code, it should be readable.

Bryce.

Cwiiis

Quote from: Bryce on 13:07, 02 December 22Can't you read back the PIC content and confirm that's it's programmed? The HEX file doesn't lock the code, it should be readable.

Bryce.
Yes, and I can confirm that it is what I'd expect - the program code is from 0x0-0x1af and the rest is filled with 3FFF. MPLAB verification says it's correct and there aren't any errors during programming. I also verified the flags reflect what's said in the wiki too, and it does.

Cwiiis

On the off-chance, I tried the 1.0 firmware given I based my circuit on the diagram of the PS/2 circuit, but no change in behaviour. I guess I should learn enough about PIC programming to just write a small debug program to check that the circuit is ok by flashing LED patterns... But I'll exhaust a few more easier, brute-force methods first.

coin

#33

My mistake, sorry

RetroCPC

Quote from: Cwiiis on 13:29, 02 December 22On the off-chance, I tried the 1.0 firmware given I based my circuit on the diagram of the PS/2 circuit, but no change in behaviour. I guess I should learn enough about PIC programming to just write a small debug program to check that the circuit is ok by flashing LED patterns... But I'll exhaust a few more easier, brute-force methods first.
I've not read the complete thread - but when using a new MCU / IDE there's always a few issues that will catch you out...Have you configured the "hardware side" of the MCU correctly? normally you have to configure the oscillator type (such as external oscillator / Crystal or ceramic resonator etc), clock path / clock dividers / PLL, ADC, DAC, watchdog timers etc...

Not sure what's required for your MCU, but might be good to write a simple software routine to flash an LED etc. just to see that the MCU hardware configuration is OK (clock frequency etc).

Bryce

Quote from: RetroCPC on 00:05, 30 March 23
Quote from: Cwiiis on 13:29, 02 December 22On the off-chance, I tried the 1.0 firmware given I based my circuit on the diagram of the PS/2 circuit, but no change in behaviour. I guess I should learn enough about PIC programming to just write a small debug program to check that the circuit is ok by flashing LED patterns... But I'll exhaust a few more easier, brute-force methods first.
I've not read the complete thread - but when using a new MCU / IDE there's always a few issues that will catch you out...Have you configured the "hardware side" of the MCU correctly? normally you have to configure the oscillator type (such as external oscillator / Crystal or ceramic resonator etc), clock path / clock dividers / PLL, ADC, DAC, watchdog timers etc...

Not sure what's required for your MCU, but might be good to write a simple software routine to flash an LED etc. just to see that the MCU hardware configuration is OK (clock frequency etc).

He's using the compiled HEX file I created. That has all the correct setup parameters in it as long as he hasn't changed anything on the hardware side it should work fine.

Bryce.

RetroCPC

Chris,

Happy Birthday:-

You have an error on the MCLR line (Reset_n), I dont believe the 100uF cap should be connected to MCLR, rather VDD/VCC, see Bryce's orginal schematic..

I'm not sure if there should have been a 100nF Cap to Ground on MCLR - maybe the PIC has internal Reset...

Anyway, the solution as I see it is to connect the Postive of 100uF cap to VCC /VDD...

If it works - a Birthday gift :)

Cwiiis

Quote from: RetroCPC on 13:01, 03 April 23Chris,

Happy Birthday:-

You have an error on the MCLR line (Reset_n), I dont believe the 100uF cap should be connected to MCLR, rather VDD/VCC, see Bryce's orginal schematic..

I'm not sure if there should have been a 100nF Cap to Ground on MCLR - maybe the PIC has internal Reset...

Anyway, the solution as I see it is to connect the Postive of 100uF cap to VCC /VDD...

If it works - a Birthday gift :)


Thanks :)

I tried correcting this and unfortunately no luck.

I then recreated the circuit partially on a breadboard, but no luck there either - I don't know what the PIC code does to know exactly how much I can reduce the circuit, but I made the assumption that you don't need to connect RB0-6 or RA2/3 for mouse detection to work at least, but I see no signs of life on the LED connected to RB7 in this configuration.

I should probably do some probing to double-check that my breadboard setup is correct, but at this point I'm thinking I need to put together a simple PIC program that just flashes an LED so I can see that I at least have power/clock/reset setup correctly.

Bryce

#38
/MCLR should be tied high to VCC via a 4k7 resistor, otherwise the circuit is in a permanent random reset loop. The 100uf and 100nf should both be across VCC and GND.

Bryce.

PulkoMandy

No one replied about the lightpen input, so, here it goes.

The way lightpen works is they detect the electron beam in the display, and just send a signal "I am above the electron beam just now". This signal is sent to the CRTC, when it receives it, it remembers which part of the display it was displaying at that exact time.

So, if you wanted to make a mouse from this, you would have to also connect it to the video output, and have it count lines and pixels there in realtime, so it can send the pulse at just the right time.

It's possible, but probably more complicated than the other options.

As for the analogue joystick port, I think that could be made to work. Especially as that port does have a +5V supply for it, and is not used for anything else really :)

Powered by SMFPacks Menu Editor Mod