VOGONS


SBVGM (DOS) VGM Player

Topic actions

Reply 80 of 530, by OPLx

User metadata
Rank Member
Rank
Member
Scali wrote:
OPLx wrote:

Some tests I did last week on the OPL3 worked out and I need to do some other tests on the OPL2, then figure out how to interpret the SN76489 noise channel on the OPL2 & OPL3.

How about simulating the noise channel digitally? There's source code available from SN76489 emulators (such as DOSBox). You could just simulate the noise bit-for-bit using the routine from an emulator, and then then find a way to replay the noise 'samples'? Either via the DAC of an SB, or using the trick to play samples on the OPL2/3?

That's an interesting way to add in support for noise playback; I never crossed my mind. I will have to look into possibly taking that approach. The OPL2/3 do have a noise generator built-in and it can be accessed by setting the chip to percussive mode and sending information to the operators that normally control channels 8 and 9 in melodic mode. SBVGM supports reinterprets SN76489 commands on the SAA1099 and if the noise generator on OPL2/3 sound similar to that of the SAA1099, it may be sufficient. I had always wondered how to access the noise generator on the OPL2/3 and stumbled across how to do so when I was fixing some old bugs in the ROL player I did for Adplug. It turns out it is "kind of" documented in the YM2413 and YM3812 application manuals, but it's a very short mention.

Reply 81 of 530, by ElBrunzy

User metadata
Rank Oldbie
Rank
Oldbie

elz -"I cannot tell the original soundtrack from this player hardware saa1099! on to the original sega master system music played"

yes there was a message ... so I did wrote : set blaster=a220 i7 d1 t1 and pressed return .. then your player could play vgz music with compatible vgz rip.

In the meantime field where burning ... and while the hill ondulated ... I did try -c to force to use the dual stereo saa1099 chips I just installed. of course the experience was incredible ...

just incredible ! I'm astouned ! I feel like I have a sega master system under my thumb.

I wanted to do a video to express how awesome it feel to use your player on ms-dos with a sb1.5 downgraded cms saa1099 but now I'm drunk too many, see ya soon !!! I bought an digital receiver to make sure I get the most of your player.

Reply 83 of 530, by OPLx

User metadata
Rank Member
Rank
Member
ElBrunzy wrote:

today I see how the japanese sms was superior to the american one... today I see thru the sound generator chip!

I'm very glad that you the program allowed you to listen to your favorite game music and am looking forward to the video. 😀
By the way, does the program still crash?

Reply 84 of 530, by ElBrunzy

User metadata
Rank Oldbie
Rank
Oldbie

I'm very glad that you the program allowed you to listen to your favorite game music and am looking forward to the video. 😀
By the way, does the program still crash?

I'm in the search of interesting idea for the video, please give me tough I would be most happy to realise them. I will re-read the whole thread, but I have no idea about that crash, i'll see what I can see.

Now that I have fm1312 and saa1099 on that sb1.5, let's talk about the real stuff:

first thing first : if I do "sbvgm -h music.vgm" it display help, but if I do "sbvgm music.vgm -h" it does not. BUT ! if I do "sbvgm -c music.vgm" it complains -c is not a file, but if I do "sbvgm music.vgm -c" it does play with the saa1099, can you see the problem I'm getting at ? that's simple command prompt parsing, my guess is you can fix that in a jeffey, but it's quite confusing for the end user.

also : I'm quite amazed how good your player work with hardware sega rip dump. Can I ask you about how you did you timing ? I'm using a p1-233 and it's all perfect

Reply 85 of 530, by OPLx

User metadata
Rank Member
Rank
Member
ElBrunzy wrote:
I'm in the search of interesting idea for the video, please give me tough I would be most happy to realise them. I will re-read […]
Show full quote

I'm in the search of interesting idea for the video, please give me tough I would be most happy to realise them. I will re-read the whole thread, but I have no idea about that crash, i'll see what I can see.

Now that I have fm1312 and saa1099 on that sb1.5, let's talk about the real stuff:

first thing first : if I do "sbvgm -h music.vgm" it display help, but if I do "sbvgm music.vgm -h" it does not. BUT ! if I do "sbvgm -c music.vgm" it complains -c is not a file, but if I do "sbvgm music.vgm -c" it does play with the saa1099, can you see the problem I'm getting at ? that's simple command prompt parsing, my guess is you can fix that in a jeffey, but it's quite confusing for the end user.

also : I'm quite amazed how good your player work with hardware sega rip dump. Can I ask you about how you did you timing ? I'm using a p1-233 and it's all perfect

Ideas for a video? What did you have in mind? 😀 Thank you also for the suggestions. I will look into implementing them soon; that does make a lot more sense. Currently the program expects the filename to be the first parameter, but I'll look into making it a bit more flexible.

About the timing...VGM data is set for playback at 44,100Hz. Since this rate is too high with the PC interrupt 8 timer, it is set to 180Hz playback. 44100Hz divided by 180Hz yields 245, so on each tick (from the 180Hz clock) the VGM playback routine is called 245 times. The approach works for most cases (even on a slow 4.77MHz PC) as many VGMs were recorded from games with 60Hz update rates, but there are some cases where this approach does not work well such as some of the OPL3 VGMs at the OPL Archive. Some of the Adlib Tracker songs playback at a rate of 300Hz (sometimes higher) and naturally the approach the program uses above will inadvertently drop frames from the VGM playback.

It is possible to set the interrupt timer to playback at about 1,000Hz, but there are other issues that show up in terms of how often the interrupt gets called and of course playback on actual hardware. One of the nice things about the SAA1099 chips are that there are no waits between register writes, but the OPL2 and OPL3 require waiting a certain amount of time (in microseconds) between address and data writes. I think the timings in the VGM data takes this into account, but I am not 100% sure. At a 44,100Hz capture those waits would only show up as a wait time of zero or at worst one VGM frame.

A while back I tried an experiment where the VGM was updated as fast at the CPU could go, but would wait with the VGM command specified a delay running the interrupt timer at 1,000Hz with a counter to act as a reference for when the VGM commands should be processed. It kind of worked, but the timing was a bit off at 4.77MHz. Again the time waiting between the OPL2 address and data writes seemed to throw things a bit off. I don't have an actual 4.77MHz PC to test on (I used DOSBox 0.74 for development), so sometimes the results are different from actual hardware (at least on my Pentium 3/450MHz machine) and that's when I have to go back and make it work for actual hardware.

Overall though, that's how the program handles the timing. One caveat about VGM format is that a program that plays back such files seems to have to handle all the commands since certain commands advance the data at different sizes; there's no way to know in advance how many bytes to skip. The whole program is written in C (I don't have enough free time to write and debug in assembler), so I am sure there are places that could be optimized.

The original goal of the program was simply to test out some things with the SAA1099 chips. The NES VGMs really show off some of the SAA1099 abilities ... though (at present) the program does not handle the NES APU's DPCM channel nor simulate duty cycles for the two square wave channels.

Reply 86 of 530, by Scali

User metadata
Rank l33t
Rank
l33t

Instead of using timer interrupts, wouldn't it be better to just poll the timer? That's an approach I've tried for sample playing (the 61h command).
It takes all CPU, but it should be the most accurate way to play back such files.
Also, you should be able to run the timer interrupt at much more than just 1000 Hz, even on a 4.77 MHz machine.

Do you do any preprocessing? Because if you were to convert the file to OPLx-like commands at startup, then the playback routine would only have to write those commands directly, no extra processing required in the timed code.
Basically how you would play back VGMs natively.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 87 of 530, by OPLx

User metadata
Rank Member
Rank
Member

Thanks for the suggestions! I hadn't considered polling; just don't use it much primarily out of habit. Since nothing else is really going on it probably won't be much of an issue CPU-wise unless the program is being run in a DOS window under Windows9x or something.

The program currently does no pre-processing on the data. I didn't implement it simply because at the time I initially wrote the program, there was no OPLx support, but that eventually got added in; he SAA1099 VGMs and NES VGMs were pretty light on CPU-usage. Since there is XMS support in the player, it could do some form of pre-processing, but I guess if there's not enough memory then it could just play the VGMs as it does at the moment. The pre-processing could also be done offline, then the player updated to support those pre-processed VGMs ... This might actually be the better approach as there would be no need for the program to have to deal with running out of memory in low-memory situations.

In truth the biggest issue I have right now is just time. 😢 Hopefully, sometime soon I will have a chance to focus on the program a bit more. I really do appreciate your comments and suggestions! 😀

Reply 88 of 530, by ElBrunzy

User metadata
Rank Oldbie
Rank
Oldbie

I visited your OPL Archive, it's great, I look forward to build a solid vgm collection of sega music and sure your demoscene collection will be a much welcome addition.

Thanks about the detail of how you do your timers. I wasnt expecting that much, it's always appreciated your explanations, I feel honered that you take the time to explain me how you did your player. Hopefully some day you will release the source code. About timing, did you knew that adlib always had to re-release them specs of the card as computer went faster ? check the Jason Linhart part http://www.oldskool.org/guides/oldonnew/sound.

About the video, I dont know exactly yet. I'm thinking about a selection of music from the sega master system, and put some picture or small animation while it's playing. Like I would try to do reference of modern thing about old video game. Funny or distracting, I have some idea in mind, like you would walk on a village but it's a close of a soundblaster 1.5, you would encounter someone on a video game but it's a friend who told you obvious thing about modern computer, there is some picture of my dog looking like a foe... you know, a random pot pourrie of whatever stuff... so any idea is welcome really.

Reply 89 of 530, by OPLx

User metadata
Rank Member
Rank
Member

The OPL Archive isn't my creation. MrKsoft kindly pointed me to his work a few messages earlier in this thread. Here is the message itself. It was from the VGMs that MrKsoft made that I found out that there are some timing issues with the player. I had primarily used VGMs from the VGMRips site to test things out.

It was no problem sharing the information about how I did the timers. The method I explained (using interrupts) is one way to approach handling timing and many programs from the "retro" era used the same or similar method. The method that Scali kindly mentioned seems feasible so I just need to find a chance to implement it. I am still intending to release the source at some point though!

I wasn't aware that Adlib had originally suggested not having any delays between address and data writes for the OPL2 chip. The OPL2 data sheet mentions that those waits are required so my guess is that originally things were so slow that it didn't seem necessary. Oddly enough the wait times were reduced on the OPL3, but from some of my experiments it seems that it depends on how the sound card model or type implemented circuitry. I think the OPL3 data sheet is pretty accurate though.

I'm not sure if I've any good ideas for videos, but perhaps something like a "history of" with footage of the game and some interesting facts. One thing to watch out for is that if you use the SAA1099 for playback you may get some comments about the noise channel not sounding accurate to the SN76489 variant used in the Master System. 😊 This thread The Tandy 1000 ISA sound card brainstorm thread talks about an ISA card that uses the SN76489. It seems sold out at the moment though. I will likely add support for the card (add options to select port that it is at) at some point later.

Reply 90 of 530, by Scali

User metadata
Rank l33t
Rank
l33t
OPLx wrote:

This thread The Tandy 1000 ISA sound card brainstorm thread talks about an ISA card that uses the SN76489. It seems sold out at the moment though. I will likely add support for the card (add options to select port that it is at) at some point later.

I have one of these cards (installed in my IBM 5160: https://youtu.be/m_pCHSqQmKs https://youtu.be/lDJXIziW06c). Also, I have my own simple VGM player for SN76489 only.
I can help out if you want to add support. I suggest you add support for (re)programming the PCjr/Tandy multiplexer as well, which means it will work on PCjr and Tandy as well as this card (the SN76489 is muted by default on these machines, and you need to switch the output from PC speaker to SN76489 to hear it).
It's just a few simple commands, my player already implements it. So I can give you the code for that (I copied it from Trixter's VGM player written in Pascal).

Also, regarding OPL2-timings... Technically VGMs should just be 'recordings' of the data sent to the soundchip's registers (with timestamps for each command sent), eg using an emulator. Which theoretically means that the delays are already in the VGM data, because they would be in the software that sends the commands.
So in theory, a VGM player wouldn't need to implement any delays itself, assuming it replays the data with about the same accuracy as the recorded data.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 91 of 530, by OPLx

User metadata
Rank Member
Rank
Member
Scali wrote:

I have one of these cards (installed in my IBM 5160: https://youtu.be/m_pCHSqQmKs https://youtu.be/lDJXIziW06c). Also, I have my own simple VGM player for SN76489 only.
I can help out if you want to add support. I suggest you add support for (re)programming the PCjr/Tandy multiplexer as well, which means it will work on PCjr and Tandy as well as this card (the SN76489 is muted by default on these machines, and you need to switch the output from PC speaker to SN76489 to hear it).
It's just a few simple commands, my player already implements it. So I can give you the code for that (I copied it from Trixter's VGM player written in Pascal).

I really want to eventually get one of those. That is so cool! The program does presently support SN76489 playback on the Tandy 1000, PCJr, and IBM PS/1 Audio. I didn't have any of those machines to test on, but I do know of individuals who have ran it on the Tandy 1000. The other two machines were tested under DOSBox. I don't recall having to fiddle with the multiplexer and detected the hardware on the Tandy and PCJr via BIOS. I'm wondering how the program was able to produce sound without activating the chip via the multiplexer. Is this just for certain Tandy and PCJr models? If you don't mind, I could definitely use the code that enables/disables it; the more the program works reliably the better. The Tandy ISA card made me also realize that I need to rethink how the hardware detection and set up work. I think these days just telling the program that such and such chip is at port X is probably better for the future ...

Scali wrote:

Also, regarding OPL2-timings... Technically VGMs should just be 'recordings' of the data sent to the soundchip's registers (with timestamps for each command sent), eg using an emulator. Which theoretically means that the delays are already in the VGM data, because they would be in the software that sends the commands.
So in theory, a VGM player wouldn't need to implement any delays itself, assuming it replays the data with about the same accuracy as the recorded data.

Ah yes ... this is the great mystery of the VGM format (at least for myself). I had thought that myself until I looked at the actual command data and realized that (for whatever reasons) those delay commands may or may not be there in the data (mostly not there). Here's an excerpt from 01 Asteroid Dance Part 2 using vgm2txt:

0x00000338: 5A 89 F3    YM3812:		Ch 4 Op 0 Sustain Level: F, Release Rate: 3
0x0000033B: 5A 2C 01 YM3812: Ch 4 Op 1 AM: Off, Vibrato: Off, KSR: Off, EG Type: 0, Freq Multipler: 1
0x0000033E: 5A 4C 0F YM3812: Ch 4 Op 1 Key Scaling: 0, Total Level: 0x0F = 27%
0x00000341: 5A 6C F0 YM3812: Ch 4 Op 1 Attack Rate: F, Decay Rate: 0
0x00000344: 61 2C 00 Wait: 44 samples ( 1.00 ms) (total 8423 (00:00.19))
0x00000347: 5A 8C F4 YM3812: Ch 4 Op 1 Sustain Level: F, Release Rate: 4
0x0000034A: 5A EC 03 YM3812: Ch 4 Op 1 Waveform Select: 3
0x0000034D: 5A C4 0E YM3812: Ch 4 Algorithm: FM, Feedback 7
0x00000350: 5A A4 71 YM3812: Ch 4 F-Num LSB = 71
0x00000353: 5A B4 31 YM3812: Ch 4 F-Num MSB = 1, Octave 4, Key On
0x00000356: 5A A0 E1 YM3812: Ch 0 F-Num LSB = E1
0x00000359: 5A A1 A6 YM3812: Ch 1 F-Num LSB = A6
0x0000035C: 5A A2 7B YM3812: Ch 2 F-Num LSB = 7B
0x0000035F: 5A A3 D4 YM3812: Ch 3 F-Num LSB = D4
0x00000362: 5A A4 72 YM3812: Ch 4 F-Num LSB = 72
0x00000365: 5A A6 81 YM3812: Ch 6 F-Num LSB = 81
0x00000368: 61 6A 02 Wait: 618 samples ( 14.01 ms) (total 9041 (00:00.20))
0x0000036B: 5A 2A 41 YM3812: Ch 5 Op 0 AM: Off, Vibrato: On, KSR: Off, EG Type: 0, Freq Multipler: 1
0x0000036E: 5A 4A 17 YM3812: Ch 5 Op 0 Key Scaling: 0, Total Level: 0x17 = 14%
0x00000371: 5A 6A F3 YM3812: Ch 5 Op 0 Attack Rate: F, Decay Rate: 3
0x00000374: 5A 8A F3 YM3812: Ch 5 Op 0 Sustain Level: F, Release Rate: 3

Going by what the YM3812 data sheet specifies, I would have expected there to be waits between the different address and data writes, but they're not there. I am guessing that part of what may have contributed to this is that most of the time playback is occurring using an emulator. I suppose they're not cycle accurate? When I had done the initial testing under DOSBox (without the delays), everything worked ... until I tried it on actual hardware ... to my dismay. The VGM Specification was what I used as a reference ... perhaps the program is just interpreting the data incorrectly?

Reply 92 of 530, by Scali

User metadata
Rank l33t
Rank
l33t
OPLx wrote:

The program does presently support SN76489 playback on the Tandy 1000, PCJr, and IBM PS/1 Audio.

Ah, cool. I downloaded it, and looked at the readme, but it didn't mention this support, so I never tried it.
I'll have to see what it does on my machine.

OPLx wrote:

I'm wondering how the program was able to produce sound without activating the chip via the multiplexer. Is this just for certain Tandy and PCJr models?

I'm not sure if Tandy needs this as well, but from what I understood, at least PCjr needs it (I don't have a PCjr myself, so I can only go by what others tell me). Also, I'm not sure if this affects only the line-out, or also the built-in speaker. So you may not need it in all cases.

The code I got is this:

#define SNMplxr 0x61	// MC14529b sound multiplexor chip in the PCjr

void InitPCjrAudio(void)
{
uint8_t mplx;

mplx = inp(SNMplxr);
mplx |= 0x60; // set bits 6 and 5 to route SN audio through multiplexor
outp(SNMplxr, mplx);
}

void ClosePCjrAudio(void)
{
uint8_t chan, mplx;

// Mute channels
for (chan = 0; chan < 4; chan++)
SetPCjrAudioVolume(chan,15);

// Reset the multiplexor
mplx = inp(SNMplxr);
mplx &= 0x9C; // clear 6 and 5 to route PC speaker through multiplexor; 1 and 0 turn off timer signal
outp(SNMplxr, mplx);
}

As you may or may not know, the SN76489 doesn't have any kind of ADSR envelope, so notes just sound forever. Which is why you want to set the volume to 0 (and it's inverted in the commands, so value 15 is silent, 0 is loudest). So aside from just switching back to PC speaker, I also mute the chip (the BIOS in the PCjr and Tandy does this at bootup as well). Otherwise, it will just produce a random tone forever.

OPLx wrote:

The Tandy ISA card made me also realize that I need to rethink how the hardware detection and set up work. I think these days just telling the program that such and such chip is at port X is probably better for the future ...

Auto-detecting is fine, but having a way to manually override the settings is also important. There isn't really a way to detect the Tandy clone card. The chip is write-only, so you can't query it for any kind of status. And it could be installed in any kind of machine, so BIOS detection is also impossible.
Also, the chip could be at various addresses. C0h is the original PCjr address, but that clashes with the second DMA controller in any AT-class or better machine. Tandy moved their chip to 1E0h in later machines for that reason. And since that is a reserved area, we also have 2C0h as a 'safe' address.
The PS/1 has it at 205h. So I guess having a commandline switch to play at an arbitrary port is the best option. That's what my player currently has.

OPLx wrote:

Going by what the YM3812 data sheet specifies, I would have expected there to be waits between the different address and data writes, but they're not there. I am guessing that part of what may have contributed to this is that most of the time playback is occurring using an emulator. I suppose they're not cycle accurate? When I had done the initial testing under DOSBox (without the delays), everything worked ... until I tried it on actual hardware ... to my dismay. The VGM Specification was what I used as a reference ... perhaps the program is just interpreting the data incorrectly?

Yes, I suppose it could be that the emulator is not accurate enough. It could also be that the VGM recorder performs some quantizing, so that you get more compact files, assuming that the replayer will insert delays between successive OPL-commands anyway.
I guess the safe way then is to just insert these delays yourself in the replayer. I guess you could do that the 'official' way with the sequence of in dx, al commands. You could make a simple optimization to only perform the delay when you know that there's another OPL-command directly after it.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 93 of 530, by OPLx

User metadata
Rank Member
Rank
Member

Thank you for the code; I will incorporate it into the next release! When I wrote the SN76489 emulation for the SAA1099 I thought it was a bit odd for the volumes to be inverted ... but the OPLx chips' volume levels are inverted as well. What I really thought was a nice feature of the chip was the "periodic noise". So far from what I found there doesn't seem to be too many VGMs generated from DOS games that use the feature.

I will definitely add in manual overrides for all supported chipsets in the next release; I must have had tunnel vision when I was implementing things at the beginning. The "delay on access" optimization you mentioned seems to be one good approach to reducing the delay times. There was one silly experiment I had considered by having a callback function in place of the delays and do some simple housekeeping work that the player would normally have to do anyway ... but I never bothered to try it out when I realized that there was a chance that (depending on what's going on) things could slow down or the approach would fail on a faster processor.

Reply 94 of 530, by Jepael

User metadata
Rank Oldbie
Rank
Oldbie

Most "register dump" formats like VGM, DRO, IMF and RAW only tell what data to write to which register without the delays needed to access hardware, the delays are only for things like tempo (like in a MOD player to play a row of tracked notes from a timer/vblank interrupt).

So yes, you do need to implement OPL register write delays in your VGM player.

For OPL2, that's 12 cycle delay after index port write, and 84 cycle delay after data port write. One cycle is a tick of 3579545 Hz clock.
For OPL3, that's 32 cycle delay after index port write, and 32 cycle delay after data port write. One cycle is a tick of 14318180 Hz clock.

Reply 95 of 530, by OPLx

User metadata
Rank Member
Rank
Member
Jepael wrote:
Most "register dump" formats like VGM, DRO, IMF and RAW only tell what data to write to which register without the delays needed […]
Show full quote

Most "register dump" formats like VGM, DRO, IMF and RAW only tell what data to write to which register without the delays needed to access hardware, the delays are only for things like tempo (like in a MOD player to play a row of tracked notes from a timer/vblank interrupt).

So yes, you do need to implement OPL register write delays in your VGM player.

For OPL2, that's 12 cycle delay after index port write, and 84 cycle delay after data port write. One cycle is a tick of 3579545 Hz clock.
For OPL3, that's 32 cycle delay after index port write, and 32 cycle delay after data port write. One cycle is a tick of 14318180 Hz clock.

Thank you for the clarification. Though SBVGM does the appropriate write delays, I couldn't find any information from the VGM spec that explicitly mentions this requirement.

Reply 96 of 530, by Scali

User metadata
Rank l33t
Rank
l33t
Jepael wrote:

Most "register dump" formats like VGM, DRO, IMF and RAW only tell what data to write to which register without the delays needed to access hardware, the delays are only for things like tempo (like in a MOD player to play a row of tracked notes from a timer/vblank interrupt).

That only works if the VGM is generated directly from a tracker though.
My impression is that VGM was originally designed to capture register writes from an emulator (which explains why it has no song structure, which it would have if it was MOD-based). And the emulator has no idea about rows of tracked notes. The only thing is that you can 'quantize' it, because you can assume that most music routines will be synced to the framerate.
I have seen tools like vgm_cmp, which 'compress' VGMs by quantizing it. I assume such tools would remove small delays from OPL commands even if they were originally captured properly.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 97 of 530, by OPLx

User metadata
Rank Member
Rank
Member
ElBrunzy wrote:

Now that I have fm1312 and saa1099 on that sb1.5, let's talk about the real stuff:

first thing first : if I do "sbvgm -h music.vgm" it display help, but if I do "sbvgm music.vgm -h" it does not. BUT ! if I do "sbvgm -c music.vgm" it complains -c is not a file, but if I do "sbvgm music.vgm -c" it does play with the saa1099, can you see the problem I'm getting at ? that's simple command prompt parsing, my guess is you can fix that in a jeffey, but it's quite confusing for the end user.

v1.09 is released here with better command line support (the options are specified first now) and it also incorporates Scali's code for enabling/disabling the SN74689 output on IBM PCJr.

Reply 98 of 530, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

The safer way to manipulate the PCjr's (and early Tandy 1000's) Audio Multiplexer is Int1A AH=80 AL=Audio source (0=PC speaker, 1=Cassette, 2=I/O channel "Audio In", 3=SN76496). The reason that manipulating port 0x61 directly is bad is that on the Tandy 1000 TX and TL, which don't need the activation via multiplexer, the relevant bits of port 0x61 control the keyboard clock line, which you should not mess around with unneccessarily. This means that several games that mess around with it directly will freeze the keyboard on those machines if an IBM Enhanced Keyboard rather than the Tandy 1000 keyboard is attached, which these machines support. As these machines do not need the TI chip to be enabled that way, their BIOSes simply ignore said Int1A call. And since the early Tandy 1000 needs the activation, you cannot go by simply by only doing this for PCjr.

Reply 99 of 530, by OPLx

User metadata
Rank Member
Rank
Member
NewRisingSun wrote:

The safer way to manipulate the PCjr's (and early Tandy 1000's) Audio Multiplexer is Int1A AH=80 AL=Audio source (0=PC speaker, 1=Cassette, 2=I/O channel "Audio In", 3=SN76496). The reason that manipulating port 0x61 directly is bad is that on the Tandy 1000 TX and TL, which don't need the activation via multiplexer, the relevant bits of port 0x61 control the keyboard clock line, which you should not mess around with unneccessarily. This means that several games that mess around with it directly will freeze the keyboard on those machines if an IBM Enhanced Keyboard rather than the Tandy 1000 keyboard is attached, which these machines support. As these machines do not need the TI chip to be enabled that way, their BIOSes simply ignore said Int1A call. And since the early Tandy 1000 needs the activation, you cannot go by simply by only doing this for PCjr.

Oh dear, I didn't realize this. Thank you for the information. I don't have an actual PCJr to test with, so I just rely on DOSBox's behavior. I've removed v1.09 and now use the BIOS call instead for the PCJr and the Tandy line of machines in v1.10. Thank you again for pointing this out.