> > What's wrong with sound emulation?
>
> I did make several direct emails reporting the sound problem, but again, a
> different thread.
Ah, I see it now. "Cannot interrupt note playing" on 3/8. A very short thread
between you and you. Oh, wait, there are two more on 3/12. You and Jay Hong.
Honestly, I didn't read those postings. There are just too many coming across
my desk every day. I can't read them all, so I need to skim by subject. There
was nothing in the title to indicate that this was an emulator problem, so I
skipped it. I would also offer the defense that it was posted to this forum and
not the emulator forum.
As for what's wrong with sound emulation, yes, you've hit upon some
deficiencies. The main deficiency is that I'm no sound expert. Certainly not
on all three platforms that Poser runs on. Neither am I a hardware expert,
serial expert, graphics expert, TCP expert, USB expert, UI expert, Unix expert,
or any of the myriad other things I've had to dive into in order to make Poser
the far-reaching utility it is today. By which I'm saying that I'm already
stretched pretty thin in other areas that devoting major amounts of time to
sound is not practical (I'm definitely not saying that since I was able to pick
up those other abilities that picking up sound programming would be a snap!).
That's one of the reasons why Poser is Open Source. If there are Sound experts
out there, I whole-heartedly encourage them to help out with the areas that I'm
thin on. In fact, the Windows sound emulation was provided by a 3rd party
developer. I then did the Mac part (stealing code from the Mac Simulator
libraries), and another chap here did the UNIX part.
FWIW: here is some background on sound emulation. As Jay says, sound is not
emulated at a hardware level. Trying to do that is just not feasible. On the
Dragonball, sound is created by tweaking the PWM at certain rates and times.
Because emulated speed is not the same as on a real device, you'd get different
sounds if Poser were to try to trigger off of the PWM tweaking. Therefore,
Poser instead patches SndDoCmd, translating the parameters into something that
sort-of kind-of make sense in the host API.
> > What do you mean by the emulating missing when it needs to update
> > the screen?
> Under Windows 98SE, it sometimes does not update the screen image at all
> when the image changes, or updates scattered parts of the
> image, when the background changes. I honestly couldn't tell you a pattern, >
because I haven't really found one. For example, if I
> simply turn the power on and off, usually it works fully, sometimes it
> redraws part of the screen, and sometimes it misses it. But
> you can always see what's really on the screen by dragging the entire
> emulator off the desktop and then back on, forcing a WM_PAINT
> message. What this says to me is that the emulator is always updating its
> internal 2x image buffer (could be updating it very, very
> fast), but is not always telling windows to update the buffer to the
> screen....[extrapolation again, but I add it to help visualize
> the problem I'm describing]
I definitely haven't seen this problem. At least, not in a couple of years,
when I thought I fixed the last update problems.
FWIW, here is some background on Poser's screen updating. For the most part,
Poser attempts incremental updating. It keeps track of where the LCD buffer is
in emulated RAM, and keeps track of write accesses to that range of RAM,
recording the highest and lowest modified addresses. This all occurs in a
thread used solely for emulation (I call this the CPU thread). Then, every 1/10
of a second, the UI thread wakes up and performs idle-time activities. One of
these activities is updating the host display. The UI thread halts the CPU
thread, and then examines the hardware registers and the recorded highest and
lowest modified LCD buffer addresses. From this information, it determines
which LCD rows need to be updated, and then updates them. When it's done, it
resets the highest- and lowest-address variables and restarts the CPU thread.
>From this, you can see that there's really no "internal 2x image buffer". Poser
takes the LCD buffer as established and used by the emulated Dragonball (or SED)
hardware, converts that to a Window DIB, and then copies that DIB to the host
HWND.
The next parts of your e-mail aren't really organized in a way that I can hammer
out long explanations in a logical order, so instead I'll just insert small
comments here and there.
> What I was suggesting was to
> redraw 100% of the current Palm screen memory onto the Windows screen so
> many times per second, so that I can see what's going on at
> a higher frame rate.
I'm not sure that a higher frame rate will help. 10 fps is pretty fast as it
is. Going to, say, 20 fps won't give you time to examine what's going on on the
screen (unless your ability to focus on the task at hand is far greater than I
give most humans credit for...unless...did you ever read "A Deepness in the
Sky"?).
> Based on my observations, I was assuming that (1) since the whole screen
> wasn't always updated, that the
> emulator was attempting some kind of delta screen update
This part is true...Poser attempts incremental updating. It speeds up emulation
greatly.
> and (2) since the
> whole screen doesn't update very often, that maybe
> Windows updates happen on a very low priority in the Emulator.
> [Extrapolation]
If there are parts of the screen that are not updating, then that simply a bug
that needs to be ferreted out.
> So my suggestion was aimed at upping the visual update rate now that the
> computation power is there.
Increasing the update rate won't help any update problems. If Poser missed
something on some frame and didn't update the whole LCD, then it's not going to
get it the next time around either (because those upper and lower address
markers I mentioned earlier get reset every time).
> Your suprise may be
> related to the other problem I observed, i.e., maybe the internal graphics
> buffer of the emulator IS updating very fast, but Windows
> is getting very few draw commands.
Just to re-iterate for the sake of attempting to be clear, Poser doesn't have an
internal graphics buffer, and Windows is getting draw commands every 1/10 of a
second. Actually, I should elaborate on that last comment: if the upper and
lower LCD address markers indicate that *no* LCD bytes have changed, then no
Windows drawing commands are issued.
> But whatever the extrapolated reasons, I would love to see on my emulator
> the palm screen updating at least 20 fps. The faster the
> Palm emulates under the hood, the faster the screen refresh I need to see
> what's happening before it's all over.
Oddly, I always viewed a different feature as being more useful. On Newton (I
used to work in the Newton group at Apple before it got melted down and many of
us moved over to Palm), we had something called "molasses mode". In this mode,
graphics drawing would pause after every primitive drawing call. This way, you
could easily see what was going on (double updates, ineffective drawing, etc.).
I'd considered for a long time adding something like that to Poser. It never
occurred to me that someone could actually tell the difference between 10 and 20
fps such that they could better see what was going on at 20 fps.
> OK, Keith - you be the judge. Was I any better this time, or was I still
> not specific enough?
As those Judge Judy says, "It's good to be the judge!" :-) So I'll let you be
the judge. If my responses to your comments made sense, then you were clear
enough. So it's up to you to judge my response!
-- Keith Rollin
-- Palm OS Emulator engineer
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
