Posted By
MMS
on 2021-10-11
15:33:29
 |  Re: Arkanoid +4!
OFF: (topic: a mouse controlled Arkanoid +4)
Paddle is really the best for it, but certainly mouse is great too.
The RS232 mouse project was mentioned on the German forum. It is BSZGG's project, I just tried to document it, including the missing schematics (kind of). The original prototype is still there at BSZGG, and I think it is a great project from him.
Colaholiker mentioned, that the Rx and Tx signals should be swapped for the mouse.
Actually I do not have any problem with a fact, that I could make a mistake (and the documentation need correction), but I do not see the problem with the logic on the schematics.
Actually as seen on the Max232 circuit diagram, the Tx in an TTL level output signal from the MAX232 board, even the arrow shows it. So, it should be sent to the User port's pin, that is expecting to receive some TTL level data, so it should be an INPUT line.
RxD of the User Port (Pin C) means Receive Data.
I think this is the way the RS232 incoming coordinate could be translated. Max 232 converts it to TTL level, sends it out via Tx from the board, and C+4 receives it via the RxD data input line.
Maybe a HW guru could tell me, where is the bad logic with this setup. If I am wrong, then certainly I will swap the Rx and Tx usage on the MAX232 board in the documentation, it is easy just swap the Dupont cables. I found it illogical to connect two output line to each other, then they will send data to each other without listening by anyone. But maybe I was wrong.
In fact there is no need to use the Plus/4 output port (TxD=Transmit data) in this setup but for the sake of completeness I connected the User Port TxD to the input line of the Max232 board (Rx), as shown on the schematics, it is an input line of the board.
I think as a scene activity could be an optimized driver, but at least (for compatibility) to agree on the RAM address is should put the coordinates and the mouse button position (a zero page unused location).
I could upload BSZGG's resident driver and his BASIC code. It should work, but do not respect any othe rpogram, and it load the coordintaes to an address at the middle of the memory. I tryied to make an optimized version that may fit into the zero page, but I failed.
About coordinates:
It should be easy to decode and use them. I think a lot about that, and I think 8 bit (0-255) for the X coordinates could be enough, I mean 1 byte is enough for 0-159 position, X coordinate (in multicolor all the pixel positions). Certainly 200 vertical position will fir into 1 byte too.
It sounds a little unconvenient on Hires screen that it may jump with this approach two pixels at the same time, but I think higher precision is not really required, especially if you use it for a GUI surface handling, or playing a game. Only hires drawing progarm and GEOS Paint could use higher resolution X coordinate.
The 9th bit could make all possible horizontal positions to be covered, but could make the program reading and using these coordinates more complex.
I mean reading out 1 byte for X, and 1 byte for Y position is easy. Software sprites typically used in multicolor modes.
|
