Image Map Image Map
Page 3 of 6 FirstFirst 123456 LastLast
Results 21 to 30 of 57

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

  1. #21


    Thanks Chris! I'll test these out and report back.

  2. #22


    Oleksandr responded and provided the latest software (drem.bin & soc.bit). Made no difference. So, i'm past the "upgrade to the latest release" option.

    He did ask for pointer to a M16 he could buy to fix the issue in his lab, but i dont suppose thats realistic, unless some one lives near PortaOne?

    For some reason my mini keyboard on the DREM isnt registering this morning, so i'll try the software Chris once sorted.


  3. #23


    Was already on 0.4.3, so no change in firmware for me.

    Tried the provided files, again, no change for me.

  4. Default

    I donít know if it makes any difference, but Iím using my DREM in the 26-4155W Fifteen Meg Disk System. I have the older 5 Meg unit floating around, but I could never get that one to work. I mention this because the controller boards within the enclosures are both quite different. The 5 Meg unitís controller board takes up the entire top of the unit, whereas the board in the 15 Meg unit is half the size and has a different variant of the WD controller chip. I forget the specific differences. Frank Durda IVís site had a drive reference that detailed the differences before it went offline, but hereís a link to it on

    Last edited by TJBChris; May 16th, 2020 at 06:04 AM.

  5. #25


    I've tried three of the controllers that Frank lists as the Type 3 WD1000-TB1 controller and two of the corresponding host interface boards. All work fine with real MFM drives. I only have one DREM at the moment and although it gives no indications of an issue it's possible I did something to it.

    It's been a few months since I've messed with it but if things work out I'll pull everything out tonight and re-test. I really want to get the DREM going because it supports 2048 cylinders and by swapping the WD1010 in the controller to a WD2010 you can have 142M drives in Xenix.

  6. #26


    I've been working on this with my M16A/Type 2 HDA/WD1010 Controller (15MB unit)/DREM2 combination and have something that is now working with XENIX 3. No more lockups.

    1. I took TJBChris zip and installed the PIC firmware and service core from there. They seem to be the latest DREM versions.
    2. I disabled the L2 cache preload in DREM2.ini by setting "l2 preload = NO"
    3. I set the drive select to only look at 1 hard drive in DREM2.ini by setting "DS Bitmap = 0x1"

    So far so good. No lockups and the system performs well. I will experiment with the DS Bitmap setting so that I can hopefully run a second HD. I might also play with the L2 preload. I'm not happy with the way the preload works anyway as it appears to hang the controller when preloading tracks. I hope that was the issue.

  7. #27


    I was already running the same PIC firmware and service core as Chris provided but tried the settings Pete posted and can boot dittmans Xenix image without issue!

    Still good through 3 shutdown -h power cycles and 3 shutdown -r's where as before when I had good boot it seemed like the the next would corrupt the *.dsk image.

    Pete thanks so much for digging into this!

  8. #28


    This is beginning to make sense. It looks like L2 Preload was introduced last year and possibly right around the time I started having issues.

  9. #29


    Since the settings Pete recommended has my machine reliably booting from the DREM I've done some testing and found two more potential issues.

    First, under high I/O load Xenix will throw Bugchk: HdTimeOut errors. The easiest way I can reproduce this is entering system maintenance mode during boot and running "fsck /dev/hd0". This only seems to happen during high I/O so it took a while before I encountered it.

    Xenix output:

    DREM log with all debugging enabled: DREM Log

    Second, after removing "DS Bitmap = 0x1" from DREM2.INI and hooking up the 2nd HD port I can get the DREM to lockup by loading Xenix, mounting the 2nd HD, unmounting the 2nd HD and running "fsck /dev/hd1". When this happens the DREM quickly flashes something on the screen, beeps twice like when its first powered on and goes to a blue screen or if all debugging is enabled a blue screen with CASE 1 printed on every line. The DREM log is 0 bytes in size after this occurs.

    Xenix output:

    DREM output:

    DREM output (all debugging enabled):

    I'm using fresh copies of dittman's Xenix images for each test but have also tried ones I built with the same results. My HDC has a WD2010 in it and works fine with regular MFM drives.

    I'll contact Oleksandr in the morning and describe everything tried so far. The DREM is a really cool device and I'd love to get things to a reliable state.
    Last edited by dlightman; May 17th, 2020 at 08:57 PM.

  10. #30


    I note in the DREM manual that HDD DS Bitmap is defined, but it doesnt explain which part from DREM2.ini the section is inserted. Does it matter?

    HDD DS Bitmap mask for HDD select signals. Used if DREM shall ignore some DS signals in shared HDD bus applications. Possible values: 0x0..0xF (Default). Does not affect LED functionality. LED’s are connected directly to the input drive select signals.

    I suspect:

    [hard drive 0]
    enabled = YES
    dsk file = /XENIX/X32070MD.DSK
    DS Bitmap = 0x1


Posting Permissions

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