Questions for Frank Durda on PSSJ (Tandy DAC)
Jeffrey L. Hayes
Frank,
I'm going over my Tandy sound package (tspak17.zip) again, trying to fix
some of the mistakes in it, referring to your PSSJ toolkit. I have a
couple questions and thought I'd ask them in the newsgroup since the
answers might be interesting to others as well.
You have a machine type M3000 defined, which you identify as "286 8.0
MHZ 1W". Is this the Tandy 3000? If so, it isn't listed in your docs
as one of the models having the DAC. If "1W" means "1 watt," could it
be some kind of laptop using an 82C86 processor? Are there laptops that
came with the DAC installed, and if so, do you remember which ones?
(Tandy's support site gives no clue as to which systems have the DAC.)
I take it the PSSJ expansion card came with a software driver that needs
to be loaded from CONFIG.SYS. Correct?
Finally, why is it necessary to enable DMA EOP interrupts at the DAC to
enable the joystick, as you do in your INIT code (the notation says that
it brings the IRQ out of tristate), and why do you have to set the DAC
volume to zero? I'm adding a /J option to my Setdac program to reenable
the joystick after playing sound, something I should have thought of
before (Ken Udut's program to do this on my ftp site won't work on newer
models because the DAC base port is hard coded at 0C4h in it).
I'm looking forward to seeing your answers, should you choose to
respond.
Jeff Hayes <tv...@agate.net>
Frank Durda IV
"Jeffrey L. Hayes" (tv...@tvdog.sdi.agate.net) wrote:
[0]Frank,
[0]
[0]I'm going over my Tandy sound package (tspak17.zip) again, trying to fix
[0]some of the mistakes in it, referring to your PSSJ toolkit. I have a
[0]couple questions and thought I'd ask them in the newsgroup since the
[0]answers might be interesting to others as well.
...
[0]I'm looking forward to seeing your answers, should you choose to
[0]respond.
I assume this public posting is because I haven't replied to your EMAIL
from last week. Note I get three or four dozen pieces of mail that require
answers every day (not counting spam and unsolicited advertising) and yours
is just backlogged. I think I recall the topic and I'll say something
about that below.
[0]You have a machine type M3000 defined, which you identify as "286 8.0
[0]MHZ 1W". Is this the Tandy 3000?
Yes a 3000HD to be precise, with the fan in the front. Serial Number
00007 as I recall. I originally got it to do the Iomega drivers for
XENIX System III 286.
[0]If so, it isn't listed in your docs as one of the models having the DAC.
The docs should state that Tandy built a plug-in card with the PSSJ chip
that would fit in any XT slot. I happened to have a Tandy 3000HD on
my desk during that period and used it for most DOSish development.
It wasn't until late 1989, well after I was maintaining Deskmate Sound
and Music that I even had a 1000 series computer in my office. Up to
that point, I used the 3000 or went down to a lab.
There were only a few of these XT PSSJ boards made, and I think I now
own 90% of them. They are pretty nasty looking.
[0]If "1W" means "1 watt," could it
It means "1 WAIT state". Like the documentation says, the first version
of the PSSJ chip (code name: Jacksboro) was not double-buffered on record,
and the delay of moving a computed sample via DMA to main memory delayed
when the computation of the next sample would start. This skewed
recordings, and the speed and wait state count of the processor were two
of the factors that determined the size of the skew.
Because the record sample rate had 1/10 the number of "detents" on the
rate control, we just lived with the fact that the recordings were made
at the wrong speed, and tried to compensate by playing them back
slightly off-speed since play-back had better speed controls. There
is a table in Deskmate Sound, Music and the Sound Library code
that tries to compensate by varying the playback rate based on where
the sound was recorded. These numbers came from some tests, a bit of
black art, and some plain guessing. No number is right at all times.
After moaning about this for two years, the second generation PSSJ (Bonanza)
contained double-buffers on the record side. This also required changes
to "prime" the chip for recording, since it wouldn't just start the DMA
as the older chip did when you put it in the desired operating mode.
One of the reasons for the Deskmate Sound file format changed around 1989
was to add a field that indicated what machine had created a file
so we could play them back correctly. The original file format had NO
unused fields. I did *not* design the original. It's replacement has
perhaps 50 bytes of reserved-for-future-use fields. I didn't want to
get trapped again. This is the current .SND file format used by all
direct-to/from-disk PSSJ audio files.
[0]be some kind of laptop using an 82C86 processor? Are there laptops that
[0]came with the DAC installed, and if so, do you remember which ones?
There were no laptops with the PSSJ chip. It really isn't low-power enough,
and at that time, sound in the laptop was not the thing to do. Digital
sound implied big hard disks and Laptops were coming out with drives 1/4th
the size in Mbytes that we stuck in desktops.
[0](Tandy's support site gives no clue as to which systems have the DAC.)
1000SL/TL/SL2/TL2/TL3/RL/RLX/RLS/RSX/2500/2500SX and possibly
others. The last system using the PSSJ chip was made sometime
in 1991, although Tandy briefly considered bringing it back
for some special applications in 1992.
Panasonic models based on 1000SL/TL (but sound interface parts
are missing, ports are there and the BIOS says the sound hardware
is there)
Custom systems built for Hallmark and some other business firm
(I forget now) - these were all based on 1000SL/TL type systems.
Supposedly some Walmart 1000AX systems actually contained newer
MLBs and would have had audio, but no microphone connectors.
Digital playback would have been possible.
[0]I take it the PSSJ expansion card came with a software driver that needs
[0]to be loaded from CONFIG.SYS. Correct?
No, there was a small .EXE or .COM that simply made the TI 3-voice part of
the chip shut up. There was a second .EXE that loaded a BIOS extension
that faked-out the BIOS calls. However, I got tired of forgetting to load
that stub on the 3000 I was working on, so the library code tries the BIOS
and if that doesn't work, it looks where the plug-in card would be anyway.
[0]Finally, why is it necessary to enable DMA EOP interrupts at the DAC to
[0]enable the joystick, as you do in your INIT code (the notation says that
[0]it brings the IRQ out of tristate),
Huh? You will have to refresh my memory since I haven't looked at the
code in two years.
I *think* you are asking about why we had to drain the DAC when ending
DMA operations. As I recall, you had to make sure that the DAC engine
had absolutely nothing left in the double-buffer or it refused to change
back to sucessive approximation operation, which the joysticks
used. This is effectively the opposite of the "priming" function that
had to be done to get DMA started on the Bonanza version of the chip.
If you have the older PSSJ chip, these steps are not necessary, but
don't hurt anything either. The newer chip requires them.
[0]and why do you have to set the DAC volume to zero?
If you don't, the unit makes an annoying "click" when it goes in and
out of an audio mode. The "off" output of the PSSJ analog outputs is
not equal to the value the chip would output if playing centered
silence (0x80). This is what you get when the audio capability was
really an after-thought. The DAC is there to make the joysticks easier
to assemble at the factory compared to what had to be done in the HX/EX/SX/TX
and earlier 1000 systems. The extra 35 cents of hardware that makes audio
possible was truely an after-thought.
The Sound Editor was not intended as a product either, merely an internal
tool to make the instrument files for the new version of Music.
The library code goes to great lengths to reduce the amplitude of the
click, by a series of cascading volume adjustments timed when gain control
adjustments. Each change of volume causes a small voltage output from the
audio system, but the idea in this code was to keep the rate of changes
below 12-18Hz, and thus below human perception. Without this ramping
code, the "click" would deafen audiences in large rooms when these systems
were connected to large PA systems. The merchies flamed us constantly about
this, but the hardware management always suggested that software should
be able to deal with this. Tandy hardware management had a habit of
saying "you can always fix hardware with software", even if smoke and
flames were involved.
There is a flag in the library called FASTRAMP or something like that which
bypasses this process and you can hear the unconcealed click.
That is also why the library code only changes modes when it has to, unlike
the Deskmate Sound and Music programs that changed modes frequently and
the BIOS calls that constantly change modes.
- - - -
Jeff, as to the state of the library code, a permanent FTP/WWW site will be
available fairly soon that I will maintain, and the non-beta version of
the library will be one of the many things that will appear fairly quickly.
I still have a problem with sites that have gotten hold of outdated versions
of code I have written, put it up for FTP access without asking or even
letting me know it is there, and then I get mail all the time from people
using the obsolete versions that are having problems.
So far, only a fraction of these sites have cooperated by replacing the
old code with current code or even flagging the code as obsolete. Some
can't cooperate for semi-legit technical reasons (like their FTP site
archive is accessed from write-once media and they would have to rebuild
the entire thing just to change this one item) or they just don't want to
delete anything that they have collected and thus reduce the size of
their collection (the most common reason given). They like having
37 different versions of some program in their collection, including
all the betas they got their hands on! I just don't have time for this.
Therefore, I am really negative on putting code on FTP sites that don't
have an agreement with me that when I want my code replaced, it gets
replaced promptly. This position hasn't changed and I hope you
understand why.
Frank Durda IV <uhc...@nemesis.lonestar.org>|"The Knights who say "LETNi"
or uhclem%nem...@rwsystr.nkn.net | demand... A SEGMENT REGISTER!!!"
|"A what?"
or ...letni!rwsys!nemesis!uhclem |"LETNi! LETNi! LETNi!" - 1983
(c) 1996, ask before reprinting.
Leonard Erickson
"Jeffrey L. Hayes" <tv...@tvdog.sdi.agate.net> writes:
> Frank Durda IV wrote:
>> There were only a few of these XT PSSJ boards made, and I think I now
>> own 90% of them.
Gee, were there any *non* XT PSSJ boards made? That is AT boards?
> Maybe you could sell some, then :-). I want the 1989 version, though.
Second the motion.
--
Leonard Erickson (aka Shadow)
sha...@krypton.rain.com <--preferred
leo...@qiclab.scn.rain.com <--last resort
Jeffrey L. Hayes
Frank Durda IV wrote:
>
> "Jeffrey L. Hayes" (tv...@tvdog.sdi.agate.net) wrote:
> [0]Frank,
> [0]
> [0]I'm going over my Tandy sound package (tspak17.zip) again, trying to fix
> [0]some of the mistakes in it, referring to your PSSJ toolkit. I have a
> [0]couple questions and thought I'd ask them in the newsgroup since the
> [0]answers might be interesting to others as well.
>
> from last week. Note I get three or four dozen pieces of mail that require
> answers every day (not counting spam and unsolicited advertising) and yours
> is just backlogged. I think I recall the topic and I'll say something
> about that below.
True, you didn't reply. I had thought it due to lack of consideration
or perhaps prickliness but I didn't realize the volume of email you get;
my apologies for my evil thoughts. Regardless of my subterranean
motives, I'm sure there are a few of us out here interested in the
technical aspects of the 1000-series and grateful for your extended
response.
> There were only a few of these XT PSSJ boards made, and I think I now
> own 90% of them.
Maybe you could sell some, then :-). I want the 1989 version, though.
> Because the record sample rate had 1/10 the number of "detents" on the
> rate control, we just lived with the fact that the recordings were made
> at the wrong speed, and tried to compensate by playing them back
> slightly off-speed since play-back had better speed controls. There
> is a table in Deskmate Sound, Music and the Sound Library code
> that tries to compensate by varying the playback rate based on where
> the sound was recorded. These numbers came from some tests, a bit of
> black art, and some plain guessing. No number is right at all times.
Sounds like timing the chip as I'm doing when I record is the correct
method.
> [0]Finally, why is it necessary to enable DMA EOP interrupts at the DAC to
> [0]enable the joystick, as you do in your INIT code (the notation says that
> [0]it brings the IRQ out of tristate),
>
> Huh? You will have to refresh my memory since I haven't looked at the
> code in two years.
INIT.ASM, lines 107-9:
mov dx,DacBase ;Put in joystick mode
mov al,DMAIEI ;Take irqs out of TRISTATE
out dx,al ;C4/304
I found that without writing DMAIEI (10h), interrupting a DMA in
progress would disable the sound chip (I have the old version of the
chip in my 1000TL).
> [0]and why do you have to set the DAC volume to zero?
>
> If you don't, the unit makes an annoying "click" when it goes in and
> out of an audio mode. [much more omitted]
Thanks, I'll have to take a closer look at the code in RAMPUP.ASM.
> The Sound Editor was not intended as a product either, merely an internal
> tool to make the instrument files for the new version of Music.
Wow. Considering that DeskMate Sound runs on an 8086, I doubt there is
as good a sound editor available that will run on the same hardware. A
couple people have written me asking for a SoundBlaster version.
> Jeff, as to the state of the library code, a permanent FTP/WWW site will be
> available fairly soon that I will maintain, and the non-beta version of
> the library will be one of the many things that will appear fairly quickly.
Looking forward to it. You told me before that you had several CDROMs
filled with various software, so it should be quite a site. One thing -
when you posted the PDST in the newsgroup, you made it a sequence of
Unix shar archives, hard to deal with under DOS. Since the systems that
have the DAC run DOS, I think it makes more sense to make it a .zip
archive with directories included and have some text instructions on the
site that say to decompress with "pkunzip -d". You might delete the
Unix man and Postscript versions of the documentation to reduce the size
since hardly anybody with DOS will be able to make use of them. (DOS
Ghostscript requires VCPI and will not run on less than a 386.)
> I still have a problem with sites that have gotten hold of outdated versions
> of code I have written, put it up for FTP access without asking or even
> letting me know it is there, and then I get mail all the time from people
> using the obsolete versions that are having problems.
>
> So far, only a fraction of these sites have cooperated by replacing the
> old code with current code or even flagging the code as obsolete.
Well, I *did* get the PDST removed from Musie when you objected.
> Therefore, I am really negative on putting code on FTP sites that don't
> have an agreement with me that when I want my code replaced, it gets
> replaced promptly. This position hasn't changed and I hope you
> understand why.
You wouldn't be the first person to say they don't want their stuff on
my site. Michael Klos keeps telling me I can get a distribution license
for Klos PPP, but he never offers me one; he prefers that I link/refer
to his site. I would make that agreement with respect to the PDST,
though. The source for the PDST is like the Greek version of the Bible
- it's not easy to understand, but it's authoritative :-). (Never mind
- you've already explained that the complications are due to the badly
designed hardware.)
Thanks again for the response. I'm waiting for the post when you
announce your site.
Jeff Hayes <tv...@agate.net>
Frank Durda IV
[2]"Jeffrey L. Hayes" (tv...@tvdog.sdi.agate.net) wrote:
[2]True, you didn't reply. I had thought it due to lack of consideration
[2]or perhaps prickliness but I didn't realize the volume of email you get;
[2]my apologies for my evil thoughts.
Actually, I now realize I understated the volume of mail. I was talking
about just mail addressed directly me to me, not counting the mail that
arrives in even greater volumes in the FreeBSD Project mailing lists I
must monitor.
[1]There were only a few of these XT PSSJ boards made, and I think I now
[1]own 90% of them.
[2]Maybe you could sell some, then :-). I want the 1989 version, though.
I actually have four total (I believe only five were made, so I should have
said 80%), one has some distortion problems and only one was ever retrofitted
to handle the newer PSSJ chip. I'm afraid I won't be selling it for
various reasons.
[1]Because the record sample rate had 1/10 the number of "detents" on the
[1]rate control, we just lived with the fact that the recordings were made
[1]at the wrong speed, and tried to compensate by playing them back
[1]slightly off-speed since play-back had better speed controls. There
[1]is a table in Deskmate Sound, Music and the Sound Library code
[1]that tries to compensate by varying the playback rate based on where
[1]the sound was recorded. These numbers came from some tests, a bit of
[1]black art, and some plain guessing. No number is right at all times.
[2]Sounds like timing the chip as I'm doing when I record is the correct
[2]method.
I am confused - there is no way to compensate for the flaw in record
rate while recording. The speed at which samples are picked up is
dependent on the DMA (assuming you are using DMA), and when the CPU happens
to finish the instruction it is executing when the DMA asserts the HOLD
line, which is how a device other than the processor requests the bus
so it can become a bus master. The CPU will always finish executing
the current instruction, and if the current instruction takes 172 clocks, so
be it. You never know exactly what instruction or group of instructions
the processor will be executing when the DMA needs to do a transfer.
The old PSSJ, won't latch the voltage level on the input for the next
sample until the current sampled byte is read by somebody (DMA or CPU).
This is what induces the sample rate error. There is no workaround in
record. The fix is to use the newer PSSJ chip.
As I mentioned, we compensated to some extent by playing the audio back
a bit slower than exactly 11K or 22K or 5.5K to match as close as possible
the typical error in the record speed. This is the same idea that a
video tape recorded on a badly aligned VCR may only play back correctly
on that one machine. People with perfect pitch listening to music
could detect the error, but most people never noticed anything.
Of course, sounds sampled elsewhere or on the newer PSSJ chip could
be played back at exactly the right speed, assuming "right" was one
of the available speeds. Because of the cheapness of the hardware,
11,025, 22,050 and other common speeds were not the ones the hardware
could actually deliver. The actual rates are listed in the source
code somewhere, or can be computed by dividing 14.31818MHz (4x NTSC
television color burst frequency) down by whole numbers and see what is
available. Why was this strange value used? Cheap: color burst
oscillators are one of the most common speeds made and as such are the
least expensive available. A crystal running at a frequency that divides
down into a "standard" sampling rate like 22,050 or 44,100 will cost more.
Of course, those "standard" speeds did not exist in PCs in 1988 when
we brought this out. This predates SoundBlaster by a year. 8KHz
was the only "standard" speed anyone was talking about and that was
because the phone companies use that speed with u-law or A-law encoding.
We didn't have hardware to do anything but linear PCM.
[0]Finally, why is it necessary to enable DMA EOP interrupts at the DAC to
[0]enable the joystick, as you do in your INIT code (the notation says that
[0]it brings the IRQ out of tristate),
[2]INIT.ASM, lines 107-9:
[2] mov dx,DacBase ;Put in joystick mode
[2] mov al,DMAIEI ;Take irqs out of TRISTATE
[2] out dx,al ;C4/304
[2]I found that without writing DMAIEI (10h), interrupting a DMA in
[2]progress would disable the sound chip (I have the old version of the
[2]chip in my 1000TL).
Look around the source code in that immediate area for an edit tag. That
is something that looks like <18>, or some other number. This indicates
exactly when work was done on a piece of code last, usually down
to the individual lines, unless the entire code section appeared at
a given edit, then the general comments at the top of that piece of code
should have an edit tag. This is an ANSI convention for marking code
changes that predates things like RCS/SCCS/etc. I use it today since
it allows changed code to be spotted without having to check out old
versions and do diffs. (I also get flamed in some quarters for using
"too many comments" in the code :-) Tough. )
Anyway, if you can find an edit tag near that code, go to the file
with the edit history in it. Because I am upgrading the OS on my
main server right now, all that code is not online so I can't take a
quick look, but if I followed my standard convention, there should be
a file like version.asm, .s or .src (or version.h for C code), and there
should be a section with a line like
Edit History EDIT HISTORY edit history
and you can grep for those words. Then search down for the Edit
number and there should be an explanation of what changes were made and
why. Sometimes the explanation will go for pages, so don't discount
this running dialog on why development went the way it did. I believe
the beta version of the library has some of the early edit history entries
removed, plus some of the more slanderous comments were pulled, such as
"Those idiots in Tandy Merchandising have screwed us again", etc.
In hindsight, I could probably start every source file with that last
statement and it would have applied, and no court would convict me. :-(
But, I was trying to be nice and get them to put other code into the
public domain...
Anyway, do take the time to read the Edit History as it will help show
how the software evolved, when problems surfaced or directions changed,
etc.
[1]The Sound Editor was not intended as a product either, merely an internal
[1]tool to make the instrument files for the new version of Music.
[2]Wow. Considering that DeskMate Sound runs on an 8086, I doubt there is
[2]as good a sound editor available that will run on the same hardware. A
[2]couple people have written me asking for a SoundBlaster version.
Yeah, and IBM sued us over that beauty, claiming we infringed a patent
they filed a few months earlier. The patent says IBM owns the idea
of a vertical line marking a position in time in a waveform, accompanied
with a numeric display showing the number of bytes, elapsed time, etc
that this point represents. Clearly IBM had never heard of storage
oscilloscopes that have been around even longer and have the exact same
capability, or the Macintosh sound editor that we did copy elements from
that did the exact same thing. Apparently the guy in the patent office
had not seen these things either and granted this patent. Yet another
argument as to why software patents are a stupid idea and should not exist.
[2]I think it makes more sense to make it a .zip archive with directories
I had planned to do that. The previous distribution had to fit the
requirements of a USENET news distribution (.shar), and was configured
accordingly. (Comp.sys.tandy and alt.sources do not allow uuencoded binaries
except as part of a package also containing source.)
For FTP/WWW download, formats native to the target platform can be used.
[2]You might delete the Unix man and Postscript versions of the
[2]documentation to reduce the size since hardly anybody with DOS will be
[2]able to make use of them.
No, they will still be available, but as separate pieces. People can
print postscript even on plain DOS machines. I know, as when I prepared
the documentation, the postscript printer was at work and I accessed
it from a MS-DOS box.
[2]Ghostscript requires VCPI and will not run on less than a 386.)
That is why the original version included ASCII printable documents too
just copy them to lpt... These are the files to display. Even
the DOS MORE command copes with these files.
[2]Well, I *did* get the PDST removed from Musie when you objected.
Um, well, actually I wrote to the campus computer services administrator
and he removed it, or at least that is what he wrote in his reply.
In any event, playing that game is messy, and I've got dozens of other sites
that weren't this cooperative, or simply don't speak English, and they have
outdated versions of my stuff too. So, I want better controls in future.
I hate to say it, but sites done as student or buddy deals through
universities and schools are some of the worst ones to deal with.
Sometimes because of school confidentiality rules, I can't even find out
who holds the account where the stuff resides or how to send EMAIL. (Example,
last time I checked, it still isn't possible for someone in the
UUCP domain to send mail to agate - it loops in the campus computers.)
Then, unless I can point to a file in the US Copyright office, it is my
word against that of some nameless person that the campus computer
department never seems to be willing or able to contact. Result: nothing
happens. I don't like this and want to avoid dealing with it.
- - - -
FEI, now that I am somewhat moved into my house and about 80% of the
stuff I had in attics and closets of parents, relatives and mini-warehouses
is all in one location, I realize, I have way too much TRS-80-related
stuff.
When I was preparing to move a year or so ago, I offered a lot of manuals
for sale. I didn't do any hardware at that time because I didn't
have the ability to get it all together and sort out what I need to
keep for a parts inventory for the systems I plan to keep, and what parts
can go.
Looks like in the next few weeks I will have made enough of a determination
on this stuff (including just identifying what some of it is - I have
some stuff that I can't identify at all) and I'll post a note announcing
a sale. I know I've got a prototype (but working) 1000HX, hard disk
interfaces for Model Is, Model I/III external floppy enclosures, external
hard disks (primaries and secondaries), cables of all sorts, lots and lots of
boards for Model II/16/6000 systems, including some 6000 MMU boards, and
lots of 8" floppies with "stuff" on them. I've also got about 20,000 8 and
9 digit LED displays for calculators, lots of Rockwell calculator guts,
even some of the 8 digit flourescent displays Rockwell used in some models.
And of course, I found more manuals, service manuals, and other documents
that I don't want, not sure why I have them, etc.
So, end of October or early November will be garage sale time. Stay
tuned.
Frank Durda IV
Leonard Erickson (sha...@krypton.rain.com) wrote:
: Gee, were there any *non* XT PSSJ boards made? That is AT boards?
An XT board will plug into an AT slot. It just doesn't have the
second set of fingers. On the other hand, an XT card will work
in all 1000-series computers in addition to all AT-class systems.
Unless you need the 16-bit DMA or upper interrupt lines, an XT-only
connector is a smart move.
Jeffrey L. Hayes
Frank Durda IV wrote:
>
> I actually have four total (I believe only five were made, so I should have
> said 80%), one has some distortion problems and only one was ever retrofitted
> to handle the newer PSSJ chip. I'm afraid I won't be selling it for
> various reasons.
Jeez, 5? In the whole world? I really didn't need to change all my
programs to make them compatible, if that's the case ....
> [1]Because the record sample rate had 1/10 the number of "detents" on the
> [1]rate control, we just lived with the fact that the recordings were made
> [1]at the wrong speed, and tried to compensate by playing them back
> [1]slightly off-speed since play-back had better speed controls.
>
> [2]Sounds like timing the chip as I'm doing when I record is the correct
> [2]method.
>
> I am confused - there is no way to compensate for the flaw in record
> rate while recording. [Much more interesting stuff omitted.]
> This is what induces the sample rate error. There is no workaround in
> record. The fix is to use the newer PSSJ chip.
Well, I'm afraid I can't take "it can't be done" for an answer, since I
have to do it. And saying, "We'll record it at the wrong speed, then
play it back at the wrong speed, and it will sound right, since the two
errors will cancel out," doesn't cut it, either. What does my hapless
user with a 1000SL do when he wants to record a sound and give it to his
best friend who has a Mac?
So what I'm doing is calculating an initial guess at the DAC divider
value (I forget what you call it, the value programmed at ports 0C6h and
0C7h), then refining the guess by actually recording for 8 timer ticks
at various dividers close to that one to get the divider that plays
closest to the rate the user requested. I then calculate the actual
sampling rate based on the number of samples recorded in that time with
that divider and adjust the .wav header accordingly. You can look at
program Recwav.pas in tspak17.zip to see what I mean (Recwav is in the
process of being completely rewritten in assembler, referring heavily to
your code, but the same principle applies).
> Of course, sounds sampled elsewhere or on the newer PSSJ chip could
> be played back at exactly the right speed, assuming "right" was one
> of the available speeds. Because of the cheapness of the hardware,
> 11,025, 22,050 and other common speeds were not the ones the hardware
> could actually deliver. The actual rates are listed in the source
> code somewhere, or can be computed by dividing 14.31818MHz (4x NTSC
> television color burst frequency) down by whole numbers and see what is
> available. Why was this strange value used? Cheap: color burst
> oscillators are one of the most common speeds made and as such are the
> least expensive available. A crystal running at a frequency that divides
> down into a "standard" sampling rate like 22,050 or 44,100 will cost more.
The standard sampling rates of 22050, 11025 and 5512.5 Hz originated
with the Mac, and the Mac is probably the only system guaranteed to play
them at the right speed. The SoundBlaster, for instance, is clocked at
1 MHz, and 1,000,000 divided by 11025 is 90.70294785. The Tandy DAC
actually gets closer to the true rate than the SB does, since it has
more detents.
> We didn't have hardware to do anything but linear PCM.
That is no major limitation. Converting 8-bit PCM to A-law or mu-law or
vice versa is just a table lookup, one XLAT instruction.
> [My stuff deleted.]
>
> Look around the source code in that immediate area for an edit tag. That
> is something that looks like <18>, or some other number. [...]
>
> Anyway, if you can find an edit tag near that code, go to the file
> with the edit history in it. Because I am upgrading the OS on my
> main server right now, all that code is not online so I can't take a
> quick look, but if I followed my standard convention, there should be
> a file like version.asm, .s or .src (or version.h for C code), and there
> should be a section with a line like
> Edit History EDIT HISTORY edit history
The edit history in the beta version, such as it is, is contained in
VERSION.ASM, and there is very little of it, less than a 25-line
screenful. It says little. I look forward to seeing the unedited
version.
BTW, the only error I found in the beta was in IRQ.ASM, at the beginning
of player_irq. You have (comments omitted):
player_irq proc far
push dx
push ax
push ds
mov ax,snddata
mov ds,ax
assume DS:snddata
cld
mov al,byte ptr snd_mode
test al,SHUTDOWN
jnz $ourirq
...
$ourirq:
and al,0e7h
out dx,al
If the SHUTDOWN bit is set, then when you get to $ourirq, neither AL nor
DX is set to a reasonable value, so you are writing a random value to a
random I/O port. (You probably saw this one already.)
I enjoyed your comments about Sound.pdm and agree regarding software
patents.
> (Comp.sys.tandy and alt.sources do not allow uuencoded binaries
> except as part of a package also containing source.)
Now that is a rule I know I've broken, since I posted Dmgif here without
source, during the period between when Musie closed and my site opened.
I've been hanging around comp.sys.tandy for several years, but I've
never seen the charter - might be nice to post it if you have it lying
around. (BTW, the source for Dmgif is available if anybody wants it,
but it's huge and it requires DeskMate libraries for compilation - I
said that at the time.)
> [...] People can
> print postscript even on plain DOS machines. I know, as when I prepared
> the documentation, the postscript printer was at work and I accessed
> it from a MS-DOS box.
Well, yes, if you have a Postscript printer. With the lp* utilities in
the NCSA Telnet package, you could print on a Postscript printer
attached to a mainframe over the Internet from a DOS box.
> [referring to the cat versions] Even
> the DOS MORE command copes with these files.
So does Vern Buerg's LIST utility. If you eliminate the overprinting,
it would be even better, since then text editors could use the files.
> [2]Well, I *did* get the PDST removed from Musie when you objected.
>
> Um, well, actually I wrote to the campus computer services administrator
> and he removed it, or at least that is what he wrote in his reply.
Hm, as I remember it, I wrote to Robert Stinnett saying it should be
removed from the site, and a few days later it was gone. I didn't know
that you had also written. Later, Robert gave me a telnet account on
the site and at that point I could have removed it myself, but at the
time I didn't have the telnet account.
Well, I won't pester you any more about putting the PDST on my site.
I'll just wait and link/refer to yours if you want to do it that way.
> [...] I've also got about 20,000 8 and
> 9 digit LED displays for calculators, [...]
Eek! :-0
Oh, while I've got your attention, what is "Letni"? I understand the
reference to Monty Python but miss the application to Intel.
Jeffrey Hayes <tv...@agate.net>
Frank Durda IV
[4]have to do it. And saying, "We'll record it at the wrong speed, then
[4]play it back at the wrong speed, and it will sound right, since the two
[4]errors will cancel out," doesn't cut it, either. What does my hapless
[4]user with a 1000SL do when he wants to record a sound and give it to his
[4]best friend who has a Mac?
You record it on a different platform or with the other PSSJ chip,
or you live with the frequency error, which is quite small and is only
obvious to the average person during certain types of music, such as
flute and violin solos.
[4]So what I'm doing is calculating an initial guess at the DAC divider
[4]value (I forget what you call it, the value programmed at ports 0C6h and
[4]0C7h), then refining the guess by actually recording for 8 timer ticks
[4]at various dividers close to that one to get the divider that plays
[4]closest to the rate the user requested. I then calculate the actual
Hate to say it, but this will not work. Been there, wasted time doing that.
The mix of instructions executed while you waited 8 timer ticks will
be different than what is going on the rest of the time, unless you
can guarantee that you are always executing the exact same opcode during
all sampling, like you are executing a HALT opcode (don't do this on
some 1000 systems - they will either turn off refresh or reboot).
Besides, during your clock ticks, you will have wow and flutter and
this will still be noticible. If you are speaking of the 18.2/sec (nominal)
system clock, even it doesn't occur on time, or reach your code on time.
The BIOS and DOS perform differing numbers of opcodes on each timer
tick since not all functions needed to be done on every tick. Therefore
the instruction mix remains variable and inconsistent.
The only way to avoid the sampling error is to use the newer PSSJ chip.
As to playback rate, you can't hit any of the standard speeds anyway
so your recordings will never be precisely 5,500, 11,025, 22,050, or 8,000.
This means that off-platform playback of these sounds will always be
off-pitch, unless you perform rate transformations on the audio, a
particularly compute intensive operation.
Somewhere in either the toolkit, or in an article I posted in the past
(my archive is offline right now) is the formulas that show you can't
get these speeds no matter what settings you give the hardware.
We even considered loading different divisors into the clock to create
an "average" of the desired frequency. This sounded awful, because the
hardware doesn't really have a good way to deal with people changing
the divisor while relying on its timing.
And C6 or C7 must be playback rates. The equivalent record values are
one-tenth of that.
[4]That is no major limitation. Converting 8-bit PCM to A-law or mu-law or
[4]vice versa is just a table lookup, one XLAT instruction.
But we couldn't afford it, not with all the other operations we had to
do and have it still work on a 1000SL. We already have to perform
centerline compensation and do range testing for silence elimination.
And it's more than one opcode, since you have to set up and tear down
some pointers and registers.
That code was hand-tweaked repeatedly to get the fastest possible speeds
on the set of processors it had to run on. The timings might even be
mentioned in the comments. Everything had to work on the SL, long after
it wasn't even made anymore. Only when we got up to the second RL did they
relax the requirement.
[3] (Comp.sys.tandy and alt.sources do not allow uuencoded binaries
[3] except as part of a package also containing source.)
[4]Now that is a rule I know I've broken, since I posted Dmgif here without
[4]source, during the period between when Musie closed and my site opened.
The problem is the cancelbots are being tightened and in my current
position I see that as a common cancel reason for material in comp.sys.tandy
and other "non-binary" groups. Nobody really asked in the group if
this service was desired, but it did say in the charter that big binaries
are out. I do know that at least two articles in comp.sys.tandy
have been canceled in the past six days because of binary content.
The only reason I know that is I am doing a study on the effects of
disregarding cancels completely and am analyzing each cancel that
comes to a given system (8,700 in the first 24 hours). So the issue is
a valid one.
[4]I've been hanging around comp.sys.tandy for several years, but I've
[4]never seen the charter - might be nice to post it if you have it lying
[4]around.
If it isn't in the news.groups archives, I'll see what I can do. It's
real old, dating back to the net.* days. I may have to go back to 6000
floppies for this one.
[4]Oh, while I've got your attention, what is "Letni"? I understand the
[4]reference to Monty Python but miss the application to Intel.
You said it! That is the word the Knights who say Letni cannot hear! :-)
Think of backwards things. Non-orthangonal instruction sets, byte-swapped
data word orders, just generaly weird. If that doesn't work, read
"LETNi" backwards!
I thought of that in 1984 when I was dumped on the Model 2000 project
and taken to that dark world of segments, vast kludges and Intel
promises. Yuck.
Don't feel bad about not getting it. Employees of Intel told me the script
I posted back then was stuck up on cubicle walls at Intel for months and it
just went right over managements heads.
Frank Durda IV <uhc...@nemesis.lonestar.org>|"Knights who say Letni, we have
or uhclem%nem...@rwsystr.nkn.net | brought you a segment register."
|"It is a good one; I like the
or ...letni!rwsys!nemesis!uhclem | upper bits particularly." :-)
(Somewhere the complete script lies)
gram
Frank Durda IV (uhc...@nemesis.lonestar.org) wrote:
:
: I thought of that in 1984 when I was dumped on the Model 2000 project
: and taken to that dark world of segments, vast kludges and Intel
: promises. Yuck.
Yeah, but it sure had a nice keyboard. Once Softerm was available,
it was the best terminal for a Xenix system you could imagine. I
used them for most of my Xenix Ops classes at the L.A. RSCC. (The
DT-100, when it finally arrived was OK, but the DT-1 sucked from
day one with its magic cookie attribute change). The T2000 I got
on closeout in '87 was a good terminal to my Mod 16's and to my 3B1
for many years, and a decent serial/parallel converter with 512k
print buffer for those and the rest of the collection. Pity I lost
it when I had to move, though the TL/2 does OK as a print buffer.
Not that I need one much, but it does help the Mod 4 and CoCo get
along with the MX-80.
Always wanted to try porting the TRSDOS6 source to the T2000. Far
superior to the DOS from Bill's evil empire. Never became enough of
a programmer to carry it through, having concentrated on Unix and
such ever since. (BTW, a couple of the Mod I/3/4 and Color Computer
emulators work just peachy [except for disk i/o, which I'm working
on] under the DOSEMU package for Linux. Now if I can find a copy of
the old HP programmable calculator emulator that ran on the Mod I,
for another layer of abstraction...) i
(here he is, boys. bring up the thorazine real quiet.)
Ward Griffiths
Frank Durda IV
[5]Frank Durda IV (uhc...@nemesis.lonestar.org) wrote:
[5]
[5]I thought of that in 1984 when I was dumped on the Model 2000 project
[5]and taken to that dark world of segments, vast kludges and Intel
[5]promises. Yuck.
[6]gram (gr...@cnct.com) wrote:
[6]Yeah, but it sure had a nice keyboard. Once Softerm was available,
Actually designed not by hardware engineers or PC clone makers, but
by the software developers of Scripsit. Then it was compressed horizontally
by the industrial engineers so that the keyboard could slide under the front
of the 2000, which they thought was more important. This is where the PRINT
and other keys were suddenly "too close" to the BACKSPACE button, and the
BACKSPACE button got smaller. Oh well, apart from that, it was a nice
keyboard, and far ahead of IBM, until they copied the Fn key layout some
years later on their PS/2 systems.
...
[6]on closeout in '87 was a good terminal to my Mod 16's and to my 3B1
[6]for many years, and a decent serial/parallel converter with 512k
Did you know the 2000 keyboard works on the Model 16/6000 under XENIX?
Once this was possible, all the junk 2000 keyboards around the office
vanished and became the keyboard people used on their Model 16/6000.
It just takes a change in the pin-out, and we slipped the instructions
into the XENIX release.
Leonard Erickson
"Jeffrey L. Hayes" <tv...@tvdog.sdi.agate.net> writes:
> Frank Durda IV wrote:
>>
>> I actually have four total (I believe only five were made, so I should have
>> said 80%), one has some distortion problems and only one was ever
> retrofitted
>> to handle the newer PSSJ chip. I'm afraid I won't be selling it for
>> various reasons.
>
> Jeez, 5? In the whole world? I really didn't need to change all my
> programs to make them compatible, if that's the case ....
Remember, that's 5 cards for developers. There are probably a million
or more Tandy 1000 systems with the equivalent hardware *built-in*. :-)
Jeffrey L. Hayes
> >>
> >> I actually have four total (I believe only five were made, so I should have
> >> said 80%), one has some distortion problems and only one was ever
> > retrofitted
> >> to handle the newer PSSJ chip. I'm afraid I won't be selling it for
> >> various reasons.
> >
> > Jeez, 5? In the whole world? I really didn't need to change all my
> > programs to make them compatible, if that's the case ....
>
> or more Tandy 1000 systems with the equivalent hardware *built-in*. :-)
My programs were already designed to work with the 1000's and 2500's
that have the sound chip built in. The PSSJ card that Frank is talking
about, though, uses a different I/O port address, so I rewrote
everything to take that 3rd possible port address into account. Oh well
... water under the bridge - the programs in Tspak should support the
PSSJ cards - all 5 of them ... except for the one that's broken ... :-/
jlh <tv...@agate.net>
Tandy 1000-series FAQ:
ftp://ftp.agate.net/users/01935/tandy1000/documents/1kfaq118.txt
http://www.agate.net/~tvdog/1kfaq118.html
Frank Durda IV
Jeffrey L. Hayes wrote:
> My programs were already designed to work with the 1000's and 2500's
> that have the sound chip built in. The PSSJ card that Frank is talking
> about, though, uses a different I/O port address, so I rewrote
> everything to take that 3rd possible port address into account. Oh well
> ... water under the bridge - the programs in Tspak should support the
> PSSJ cards - all 5 of them ... except for the one that's broken ... :-/
You should always use the address returned by the BIOS and not hard-code
the location. I am aware that the PSSJ chip was recently licensed
by a third firm to use in an upcoming project. What I/O address
will they use? Dunno, but if they set the BIOS up right, you code
won't have to change to support this new platform.
Oh, and I have been told that there may be more of the plug-in cards
than the five I know of. Seems some unknown number of vendors
received boards for development work from a second build. Disney
apparently got a couple.