Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.sys.ibm.ps2.hardware    |    Discussing IBM PS/2 hardware    |    42,985 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 41,873 of 42,985    |
|    Kevin Moonlight to Ryan Alswede    |
|    Re: Snarky stalker?    |
|    02 Jul 23 02:40:14    |
      From: me@yyzkevin.com              on the topic of duke3d, I have not been able to get any version to crash       including the one listed above. I would not say this is conclusive of       anything, but it is perhaps potentially maybe might be could be promising...       still need to test on some        other machines, of which working I have the 50Z with IBM 486 Planar, and        the PCServer 500 S/390 which I can pop out to try the soundcard in.              The adlib distortion/jibberish was really bothering me, something so simple       having issues. I started trying to understand a bit more. I was measuring       the channel ready signal and I would often see what to me were unexpected       transitions as I currently        understand that every slot has its own channel ready signal, and the system        logically or's them together to drive a common channel ready return. I saw       the various historic discussions mentioning system speed etc, programs not       having delays, the        JP5 (channel ready) and it all ending at the :solution: being creatives CQM       chip that always responds quickly.              in any case, I thought perhaps asserting the channel ready only briefly was       not enough as the default extended cycle varies per system. so I made some       changes converting the ready signal to a latch and clearing it some clock       cycles later... and        then initially I thought it was magic I was hearing near perfect adlib       audio, but then I heard a glitch here and there and while 1000% improved       something was not right.              I was seeing propagation delays between my test signals I could not explain       and then while looking at the hardware I noticed something. My board is       all populated with 74HCT family chips. While by itself this would not have       jumped out at me, the        note from TubeTime is concerning:              "Logic chips are all specified as AHCT, but ALS or ACT may also be used. Do       not use LS or HCT devices, particularly for U2, since Micro Channel is a much       faster bus than ISA and this logic is not quite fast enough to meet the timing       margins. "              So I may be using a unpredictable wildcard here for my testing, I will need       to see if this part substitution may be contributing to the adlib issues.        why adlib and not soundblaster? I suppose the dsp commands are by design       very slow due to the "       inbox/outbox" and status register topology, and during audio playback with       DMA this presumably has some differences causing it to not fall victim to a       potentially timing tolerance issue of these out of spec chips. no sure.               Another user on the facebook group mentioned the same adlib symptom on       some systems, i've asked them where they got the board and when it was       made, I may follow up and ask what family the logic chips are. maybe it       means nothing.                            On Saturday, 1 July 2023 at 22:03:29 UTC-4, Ryan Alswede wrote:       > >> after. Some games may have intentionally not been clearing the interrupt       flag for some other reason, these will not be happy. This is all just       experimentation in fun at this point. quite a hack.       > Try Duke Nukem 3D basic version with your TSR work around for fun. Atomic       edition works. Basic 3D does not.        >        > Located here if you don't already have a copy.        > https://archive.org/details/duke-3-d              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca