Image Map Image Map
Page 4 of 6 FirstFirst 123456 LastLast
Results 31 to 40 of 57

Thread: Model 16A - HDC type 4 + DREM issue

  1. #31

    Default

    OK, I am coming to a conclusion that whilst we may all have issues with the DREM, that the issues i am having with Boot Error HC whilst trying to boot from the DREM via various images, is something more fundamental compared to the issues you are all having. Given can pass all of the HDC checks (apart from the RAM given the type #4 doesn't have RAM on board), and I can pass all of the reliability tests, including formatting a disk, then something else in my configuration could be screwy.

    Out of all of us on the thread/forum, is anyone using a type #4 card with a DREM? If so, like TJBChris could you provide you're working configuration so I can start to rule out issues.

    Steve

  2. #32

    Default

    I've been running test's for Oleksandr and sending debugs.

    After the first round of debugs he recommended:

    Removing "Step Signal Hold=8" from the DSK CFG file.
    Adding "Step Rate=0" to the DSK CFG file.

    After sending debugs with those settings he recommended:

    Adding "Data ECC=NO" to the DSK CFG file.
    Adding "L1 Sync Event=STEP" to the DSK CFG file.
    Create smaller images for the tests.

    He also says I'm running the DREM in "safe legacy mode" and while he didn't go into details I'm guessing that this is because we disabled L2 cache preload in drem2.ini.

    Up to this point I had been using dittman's XENIX image as a control which already had Data ECC set to NO but I will re-create new images of a smaller size with L1 Sync Event set to STEP and submit more debugs this evening.

    Once there is progress with the Type 2 + WDC I'll report it here and switch to the Type 4.
    Last edited by dlightman; May 19th, 2020 at 05:45 AM.

  3. #33

    Default

    Some of the suggested above he confirmed to me to, specifically:
    Removing

    Step Signal Hold=8

    and

    insert line

    Step Rate=0

  4. #34

    Default

    Progress!! Of sorts

    With a combination of the new Boot ROM (C9AC) and Chris's configs, Xenix boots!

    Well, it boots, and then complains i need a new PAL with the error:

    "BugHlt: New Pal - hardware change required"

    Into research mode again, but we're movin'!

    Do I assume this is lack of an 8Mhz CPU card, and therefore burstmode? I've tried booting the BM modded distro from Pete's archive, and I get an error "BugHlt: HRDIOE - Can't load Xenix"

    Pete, do you happen to have a Burst Mode patched DREM image?
    Last edited by Tarkie101; May 19th, 2020 at 11:21 PM.

  5. #35

    Default

    I found that if I create a new empty DREM image and do the entire format, mkfs, install on the 16B none of the issues I reported previously in this thread occur. The only difference in my setup is the

    Before I built the new image from the 16B I was using dittman's xenix.cfg/dsk or building them in trs80gp.

    I'm going to do some more testing of this and will continue working with Oleksandr in parallel.

  6. #36

    Default

    Quote Originally Posted by Tarkie101 View Post
    Progress!! Of sorts

    With a combination of the new Boot ROM (C9AC) and Chris's configs, Xenix boots!

    Well, it boots, and then complains i need a new PAL with the error:

    "BugHlt: New Pal - hardware change required"

    Into research mode again, but we're movin'!

    Do I assume this is lack of an 8Mhz CPU card, and therefore burstmode? I've tried booting the BM modded distro from Pete's archive, and I get an error "BugHlt: HRDIOE - Can't load Xenix"

    Pete, do you happen to have a Burst Mode patched DREM image?
    Consider trying TRS-XENIX 1.3.5 as it does not have the new PAL requirement. Here is 1.3.5 on the model2archive

  7. #37

    Default

    Quote Originally Posted by dlightman View Post
    I found that if I create a new empty DREM image and do the entire format, mkfs, install on the 16B none of the issues I reported previously in this thread occur. The only difference in my setup is the

    Before I built the new image from the 16B I was using dittman's xenix.cfg/dsk or building them in trs80gp.

    I'm going to do some more testing of this and will continue working with Oleksandr in parallel.
    My image was built with an older firmware on the DREM2 and I didn't have any issues with hangs or adding a second virtual HD.

    Maybe something has changed low-level.

  8. #38

    Default

    Quote Originally Posted by dlightman View Post
    Consider trying TRS-XENIX 1.3.5 as it does not have the new PAL requirement. Here is 1.3.5 on the model2archive
    1.3.5 works, no issues. But where's the fun in that

    The current thought i have is :"Can I now do a 1.3->3.x upgrade using the disk on the M2 Archive, but mount it first, and change the Z80ctl to be the non-burst version?". Thats a job for tonight, interestingly the 1.3 to 3.0 core upgrade page has no instructions - warning, fun times ahead.

    However if someone has a DREM image of a patched 3.x system (cough cough, Pete?) then that would be much simpler.

    Not sure why the image from the archive of the patched Disk 1 isnt working for me, but i'll spend some time looking at that too. I get the Disk Error message referenced in the z80ctl disassembly which may indicate a floppy error, but this is a HXC image.

  9. #39

    Default

    Here's a DREM image I created in trs80gp just to make sure that Pete's patched disk works.

    Everything installed correctly and it shows the patched version number:


  10. #40

    Default

    Well that worked first time!

    Just need 3.3 now and the development system.

    That will have to wait until tomorrow.

    Thx dlighman.

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
  •