Highspeed SIO patch V1.10 released

[analmux]

Well, if the sawtooth is being approximated in software using a Fourier series, it depends on how many coefficients are being used, I guess.

 

Sawtooth has quite a lot of 'harmonics', which don't fall-off that rapidly as f.e. triangle waveform.

 

Fourier series isn't needed though, and isn't used. PWM is just a windowed integrating effect, for computing averages (or weighted averages, by using a 'mollifyer' or 'weight-function). The integration is of course always approximated by a summation over certain 'samples'.

 

If I'm correct, the recent pokey emulation uses this relatively simple PWM for the sawtooth, and alike effects. I wonder how much of these samples are needed for a PWM effect which sounds good enough.

 

It isn't good to generate a large spectrum of sounds by logic operators, and some other sounds by a totally different method, like using a Fourier series.

[HiassofT]

Hi Ijor!

 

Nice work!

Thanks!

 

I already thought about this, too (plus a key-combination to clear the highspeed SIO table). It wouldn't be a big problem for the stock XL OS, but I'd have to analyze the various MyIDE OSes (they already patch the keyboard IRQ routine, but it's different for example in 3.1 and 4.3).

I agree that would be a nice addition. One likely scenario where high-speed SIO capability could change dynamicly is with a Happy or other "programmable" drives.

I checked the various MyIDE versions and think I found the right location to patch the code (replace the "LDA $D209" with a JMP to the new code). A first, quick test worked fine, now I have to do some more testing.

 

Are you supporting high-speed SIO both for reads and writes?

Yes.

If so, note that Happy drives have a problem when writing at high-speed but with track buffering disabled.

What kind of problems are this and under which circumstances do they show up?

 

I ran a some tests with my Happy 1050 (in ultraspeed mode and in warp speed mode and disks in ED and DD) and everything seemed to work well. I then sent a happy command ($48) with DAUX set to $0020 to the drive, writing then was of course faster but otherwise it worked as well as without this config.

 

Ideally, you should turn-on track buffering if possible.

In general I don't like fiddling around with drive settings too much. First I'd have to check if such a command has negative effects with other drives and then I'd also have to be sure it works well with Happy drives. For example: what happens if the user first uploaded code to the drive's RAM?

 

so long,

 

Hias

[machf]

Well, if the sawtooth is being approximated in software using a Fourier series, it depends on how many coefficients are being used, I guess.

 

Sawtooth has quite a lot of 'harmonics', which don't fall-off that rapidly as f.e. triangle waveform.

Yes, I know, that's why I said it would depend on the number of coefficients. Don't know what the emulator is actually using, but a sawtooth function definitely isn't easy to simulate...

Fourier series isn't needed though, and isn't used. PWM is just a windowed integrating effect, for computing averages (or weighted averages, by using a 'mollifyer' or 'weight-function). The integration is of course always approximated by a summation over certain 'samples'.

 

If I'm correct, the recent pokey emulation uses this relatively simple PWM for the sawtooth, and alike effects. I wonder how much of these samples are needed for a PWM effect which sounds good enough.

Possibly several. A sawtooth is still hard to emulate, even by other means than Fourier... you may end up with something only vaguely resembling it.

It isn't good to generate a large spectrum of sounds by logic operators, and some other sounds by a totally different method, like using a Fourier series.

[MEtalGuy66]

Someone should upload a pre-patched XL/XE ROM image for those who don't want to patch it themselves. I'd help "monkey test" it, if I could just burn it on an EPROM and slam it in...

 

Also, what is the prospect for compatability with Spartados 3.2x ?

[analmux]

Yes, I know, that's why I said it would depend on the number of coefficients. Don't know what the emulator is actually using, but a sawtooth function definitely isn't easy to simulate...

 

??? I don't get it. What's so difficult about it then? I don't see the problem. So, please explain yourself.

 

maybe this link here clears some things up:

 

http://www.atariage.com/forums/index.php?s...p;#entry1431677

 

please read somewhere in the middle of the post. Perry_m wrote that PWM is as easy as resampling.

 

Sawtooth effect on real machine is nothing more than a PWM-alike effect, caused by the retardation of capacitors which are functioning like windowed integrators.

[HiassofT]

Someone should upload a pre-patched XL/XE ROM image for those who don't want to patch it themselves. I'd help "monkey test" it, if I could just burn it on an EPROM and slam it in...

You can also easily patch a ROM on a Windows PC (using the patchrom.exe) or on a Linux PC (do a "make patchrom" first to compile the executable). If you like I can email you a pre-patched XL/XE ROM.

 

Also, what is the prospect for compatability with Spartados 3.2x ?

The patched OS ROM works fine with SpartaDos (just ran a quick test with 3.2f and 3.2g). But, since SpartaDos doesn't use the SIO code of the OS (only for the first few sectors when booting), it doesn't really help much. With SDX 4.22 you can use the SIO2.SYS instead of the default SIO.SYS. Then you can also use highspeed SIO with SIO2PC/APE/...

 

OTOH, the "software patch" won't work with SpartaDos if it uses the RAM under the OS.

 

IMHO the best solution would be to take the source code and create a driver for SpartaDos out of it. I'm not really an expert in this area (actually, I don't even know how to do this) and also I don't know if it would be possible with SpartaDos 3.2x. But I'm sure there are others here that could answer the question and/or create a driver.

 

BTW: the new SDX 4.41 already includes a working SIO.SYS driver that supports ultraspeed SIO with SIO2PC etc.

 

so long,

 

Hias

[machf]

Yes, I know, that's why I said it would depend on the number of coefficients. Don't know what the emulator is actually using, but a sawtooth function definitely isn't easy to simulate...

 

??? I don't get it. What's so difficult about it then? I don't see the problem. So, please explain yourself.

 

maybe this link here clears some things up:

 

http://www.atariage.com/forums/index.php?s...p;#entry1431677

 

please read somewhere in the middle of the post. Perry_m wrote that PWM is as easy as resampling.

 

Sawtooth effect on real machine is nothing more than a PWM-alike effect, caused by the retardation of capacitors which are functioning like windowed integrators.

 

In analog form (electronics circuitry with use of capacitors) it's easy to perform. But digitally, an integration will be using a discrete approach - essentially, it's the same thing with all A/D and D/A conversions: there's a "rounding error" that will give you a stairstep rather than a true sawtooth, in the first place. Ideally, the emulator should use steps that are the best that the sound hardware on the PC can offer. And you need to make sure that the sample frequency used is > twice the wave's maximum frequency. Fourier or not, it's going to have the same constraint. Can the software+hardware reach the needed frequencies for the whole spectrum the POKEY sound generation covers?

Edited June 26, 2008 by machf

[ijor]

If so, note that Happy drives have a problem when writing at high-speed but with track buffering disabled.

What kind of problems are this and under which circumstances do they show up?

I ran a some tests with my Happy 1050 (in ultraspeed mode and in warp speed mode and disks in ED and DD) and everything seemed to work well...

 

It seems to work well, but it doesn't. It usually corrupts the data.

 

Hi-Speed transfer is simply not compatible with "slow" (unbuffered) writing mode. It is documented by Happy, and I know it from personal experience. I don't know the reasons and I don't know/remember exactly if data is corrupted in every single write, or in some specific circumstances. I never bothered investigating the issue (now that we bring the issue, I'm curious and may be I will).

 

Ideally, you should turn-on track buffering if possible.

In general I don't like fiddling around with drive settings too much. First I'd have to check if such a command has negative effects with other drives ...

 

I understand, and I realize about the potential problem.

 

But honestly, the chances that the "H" command would affect non-Happy drives is close to zero. But it doesn't matter how much close to zero, I agree it would never be zero...

 

... and then I'd also have to be sure it works well with Happy drives. For example: what happens if the user first uploaded code to the drive's RAM?

 

When the Happy is programmed with user code, it is either located in RAM areas outside the track buffer, or either the code takes care of ignoring/rejecting "H" commands to enable fast mode. Otherwise, it is broken.

 

Conceivable there are some third party Happy programs that are "broken" precisely like that (I might even hade made that mistake myself). And I realize you would like to keep compatiblity with those "broken" programs.

 

But you can't help it, your patch (or any OS patch for that matter) would always mean some degree of incompatiblity one way or the other. If the user wants 100% compatibility, he would have no choice but to install a switch or one of the solutions available to select between multiple OSes.

 

Please note that later versions of Sparta Dos do enable fast writes automatically on Happy drives.

 

Anyway, whatever you would decide, the important thing is that you should be aware about the issue.

[HiassofT]

Hi Ijor!

 

It seems to work well, but it doesn't. It usually corrupts the data.

Ouch, this is really bad :-(

 

Hi-Speed transfer is simply not compatible with "slow" (unbuffered) writing mode. It is documented by Happy, and I know it from personal experience.

Do you remember where this was documented? I just have a copy of the "warp speed software rev 7 user manual" which doesn't contain any information about SIO commands at all.

 

When the Happy is programmed with user code, it is either located in RAM areas outside the track buffer, or either the code takes care of ignoring/rejecting "H" commands to enable fast mode. Otherwise, it is broken.

ACK, you are right.

 

I'll extend my patch so that it will enable fast writes.

 

so long & thanks a lot for the info,

 

Hias

[HiassofT]

Please note that later versions of Sparta Dos do enable fast writes automatically on Happy drives.

Another question: Which versions are this?

 

I ran a trace and 3.2g, 3.3b and the new SDX 4.41 only send a $3f command to the drive, but not a $48.

 

With SDX 4.22 it's the other way round, it sends just a $48 command (with DAUX=$0020), but no $3f.

 

so long,

 

Hias

[ijor]

Do you remember where this was documented? I just have a copy of the "warp speed software rev 7 user manual" which doesn't contain any information about SIO commands at all.

 

Happy never documented their custom SIO commands. What is documented, is that hi-speed xfer is incompatible with slow writes. The latter is documented (checking) ... in the U.S.D. EMU section.

 

Another question: Which versions are this?

I ran a trace and 3.2g, 3.3b and the new SDX 4.41 only send a $3f command to the drive, but not a $48.

With SDX 4.22 it's the other way round, it sends just a $48 command (with DAUX=$0020), but no $3f.

 

I'm afraid I don't remember. But I trust your tests that would indicate that only SDX (original versions) enable fast writes.

 

Yes, omitting "?" makes sense. It is not strictly required and Happy own software rarely use it (if at all).

[thorfdbg]

In analog form (electronics circuitry with use of capacitors) it's easy to perform. But digitally, an integration will be using a discrete approach - essentially, it's the same thing with all A/D and D/A conversions: there's a "rounding error" that will give you a stairstep rather than a true sawtooth, in the first place. Ideally, the emulator should use steps that are the best that the sound hardware on the PC can offer. And you need to make sure that the sample frequency used is > twice the wave's maximum frequency. Fourier or not, it's going to have the same constraint. Can the software+hardware reach the needed frequencies for the whole spectrum the POKEY sound generation covers?

 

The point is that the software emulation doesn't have to run at the exact machine speed to perform that. It is enough if the software knows

how many samples it has to integrate up to fill up the next audio output buffer. I further don't understand what you mean by "staircase"? Every *digital* sound is a staircase, but the signal to noise ratio caused by this staircasing is so low that you cannot percieve it - that's not at all different why CDs offer good audio quality *even though* they are digital. In atari++, the pokey generation integrates the samples within one "host hardware sample time" interval up. If that is "shorter" than the original pokey interval, then the "sawtooth generation" will be taken over by the lowpass in the audio output hardware, as it was in the Atari. If the sample interval is longer, this "lowpass" is actually realized by the integration function in the emulator, so it works correctly in either case.

 

Even then, why does the sampling frequency (that is, the frequency by which samples are "logically" created, even though the physical

computation speed is different) have to be larger than twice the maximum frequency? There is the sampling theorem, of course, but if your

output audio device has a band limit of 44.1 kHz, then you won't be able to hear the missing or additional frequencies anyhow.

 

The situation is in so far complicated as there are three, not two frequencies involved: The frequency by which the emulated Pokey

runs, the frequency by which the samples are played by your audio hardware, and the frequency the CPU runs at the host machine. They shouldn't be confused. (-: It is a matter of a reasonably stable design to assign enough CPU power to the sound generation and to keep the sound with the game play in sync, even though the CPU load is varying - that was the trickier part.

 

Even my 1.6Ghz Athlon was fast enough on Linux to generate 44.1kHz sampling rate for atari++ and the Alsa interface (alsa seems to

have a pretty low overhead). Windows, even with DirectSound, doesn't go up that high, I had to lower the host hardware sampling rate

to half of it, unfortunately. Nevertheless, the "sawtooth" comes out correctly.

 

What is harder is the proper emulation of the "triangle" wave, which is more or less due to nonlinearities in the pokey audio output mixer (if it would be fully linear, no mixing would happen and nothing could be heard). Atari++ has a "gamma" regulator for the pokey output for that. If tuned correctly, the triangle also comes out.

 

So long,

Thomas

[machf]

OK, forget it - I was only saying that a software implementation had to take all that into account, not that it wasn't possible.

[analmux]

OK, forget it - I was only saying that a software implementation had to take all that into account, not that it wasn't possible.

 

No problem

 

But my point was more like that using Fourier theory is a bit superfluous, as you'd need to make a sum of fourier-coefficients multiplied by sinewaves with different wavelengths. For this you'd need to 'compute' the wanted pitches, instead of just doing some digital logics and summings/integration. Then, you'd need a formula which tells you which pitch will be the result of combining two ultrasound pokey pitches. The PWM will just as well function like some kind of blackbox. Whatever the capacitors of the real atari will generate, the PWM-resampling will mimic it very closely.

 

Sawtooth is far from the only sound possible by this PWM feature, and you'd need to compute all the possibilities, each with its own formula and its own Fourier decomposition. There are also modulations of sawtooth + noise, but filtered polycounter sounds also are possible due to PWM / capacitors. etc.etc.

 

But, let's not spoil this thread. Back to topic now

[HiassofT]

What is documented, is that hi-speed xfer is incompatible with slow writes. The latter is documented (checking) ... in the U.S.D. EMU section.

Thanks a lot, now I also found it in the docs!

 

BTW: I just finished implementing the new features (fast writes are always enabled for Happy drives, highspeed SIO can be enabled/disabled/reset with keystrokes plus another keystroke to cold boot the Atari) and started with beta-testing. If anyone would like to help beta testing, just send me a PM or email.

 

so long,

 

Hias

[drac030]

With SDX 4.22 it's the other way round, it sends just a $48 command (with DAUX=$0020), but no $3f.

 

Yes, the SDX 4.20-4.22 did not interrogate the drive about the speed index with the $3F command. The SIO.SYS driver always tried to select the fixed baudrate of 52 kbps. If it failed, it used to fall back to 19,2 kbps. As it already has been pointed out, it has changed in 4.41, now the drive is interrogated, and the SIO routines should work OK even with the speed index of $03 (89 kbps IIRC).

 

The command $48 is sent not by the SDX itself (i.e. its SIO driver) but by the INDUS.SYS driver. The only difference between 4.22 and 4.41 in this matter is, that in 4.41 the INDUS.SYS driver does not get loaded by default. But it is present in the cartridge, if you want 4.41 to send $48 over the SIO bus, you have to include DEVICE INDUS in your CONFIG.SYS file.

[+Larry]

How does this SIO patch work with an Indus GT drive? Also as a suggestion, I think a patch that provides a key combo for a forced cold boot (instead of turning the computer off and waiting for memory contents to dissipate) is really essential.

 

I understand that you may only want to use Synchromesh, but since it is quite limited in its support, are you aware that you can put in the patched rom 0.5 from MrMartian and the drive will recognize UltraSpeed, and operate just as a US Doubler? I put this in my Indus, and I like it much better than the Synchromesh. Note: there were a couple of issues with some earlier versions of this, so be sure to get the last one if you decide to try it -- pretty sure it was 0.5.

 

I started to piggyback the new eprom with the original Synchromesh II rom, but the UltraSpeed works so well, I just went with US.

 

Here is the link:

http://www.atariage.com/forums/index.php?s...;hl=Synchromesh

 

-Larry

[ijor]

Hi drac030,

 

The command $48 is sent not by the SDX itself (i.e. its SIO driver) but by the INDUS.SYS driver.

 

Yes, the SDX manual notes that INDUS.SYS is required for Happy drives.

It is curious though that ICD put Happy stuff in an Indus driver.

 

The only difference between 4.22 and 4.41 in this matter is, that in 4.41 the INDUS.SYS driver does not get loaded by default.

 

Is this by design? If so, and just out of curiosity, why?

 

Note that this change means an incompatiblity with 4.22 (and old) SDX versions, affecting Happy drives (for reasons described in this thread).

[drac030]

The only difference between 4.22 and 4.41 in this matter is, that in 4.41 the INDUS.SYS driver does not get loaded by default.

 

Is this by design? If so, and just out of curiosity, why?

 

Note that this change means an incompatiblity with 4.22 (and old) SDX versions, affecting Happy drives (for reasons described in this thread).

 

We removed INDUS.SYS from the default CONFIG.SYS file, because what it does makes some trouble to some drives (e.g. in TOMS it causes the track buffering to be switched off), and for many other types of drives it is completely useless - so loading it only makes the DOS boot several seconds longer.

 

If I understand correctly, Happy only requires it for writing. So Happy users should write own CONFIG.SYS file that tells the SpartaDOS to load INDUS.SYS, and always startup the DOS with this file. I expect that this is not a great trouble, because regular users (I think) always use customized CONFIG.SYS.

 

But, of course, I see now that that decision (INDUS.SYS removal from the CAR:CONFIG.SYS) may badly surprise some users. We can restore INDUS.SYS to the default CONFIG.SYS in next release, but I would prefer to know a method of detecting, if the particular drive is the Happy. This would prevent INDUS.SYS from blindly applying these commands to other drives.

 

I have to say that I am rather surprised, that the Happy drive requires a special command to not screw the data.

[HiassofT]

We removed INDUS.SYS from the default CONFIG.SYS file, because what it does makes some trouble to some drives (e.g. in TOMS it causes the track buffering to be switched off)

Which of the commands is causing the troubles, the $48 (with DAUX=$0020) or the $58 (DAUX=$0119) and what are the issues with other drives?

 

We can restore INDUS.SYS to the default CONFIG.SYS in next release, but I would prefer to know a method of detecting, if the particular drive is the Happy.

I'm also currently thinking about this. ATM I don't know of a way to reliably detect a Happy (except the $48 command). In particular this also means that my highspeed patch could misdetect a Toms as a Happy.

 

BTW: Does the Toms $48 command transmit any data, or is it an immediate command like the Happy $48?

 

I just thought about another approach: is there a way to identify a Toms drive (and maybe other drives that handle the $48 command)? If yes, we could first check this and then only send the $48 command if it's not a Toms drive (and hope that this check doesn't have any negative effect on other drives...).

 

so long,

 

Hias

[ijor]

If I understand correctly, Happy only requires it for writing.

 

Yes, the default boot state of a Happy drive is, fast read but slow write. And even if the user set reads as slow as well, it is still work without problems at high-speed. The only problem is when writing at high-speed with writes in slow mode.

 

But, of course, I see now that that decision (INDUS.SYS removal from the CAR:CONFIG.SYS) may badly surprise some users. We can restore INDUS.SYS to the default CONFIG.SYS in next release, but I would prefer to know a method of detecting, if the particular drive is the Happy.

 

Well, the usual method is, precisely, the $48 command. It is not fool-proof, because conceivable some other drive use the same command for a different purpose. I know for sure that this won't conflict with any US made drive or mode/enhancement (Happy was popular and well known in the US, so other drives intentionally avoided the conflict).

 

But I am not so familiar with all the European drives. I would say that as long as you issue the $48, only after the drive acked the $3F, then chances of any conflict are probabaly nil.

 

I have to say that I am rather surprised, that the Happy drive requires a special command to not screw the data.

 

It is suprising, and then even more. My guess is that Happy didn't detect the bug until it was too late because SpartaDos wasn't that popular in the early days. And actually the earlier 1050 Happy didn't have built-in support for USD i-speed at all. They could, and actually they should have, released a ROM fix though .. but this was somehow against their own policy

Edited June 27, 2008 by ijor

[ijor]

I'm also currently thinking about this. ATM I don't know of a way to reliably detect a Happy (except the $48 command). In particular this also means that my highspeed patch could misdetect a Toms as a Happy.

 

BTW: Does the Toms $48 command transmit any data, or is it an immediate command like the Happy $48?

 

The conflict with the Toms is the $48 command or the Indus syncromesh stuff? I assumed it was the latter.

 

Is there a comprehensive description of Toms custom SIO commands? If so, I could probably come up with a reliable way to distinguish between the Happy and the Toms (assuming again, the conflict is the $48 command, otherwise it shouldn't be needed).

[DamageX]

I understand that you may only want to use Synchromesh, but since it is quite limited in its support, are you aware that you can put in the patched rom 0.5 from MrMartian and the drive will recognize UltraSpeed, and operate just as a US Doubler?

That's cool, maybe I'll try it sometime. I had to ask about the Indus since it's the only drive I have. I always used DOS-XL and synchromesh back in the day. Of course now I'd rather just stick with APE or harddisk.

[HiassofT]

I would say that as long as you issue the $48, only after the drive acked the $3F, then chances of any conflict are probabaly nil.

This would be a possibility, but unfortunately this would also break happy warp speed mode (commands 'p', 'w', 'r' at 38kbps) in my patch. First I check for the $3f command, then 1050 Turbo, then XF551 mode and at last I use a $48 command to check for happy warp mode.

 

Yesterday I rearranged my code so that $48 is checked first, then $3f, and after that 1050 Turbo and XF551. But I guess I might have to change this again :-)

 

The conflict with the Toms is the $48 command or the Indus syncromesh stuff? I assumed it was the latter.

Good question. I did some more tests and now I'm confused even more than before:

 

The original "GTSYNC.COM" from the Indus Super Syncromesh disk just uses $58 commands to upload the syncromesh code to the drive. It doesn't send any $48 commands.

 

The INDUS.SYS driver from SDX 4.22 first sends a $48 and then a $58 command.

 

I also tried a config.sys with indus.sys enabled in SDX 4.41, but then I only heard some beeps but didn't get any log messages in AtariSIO (this is normal if the PC doesn't support the transmission speed). In a next test with SIO2.SYS (instead of SIO.SYS) plus INDUS.SYS again the $48 and $58 commands showed up.

 

So, the big question here is: why does the INDUS.SYS driver send the $48 command? Do the Indus drives support it?

 

Is there a comprehensive description of Toms custom SIO commands? If so, I could probably come up with a reliable way to distinguish between the Happy and the Toms (assuming again, the conflict is the $48 command, otherwise it shouldn't be needed).

I'd also be interested in such a list. Plus a list of the Indus commands. I only have various 1050s and a XF551 here to test, but no Indus/Toms/... drives.

 

so long,

 

Hias

[HiassofT]

First I check for the $3f command, then 1050 Turbo, then XF551 mode and at last I use a $48 command to check for happy warp mode.

I might have found a solution.

 

What kind of highspeed protocol do the Toms drive use? Is it this one? I don't understand polish, but it seems like this protocol is identical to the "1050 Turbo" mode.

 

If this is the case, the code I wrote yesterday should be OK, as the 1050 Turbo mode is checked before testing for warp speed (with $48). So if the Toms doesn't respond to $3f, it should never receive a $48 command.

 

so long,

 

Hias