Simon Cooke wrote: > especially as somehow it manages to play samples back
Just careful line and cycle counter timing for the gap between each out, and calls to Dave superb sound DLL to generate the data itself. I'd already done the video generation using the same sort of method so it wasn't too bad (well, after the initial pulling out to figure out the buffering!). > (but not Modplayer stuff). Really? What does it do? and where can I find some MODplayer stuff?! > There's something decidedly weird with the sound emulation though - > NT 4 shouldn't have those problems (ST_SOUND works fine, y'see). Might be my sound card drivers or the fact that it's an ISA card, but I've seen lots of other latency complaints with NT4. I allocate a single static secondary buffer x times the size needed for a single frame of data, and just top it up during after after each frame. My logging even confirms the buffer stays almost completely full! I even checked it by saving the sound data for a pure note to disk, and the WAV file is perfect but it plays with clicks in it! I might try installing NT4 at home with my SB Live! to see how it is (I usually share the same installation between home and work on a removeable hard disk). It's fine under Windows 2000 RC2, but that's got all the updated DirectX code in it! I'll have a look for ST_SOUND tomorrow and give it a try in work! > also, on the SCPDU 6 demo, the vubars are too far to the left. > FLASH looks odd too... There a many more of them too - all caused by the instruction timing for the main screen area not being right (it's a very poor approximation at the moment, but will be improved very soon!). Any very timing sensitive main-screen or bottom border effects run too quickly, so the on-screen effects are usually a bit scrambled and the bottom border effects are shifted left (but should be aligned perfectly vertically!). Ironically it's the accurate video code that's uncovering things that the previous line method masked! I'd like to go through most of the Z80 instruction set and do on-screen timing to try and sort them out. A lot of the visual glitches will be cleaned up pretty quickly, but some (like the VMPR scrolly in one of the Mnemotech demos) might end up relying on instructions split across contention boundaries which will be harder to solve! The border timing should be pretty good (thanks to people on the list!), as will the screen-off timing (as relied upon by Defender!). The external memory and ROMs are correctly uncontended too - the system reset is very slow if the ROMs are contended! > But we're getting there. Shame it took so long - if only I'd not had the summer off! *grins* > Si -> Nice work on the floppy drive emulation. I'm kind of surprised - > loaded up SAMDice, and it gave all the right kind of info for a track read > :) You damn silly fool :) It's not something that's really very useful but I couldn't resist it! I'm still doing the WRITE_TRACK data parsing that's needed for formatting correctly (currently it reports 'write protected' if you try a format). The READ_TRACK data is a bit too accurate in some way too, as the read controller seems to trip over particular values (46 or something daft) and appears to get the MFM decoding out of step after that! The general structure should be ok, even the header CRCs are correct with SDF images! Si
