Image Map Image Map
Page 3 of 9 FirstFirst 1234567 ... LastLast
Results 21 to 30 of 81

Thread: TRS-80 diagnostic/ICE card

  1. #21

    Default

    David,
    But, even without the LC Mod it should still display the characters that are in the Character Generator. The Level II
    Manual gives these as the Characters:.



    Larry


    Model-1_Char_Gen.jpg8046670.jpg

  2. #22
    Join Date
    Sep 2016
    Location
    Melbourne, Australia
    Posts
    597

    Default

    Quote Originally Posted by ldkraemer View Post
    David,
    But, even without the LC Mod it should still display the characters that are in the Character Generator. The Level II
    Manual gives these as the Characters:.



    Larry


    Model-1_Char_Gen.jpg8046670.jpg
    I assumed it would which is why it had lower case to start with, not having a functioning model 1 or a an image of what characters are wrong I can only guess.

  3. #23
    Join Date
    May 2006
    Location
    Hamilton, Ontario, Canada
    Posts
    3,751

    Default

    OK, I've had a chance to get back to the diagnostic ROMs.

    This is a G board with no lower case. The first picture shows that the characters are not correct, in some locations. This happens in both David's version and Larry's version (since they are based on the same code).

    On a D board, with lower case, everything displays as it should.

    The second picture shows Larry's ROM with the characters all converted to upper case. When plugged in, it shows all @9 which tells me there is something wrong with the code. I burned it twice and got the same thing both times.

    The third picture shows Larry's keyboard scan diagnostic and it seems to work right. Unfortunately, none of the Model 1s I have that are working enough to show something intelligent on the screen don't have keyboard issues. I do have some Model 1 motherboards that have no keyboard attached and I'm guessing the ROM will see that as an issue.
    Attached Images Attached Images
    Legacy Computers and Parts

    Sales of, parts for, and repairs to, Vintage and Legacy computers.

  4. #24

    Default

    OK, in the first picture (G Board with NO Lowercase), the first line should be:

    Komtek Test ROM Version 1.4a

    Instead you are getting the following HEX values:
    K= Correct
    o= 4F or 6F / =2F <-- This is telling me there is some problem with the Data Lines such that a 4F is converted to 2F for the Video Display.
    m= 4D or 6D - =2D
    t= 54 or 74 4 =34
    e= 45 or 65 % =25
    k= 4B or 6B + =2B
    = Correct
    T= Correct
    e= 45 or 65 % =25
    s= 53 or 73 3 =33
    t= 54 or 75 4 =34
    = Correct
    R= Correct
    O= Correct
    M= Correct
    = Correct
    V= Correct
    e= 45 or 65 % =25
    r= 52 or 72 2 =32
    s= 53 or 73 3 =33
    i= 49 or 69 ) =29
    o= 4F or 6F / =2F
    n= 4E or 6E . =2E
    = Correct
    1= Correct
    .= Correct
    4= Correct
    a= 41 or 61 ! =21

    I am curious why the Case Conversion ROM gives @9's on the screen versus the same information as the Lowercase version. Especially since
    it works correct in my Emulator. I've got to dig out my Model 1 and repair it so I can also test it.

    The Keyboard test ROM just echo's on the screen what key is shorted ROW to COLUMN. It doesn't test the existence of a keyboard as that is
    just a Hardware matrix of switches at 0x3800.

    Thanks.

    Larry

  5. #25

    Default Display Problem

    If you look at the attached PNG, and follow Pin 12 of Z62 down to Z28 that is the Bit that is 2 of 1,2,4,8.
    Then follow Pin 12 of Z45A for Lower Case Modified Motherboards, or Pin 13 of Z30 down to Pin 13 of Z27,
    that is Bit 4 of 1,2,4,8 for the MSD. It appears that there is some type of Wiring Wiring error for Pin 10
    of Z28 to be selected when Pin 15 of Z27 should be selected (Input is Pin 13 (D3) of Z27).

    No way that one bad IC Z27 or Z28 can set the Bit in the other IC unless Pin 12 of Z62 (Bit 5) is some how
    shorted to Pin 13 of Z30.

    It will be interesting to see what you find.

    Thanks.

    Larry

    Model-1_Lowercase_Mod.jpg

  6. #26
    Join Date
    Sep 2016
    Location
    Melbourne, Australia
    Posts
    597

    Default

    The display is how it should be according to the schematic for a Model1 with no LC Mod.

    Take a lower case "o" as an example. Its value is 6Fh, the bit of importance is D5, it feeds into a Z30 a 74LS02 (NOR Gate). The input in this case is high, the output of that gate which is now low is latched and fed into the character generators A6 input. So the character being fed into the character generator is now 2F.

    An upper case "O" (4Fh) D5 is low which is inverted via the NOR gate and fed into A6 (high) effectively inputting 4Fh to the character generator.

    All I can say is its an ugly way to reduce the chip count by one static RAM.

    So what it means is for machines with no LC mod the bit swapping they do means lower case wont display correctly. Adding a code to test for the absence of an LC mod and using a different set of upper case only messages will overly complicate the code.
    The best solution is to only use upper case messages.
    Last edited by David_M; June 10th, 2018 at 06:14 AM.

  7. #27
    Join Date
    Jun 2010
    Location
    Vancouver, BC, Canada
    Posts
    287

    Default

    Quote Originally Posted by David_M View Post
    All I can say is its an ugly way to reduce the chip count by one static RAM.

    So what it means is for machines with no LC mod the bit swapping they do means lower case wont display correctly. Adding a code to test for the absence of an LC mod and using a different set of upper case only messages will overly complicate the code.
    The best solution is to only use upper case messages.
    FWIW there's a fairly simple way to handle printing messages and having them uppercased on Model I's without the lower-case mod. I seem to recall finding the technique when disassembling Big Five games. With HL pointing to screen memory and A containing the character to print, do this:
    Code:
        LD   (HL),A
        CP   (HL)
        JR   Z,chok
        RES  5,(HL)
    chok:

  8. #28
    Join Date
    Sep 2016
    Location
    Melbourne, Australia
    Posts
    597

    Default

    Unfortunately its not that simple for the ROM. To make the ROM code able to function in a system with faulty or no RAM, we can't use the stack. Normally it would be a simple matter of testing for the existence of an LC mode storing the result and adding your code example to a single display subroutine. But since we cant use a memory variable or a subroutine all temporary variables have to be held in registers and each time we display a message it is hard coded not in a subroutine. Hard coding an LC test and the conversion 10 or 15 times versus not using lower case... the choice is simple.

    Quote Originally Posted by gp2000 View Post
    FWIW there's a fairly simple way to handle printing messages and having them uppercased on Model I's without the lower-case mod. I seem to recall finding the technique when disassembling Big Five games. With HL pointing to screen memory and A containing the character to print, do this:
    Code:
        LD   (HL),A
        CP   (HL)
        JR   Z,chok
        RES  5,(HL)
    chok:

  9. #29
    Join Date
    Sep 2016
    Location
    Melbourne, Australia
    Posts
    597

    Default

    Things seem to have gotten side tracked with the test ROM I wrote but I have been focused on the original goal.

    After laying out a few schematics in KiCAD I've settled on a solution based around an Arduino Mega2560. There is an existing project that has a few limitations with DRAM tests not being reliable because the RAS/MUX/CAS sequence are generated based on a clock source the ICE has no access to.

    Connecting to the expansion interface works around that problem because the ICE has to provide those signals. I've put together a schematic that builds on the other project but provides the ability to connect via the cpu socket or the expansion connector.
    I can detect in the software when the expansion interface cable is connected and automatically adapt the operation to whichever interface is being used.

    The cpu connection will work with the standard software from the other project, I'll be writing extensions to the code to support the expansion interface connection.

    The unit will be low cost and use easily obtainable parts. The pcb will be a custom shield for the Arduino, using common pcb mount push button and a couple of 40 pin headers. The cables will be a 40 way ribbon one will have a pcb edge connector and the cpu version will have a 40 pin dip plug.

    Untitled-2.jpg

  10. #30
    Join Date
    May 2006
    Location
    Hamilton, Ontario, Canada
    Posts
    3,751

    Default

    Ok, so this device, when used with an EI, will plug into the keyboard CPU socket on the keyboard and attach to the expansion connect when the keyboard is stand-alone?

    I suppose that makes sense since, if you were going to use it in place of the inter-module cable (which would have been nice) you would have to provide some sort of switch-in/switch out buffering to allow for the fact that some EI/CPU combinations required the buffered interface cable (which would have been REALLY nice). Ah well...

    BTW, when the ROM was modified to display only uppercase characters, it worked fine in the G board without a LC mod.
    Legacy Computers and Parts

    Sales of, parts for, and repairs to, Vintage and Legacy computers.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •