Sound bits

[deathshadow60]

Certain PIO disk devices, software controlled refreshes and polling on non-DMA computers (Jr/1k) -- they can often crash if you don't call it soon enough/often enough or spread out enough.

For my uses usually adding that much logic to my ISR doesn't help a whole lot either -- doesn't leave enough CPU free to do anything else. It's called load balancing -- you spread it out instead of blowing it all out in one slice... Which is usually why timers are used in the first place.

See why multitasking time slicing is pretty much how every modern OS handles it.

[Trixter]

Certain PIO disk devices, software controlled refreshes and polling on non-DMA computers (Jr/1k) -- they can often crash if you don't call it soon enough/often enough or spread out enough.

Good point, and something to watch out for.

you spread it out instead of blowing it all out in one slice... Which is usually why timers are used in the first place.
See why multitasking time slicing is pretty much how every modern OS handles it.

Were I writing an OS that has to manage multiple timeslices of unknown duration, I would agree, but DOS programs have access to the entire machine when they're running and the author of a program knows beforehand how long each timeslice takes. On fast machines, the overhead is negligible, but for machines as slow as the ones we work with, interrupt service overhead is substantial.

For a program that, for example, must update the screen at an interval of 30Hz, there is no difference between a 30Hz timer that "blows it all out in once slice", and one that uses a 240Hz timer and spaces calcs out, updating the screen once every 8 ticks. In fact, I'd argue that the latter method is less efficient, because calcs in one timeslice that finish early waste time that cannot be used by calcs in other timeslices (or worse, one timeslice will get interrupted by another).

[KenG]

I know this is a very old thread, but I found it and now have sound in Battlechess. I did discover one thing in testing it. Once I typed tsound s to re activate the speaker, typing tsound kept giving the message "Speaker sound activated". I thought about this while taking a shower. Typing anything except s will turn Tandy sound back on.

[Vorticon]

I know this is a very old thread, but I found it and now have sound in Battlechess. I did discover one thing in testing it. Once I typed tsound s to re activate the speaker, typing tsound kept giving the message "Speaker sound activated". I thought about this while taking a shower. Typing anything except s will turn Tandy sound back on.

Yeah Here's the listing of the program (Turbo Pascal) and you can clearly see in the bolded section that this would indeed be the case. Minor bug, but still works fine.

PROGRAM TSOUND(INPUT);
VAR ANS:CHAR;
BEGIN
IF ParamCount>0 THEN
ANS:=ParamStr(1)
ELSE
ANS:='T';
WRITELN;
IF (ANS='S') OR (ANS='s') THEN
BEGIN
PORT[97]:=13;
WRITE('SPEAKER NOW ACTIVE...');
END
ELSE
BEGIN
PORT[97]:=125;
WRITE('TANDY SOUND NOW ACTIVE...');
END;
WRITELN;
END.

[bagelswitch]

Resurrecting a very old thread here, but I found it desireable to enable the TI sound source for software that doesn't enable it via port 61, while also leaving the PC speaker active - this allows games, for example the 8-bit guy's recent game Planet X3, to play "Tandy" music while producing sound effects via the PC speaker. I wrote the attached to do this, and it seems to work fine. All it does is ensure bits 5 and 6 on port 61 are set to 1:

Code: Select all

in al,61
or al,60
out 61,al
int 20


. . . following the suggestion on page 25, here: http://iama.stupid.cow.org/OldComputerMagazines/jrNewsletter/1989s/September%20October%201989(s).pdf

[Trixter]

We're setting up a repo for PX3 code; if this happens, I'll contribute this to the codebase. Thanks!

[JudgeMonroe]

This has been an interesting thread. I have used this "turn on the sound chip" project as my Hello World in x86 assembly.

Code: Select all

section .text
org 0x100
   in AL, 0x61     ;read port to AL
   xor AL, 0x60   ;toggle bits 5,6
   out 0x61, AL   ;write AL to port
   int 0x20          ;terminate


Every time you execute, the sound is toggled. I have a more verbose version that writes to the terminal, but that's 51 bytes instead of 8.

I was going to use MASM for this but it's too fiddly. For simple COM files, NASM was fast and easy. I actually used debug to get it into the jr.