Author Topic: EnterMice (egér és joy illesztő) (Read 43075 times)

gflorez · « **Reply #135 on:** 2019.March.29. 17:35:29 »

I have tested your mouse2.com and mouse3.com programs. The two fail on 10MHz.

You have to reassure that the interrupt is made every 1/50 second, because these routines work on other programs on my 10MHz Enterprise without adjusting delays. A lot of tests where made when developing the EnterMice to achieve it.

I will read your code to try find the cause.

pear · « **Reply #136 on:** 2019.March.29. 18:59:31 »

Maybe for clarity.
After 25 μs from the change of the RTS signal state, the first nibble of the data is available.
However, the full read cycle of the data byte half on the EnterMice side is 39 μs. The remaining 14 μs is necessary to terminate the interrupt service.
In addition, the entire EnterMice firmware was optimized with the assumption of readings every 20 ms.
Reading the PS/2 data from the mouse can take up to 12.5 ms, so it will fail faster.
The start of reading the PS/2 data follows 1.5 ms after the end of the last data nibble reading.
For the whole to function correctly, for the read of all data from EnterMice it is at least full 6 ms. That's enough time. Especially at 10 MHz.

Code: ASM

                                        ; tacts limit 56 @12MHz (112 @24MHz)
                                        ; data exhibit before 26 (52) tacts
msxservice:                             ; +4  interrupt system delay + jump
        HDW_INT_START   1               ; +6  using set #1 of GPR
        mov     a,r7                    ; +1  load nibble counter   
        clr     c                       ; +1
        rrc     a                       ; +1  count msxData ptr
        orl     a,#msxData              ; +1
        mov     r0,a                    ; +1  store msxData ptr
        mov     a,@r0                   ; +1  load msxData
        jnc     msx_set                 ; +2  if ptr is odd
        swap    a                       ; +1  then swap nibble
msx_set:
        anl     a,#0F0h                 ; +1  leave high nibble
        mov     r0,a                    ; +1
        mov     a,outBuff               ; +1  combine data to out
        anl     a,#00Fh                 ; +1  reset msxD0..msxD3
        orl     a,r0                    ; +1  
        mov     outPort,a               ; +1  exhibit data  @25 tacts
        mov     outBuff,a               ; +1  store data
        inc     r7                      ; +1  increment nibble counter
        TMR_START       msxComTout      ; +6  set timeout (see em.equ)
        HDW_INT_END                     ; +6 = 39 tacts
 

pear · « **Reply #137 on:** 2019.March.29. 19:22:36 »

I had to remind myself where the limit of 56 μs came from.
I have measured the original BoxSoft interface timings with CPU clocked at 4 MHz.
The full data reading lasted 140 μs.
At 10 MHz it gave a limit of 56 μs, which I aimed at.
Finally I managed to get down to 39 μs, so with a lot of spare time.

IstvanV · « **Reply #138 on:** 2019.March.30. 11:11:14 »

In this routine, reading 4 bits with READ_LOOP_3 takes well over 200 cycles, so the 14 us (or 39 us total) requirement should not be a problem in theory. According to a quick test with amoba.com, mouse input is polled at fairly regular 20 ms intervals.

I still suspect it is M_WAIT_LOOP that needs to be increased, because the idle state of 80 00 from mouse2.com suggests the error is in the first bit of the first nibble. Perhaps it needs to be longer than 25 us only the first time. In mouse3.com at 10 MHz, it seems to take 16-24 us from toggling RTS to reading port B6h, depending on whether DAVE wait states are enabled and if it is the first or second nibble.

Povi · « **Reply #139 on:** 2019.April.02. 14:13:10 »

I found a bug, if not enough RAM is available, so it is fixed.

I did not fixed the mouse bug at 10MHz, I don't know, what the B register should be at M_WAIT_LOOP.

I attached the source, you can compile it with sjasm, the AMOEBA.COM (attached in previous zip) is needed for the compilation.

gflorez, can you do some tests with higher B values at 10MHz?

gflorez · « **Reply #140 on:** 2019.April.02. 15:33:47 »

I will try later.

Judge · « **Reply #141 on:** 2019.April.05. 11:11:41 »

Quote from: Povi on 2019.March.28. 19:47:36

Viszont feléd kérdés: ha nincs bedugva az EnterMice hw a gépbe, úgy mit csinál az egeres verzió nálad?

Ha nincs a gépben az EnterMice, akkor is ugyanúgy csíkos az egeres változat.
Az eredeti viszont minden állapotban kifogástalan.

Judge · « **Reply #142 on:** 2019.April.05. 11:26:48 »

EnterMice burkolat címke. Ha valakinek szüksége lenne rá.

EnterMice cover label. If someone needs it.

[ Guests cannot view attachments ]

[ Guests cannot view attachments ]

Judge · « **Reply #143 on:** 2023.November.13. 22:57:19 »

A klubban megígértem...elkezdtem az EnterMice burkolat illesztését a géphez.
Ha kész lesz, nem lesznek problémák a csatlakozással. Pontosan a helyére találnak az élcsatlakozó érintkezői.
Átalakítom azt rést is rajta, ahova elvileg a printer csatlakozó menne, ha az EnterMice a gépben van, csakhogy az eredeti kialakításnál nem fér át rajta a printer dugó.

Itt egy prototípus:

[ Guests cannot view attachments ]

Author Topic: EnterMice (egér és joy illesztő) (Read 43075 times)

gflorez

Re: EnterMice (egér és joy illesztő)

pear

Re: EnterMice (egér és joy illesztő)

pear

Re: EnterMice (egér és joy illesztő)

IstvanV

Re: EnterMice (egér és joy illesztő)

Povi

Re: EnterMice (egér és joy illesztő)

gflorez

Re: EnterMice (egér és joy illesztő)

Judge

Re: EnterMice (egér és joy illesztő)

Judge

Re: EnterMice (egér és joy illesztő)

Judge

Re: EnterMice (egér és joy illesztő)