Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

Stuart

Members
 View Profile  See their activity

  • Content Count

    1,019

  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Stuart

  1. Posted · Edited by Stuart

    23 minutes ago, xabin said:

    After watching Ashens for a long time, it still messes with me how weirdly the I is spoken in various words by the British; for instance, "titanium" is pronounced like "tit - tanium", with a short "I", but "urinal" is pronounced "Yoo-rai-nal", with a long "I". Very odd...

    Not consistently true - I'd say "tie-tanium". So it's consistent with urinal, should I ever happen to use both words in the same sentence. And Titanic. There's a titanic tie-tanium yoo-rai-nal in the cupboard under the stairs.

    • Like 2

  5. Posted

    I've got 10 off HY6264ALP-10 8Kx8 RAMs looking for a new home. Any use to anyone looking to expand a RAMDisk or something?

     

    Completely untested! No guarantees! No returns!

     

    Yours for the cost of postage from me in the UK to wherever you are.

     

    • Like 3

  7. Posted

    12 hours ago, Lee Stewart said:

    I seem to recall that the QI version has a prayed-on metal coating on the inside of the clamshell.

    Our Father who art in Heaven,

    Please let my QI TI work,

    Without undue RF interference,

    ...

     

    ;-)

     

     

    • Haha 2

  8. Posted

    On 3/17/2020 at 3:04 PM, BeeryMiller said:

    Matt, not aiming this specifically at you, just general with the mouse programming on the TIPI.

     

    While I am in a holding pattern on another project, I've been playing with code to interface the mouse to the MDOS side of things.  Back in the early 90's, Bruce Hellstrom wrote software drivers that used either the Myarc Mouse on the Geneve 9640 or a serial mouse that plugged into the RS232 card.  These drivers installed themselves into the operating system of MDOS and could be activated by a command in the user's task page 0.  The mouse would work in all text and all graphic modes. Once activated, they ran from the interrupts and updated a set of command registers with location, speed, button pressed, and a couple of other bytes of info.

     

    With the 9938 and the Vid XOP calls, MDOS returned to the driver the precise x/y location.  With the serial mouse, there was a bit more work to work out the initialization and the data fed back.  I've seen 3, 4, and 5 byte sequences that could be reported in the serial code.

     

    I've got the calls to the TIPI for the mouse written into the XOP, and I can see the changes in direction left/right, up/down.  Trying to work that bit into the driver code now.  The serial code wasn't clearly commented in the interface, and I was hoping to get some feedback from anyone that may have messed around with software controlling the mouse on the 4A.

     

    Any thoughts on if it is better to incorporate a change in the x or y direction by a pixel at a time, or the full change the mouse has measured?  I ran a rough test outside the driver code and I could see a change of "1" to over "10".  Just trying to get a feel for movement.  It's easier to INC/DEC a value, than dealing with negative numbers than the additional hurdle if adding/subtracting pushes the mouse location outside the boundaries of the screen across all the various modes.

     

    I'm still trying to understand how the TIPI returns three bytes for x, y, and buttons.  I can move the single byte into a register, and do a SRL and it knows if it was a negative or positive direction movement as I could see >FFF0 or >0010 depending upon the direction of movement when I display the register's content.

     

    FWIW, I've got a two button wireless mouse with a scroll wheel between the two buttons.  It correctly reports the bits for the button, but also has additional reporting beyond those three buttons.  Matt, any significance?

     

    Beery

     

     

    For my Internet Browser, I took the simple approach of just checking in what direction the mouse is moving, and ignoring how fast the mouse was moving. The screen resolution for the TI is so low that trying to implement any form of mouse 'acceleration' didn't really seem worth the effort. I move the cursor two pixels at a time which is fine for the browser but no use of course for any drawing-type programmes. I've copied below the mouse code in case it is of any use. 

    *No key pressed and no joystick movement. Check if any movement from TIPI mouse.

CHKMSE  BL   @RDTPMSE       Read data from TIPI mouse. Data returned in buffer MSEBUFF.

        CLR  R4             Flag to indicate if there was mouse movement.

        CLR  R1
        MOVB @MSEBUFF,R1    Get horizontal movement. This is:
*                           >00 = no horizontal movement
*                           >FF (slow) - >81 (fast) = movement left
*                           >01 (slow) - >7F (fast) = movement right
        JEQ  CHKMSE2        No horizontal movement. Check vertical.
        SETO R4             Set flag to indicate mouse movement. (Instruction doesn't affect any status bits)
        JGT  CHKMSE4        Jump if movement to the right.
        DECT R2             Movement is to the left. Decrement X position.
        JMP  CHKMSE2
CHKMSE4 INCT R2             Increment X position.

CHKMSE2 MOVB @MSEBUFF+1,R1  Get vertical movement. This is:
*                           >00 = no vertical movement
*                           >FF (slow) - >81 (fast) = movement up
*                           >01 (slow) - >7F (fast) = movement down
        JEQ  CHKMSE3        No vertical movement. Check button.
        SETO R4             Set flag to indicate mouse movement. (Instruction doesn't affect any status bits)
        JGT  CHKMSE5        Jump if movement down.
        DECT R3             Movement is up. Decrement Y position.
        JMP  CHKMSE3
CHKMSE5 INCT R3             Increment Y position.

CHKMSE3 MOVB @MSEBUFF+2,R1  Get button press. This is:
*                           >x8 = no button press
*                           >x9 = left button press
*                           >xA = right button press (not used by the browser)

        ANDI R1,>0F00       Isolate required nibble.
        CI   R1,>0900       Left button press?
        JEQ  JOYFIRE        Yes. Jump to routine that handles keyboard <ENTER> key (via joystick routine as jump out of range).

        MOV  R4,R4          Flag set to indicate mouse movement?
        JEQ  MSST001        No, jump to continue.
        B    @MSSP10        Yes, process new sprite position.
        
****************************************************************
*Subroutine - read data from TIPI mouse.
*Call: BL @RDTPMSE
****************************************************************

RDTPMSE MOV  R11,@SAVR11    Save return address.
  
        LI   R1,1           Number of bytes in message to send.
        MOV  R1,@GPLWSR0    Save in GPL workspace R0.
        LI   R1,B20         Address of message to send.
        MOV  R1,@GPLWSR1    Save in GPL workspace R1.
        MOV  @MSEBUFA,@TIPIBUF  Set TIPI buffer address.

        BL   @TIPICOM       Send TIPI command message and get result, which is three bytes -
*                           horizontal movement, vertical movement, and button press.

        MOV  @SAVR11,R11    Restore return address.

        B    *R11           Return.

     

    • Like 1

  10. Posted

    3 hours ago, RickyDean said:

    There was discussion of the pals here some time back, but I have a short lunch and can't find it at the moment.

     

    This thread: https://atariage.com/forums/topic/288694-wanted-replacement-pal-chip-corcomp-fdc-1985-rev-a-u12/page/2/#comments

     

    I worked out a first iteration of the PAL equations based on the info from Helocast, but it needs someone who can program and re-read the PAL data to check and refine them.

  11. Posted

    Nothing new ... but have been having an e-mail chat with a chap helping to restore a Royal Observer Corp Group HQ Bunker in Scotland (that's the northern bit of the UK!). This is one of a number of HQ Bunkers that would receive information from smaller 3-man underground bunkers about the spread of nuclear fallout in the UK in the event of someone dropping one or more nuclear bombs on us. Operational up to the early 90's. They've got a number of bits of kit that use the TMS9900 and 9995 that they're restoring, and they were after one of my TMS9900 PCBs to use as a simple way to test their processors and clock chips.

     

    https://www.facebook.com/28Group/ if you're interested. It's a Facebook page but if you haven't got an Facebook account just click the "Not Now" link towards the bottom right of the login banner displayed and you can scroll through to your heart's content and try to spot our favourite processors.

    • Like 2

  12. Posted

    12 minutes ago, Vorticon said:

    Do you know who designed it? Obviously someone familiar with the TMS9900 assembly language and the TI.

    It is being sold by Jaime, who designed the NanoPEB.

     

     

    • Like 1

  14. Posted

    2 hours ago, Ksarul said:

    The biggest difference is that the 9903 is a synchronous chip. . .

    Indeed, which means that you'd have to sit at your terminal typing away at a steady speed, never slowing down or deviating, never stopping ...   ;-)

     

    I suspect what dhe vaguely remembers is that you could pop a 9903 in a 9902 socket (it is one pin shorter so has to go at one end of the socket), but the synchronous protocol and serial connections are different to the RS-232 interface provided by the 9902. You *can* design the board to support both but it needs a 25-pin serial connector and you need a terminal that supports the same synchronous connection.

     

  17. Posted

    3 hours ago, fabrice montupet said:

    Unless someone urgently need them. For my hardware projects, I am interested in them all

    Thank you!

    Hi Fabrice,

     

    They're all yours. PM me your mailing address and I'll get them in the post to you during the week. If I then let you know the postage cost, can you PayPal me the money?

     

    Stuart

  18. Posted

    I've been given the following:

     

    -- Approx 5 HM628128ALP-7 128KB static RAMs

    -- Approx 10 HM62256BLP-7 32KB static RAMs

    -- Approx 10 HY6264LP-10 8KB static RAMs

     

    Any use to anyone? They're free except for the cost of postage and packing from me in the UK. To post to the US will cost about UK£10.

     

    They're quite possibly from China. I haven't tested any of them. No guarantees or refunds!

     

    Stuart

     

    • Like 2

  20. Posted

    2 hours ago, FarmerPotato said:

    I was wondering, if I put a pull-up resistor on CRUIN, how do I measure when a pin goes hi-Z if I don't know if it was outputting a 0 or a 1.

     

    If you pull one of the 9901 programmable inputs either high or low then use the TB instruction to read the state of that input, then you'll know whether CRUIN will be high or low? So if you pull CRUIN high through a resistor and use it to measure a low input, it should be fairly obvious when it goes hi-Z?

  24. Posted

    If your power supply is OK (the voltage on each output pin should be marked on the PCB right next to the connector) then you might be better off by first replacing the two static RAM chips - those are the two larger chips marked "MCM6810P". You can get those off eBay. The VRAM RAM chips (the block of eight marked MCM4116... and TMS4116...) can and frequently do go bad, but they usually result in a corrupted display rather stopping the machine booting altogether. Get some decent quality cutters so you can cut the IC pins individually with the IC still on the board then you can remove the IC body, then you can unsolder and remove each pin individually. This will reduce the risk of damaging the PCB. Fit a turned-pin socket to the PCB to plug the new IC into.

    • Like 4
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...