Slowly managing to answer some older mails...
ZN wrote: > Since the GF doesn't use DMA (and I wouldn't be caught dead designing for > basically ISA DMA!), it is actually more like the Q40. The big difference > is that there is a hardware FIFO in the sound chip, that makes things > easyer. The interrupt frequency can be much lower (I estimated 4kHz worst > case for 48kHz stereo 16 bit full duplex, less for shorter samples or lower > sample rates). OK, I see. So you'll also include a programmable timer? And max 4kHz sounds already a lot nicer to handle than 20kHz. Just for comparison for people less into the subject, a typical PC normally employs an interrupt rate of about 0,1kHz, never really going beyond 1kHz (except of course when using a QXL under DOS or QPC1 prior to v1.20, there it's 2kHz). > As for designing a new sound system, what did you have in mind? I'm not really sure. It's just that the FIFO buffer currently employed is difficult to implement in a DMA based system. It could be done to a degree but well, applications using the SSSS could e.g. in theory feed their data byte per byte to the system which gives me a major headache when trying to implement this on a continuously playing loop buffer (and that's what PC sound buffers are). Furthermore the 20kHz trouble me. DirectSound employs one primary playback buffer which contains the actual samples send to the sound card (i.e. its frequency is the output frequency of the sound card), applications however use secondary buffers which virtually can have every format. DirectSound mixes them on-the-fly into the primary buffer. But sound quality is reduced if the primary buffer runs with 44kHz (which it usually does) and I use a secondary buffer that uses 20kHz, the conversion might be noticeable, especially on clean sounds like a sinus wave. I could ask the system to set the primary sampling rate to 20 or 40kHz, but then the secondary buffers of other PC programs (like an MP3 player) suffer quality loss. All this might seem insignificant to some, but those are the decisions and problems I have to deal with and if I do something I'd like to do it as good as possible. Therefore ideally a sound system should at least provide an interface to set the sound frequency (+ mono/stereo, 8/16 bit...), then applications only designed for Q40 could work (with probably reduced quality), but more sophisticated ones can use higher and more common sampling rates. > I always though the sound system should really be a device. Sounds good from an application programmer's point of view. I'm just not sure how much overhead this will add to the whole thing. Didn't Simon write some wrapper device for the SSSS? ["fast" memory] > Could this feature be 'back-annotated' into SMSQ/E for GC/SGC (although in > their case it's not a crytical requirement), QXL, Qx0? This is definitely > something very beneficial to all platforms. The code is platform independent and I will make it available (in the end it's not much different code after all. The figuring out how to do it and later fixing bugs on a not-at-all-booting system was the major part of it). >> - WMAN v1.54. This is the first WMAN that actually implements the new >> colour definition scheme. >> >> The new colour format word is: >> >> %00000000cccccccc exactly as before > I am assuming 8 color traditional definition with stipple? Yes. >> %00000001pppppppp palette >> %00000010pppppppp system palette >> %00000011gggggggg gray scale >> %01ssxxxxxxyyyyyy palettte stipple. see below (*** NEW ***) > Ah - great idea. However, it occurs to me that the system palette (IIRC > from that little exploration with Jim et all post US meeting this is Aurora > based) should be sorted to put 'linear' 64 colors (based on 2 bits each R, > G, B) into the first 64 entries I only included the above option because of the way the current palette is designed (the first 64 entries form a complete subset of the palette). I strongly discourage any messing around with the _PAL palette. If Jim needs an own palette for icon drawing then there's no problem at all to implement this internally and use 24bit draw calls for it. > Now, something that is not clear to me, when this was originally discussed, > a mode was mentioned where a 'palette-like' structure would hold some > standard system color assignments, to be used by graphical elements (such > as background color, window border, window background, etc etc). > Manipulating this would essentially alow the user to set up their preferred > 'look' of WMAN without needing to do that for each and every program. Or am > I mixing up 'palette' and 'system palette'? No, that's exactly what the system palette is about. I post more details of my thoughts when time permits. >>Attendants of the US-QL show: the QPC executable is the same but for >>the new fast memory facility you have to update to SMSQ/E 2e99. I >>found the problem on the flight to Los Angeles :-) > So, what was it? :-) In order to stay compatible with SYSMON I had to do some stuff to the common heap that somehow messed things up. As I will be updating SYSMON this isn't necessary anymore anyway. Marcel
