Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Lars

Pages: [1] 2 3 ... 13
1
This sounds fantastic, I can't wait to try it out.

Are the additional sample rates available to any audio adapter, or just USB?

Just wondering - I've got a couple of Warp boxes running audio logging 24x7, I'd love to be able to up the sample rate (they're using onboard audio cards supported via Uniaudio). 

I could of course switch these 2 systems over to using USB audio cards if needed.

Currently they are only available to USBAUDIO because the USBAUDIO installation package updates the MMPM subsystem accordingly.
The problem is an outdated AUDIOIF.DLL and SPI.INI. In principle Uniaudio could also support these higher rates and BitsPerSample (of course only if the HW supports them). But for that it needs an updated AUDIOIF.DLL and SPI.INI.
In order to not interfere with other audio adapters we have decided to build a USBAUDIF.DLL which takes the place of AUDIOIF.DLL so that AUDIOIF.DLL can remain untouched.

Lars


2
Lars,

This is pretty awesome stuff. Will this make for a completely separate solution from something like the AN stuff though?

Thanks,
 - Dariusz

Don't worry. You can combine my USBAUDIO.SYS with the AN driver stack and it should work just fine. The updated installation installs a new dll called USBAUDIF.DLL as a replacement for AUDIOIF.DLL alongside to the already existing AUDIOIF.DLL (in the \MMOS2\DLL dir) but it leaves AUDIOIF.DLL untouched so they don't step on each others toes.

Likewise the new installation overwrites SPI.INI (in the \MMOS2 dir) but our SPI ini update is "cumulative", which means it includes and adds on top of what is already in the default SPI.INI file.

In short: we try to keep things compatible with whatever comes with an AN installation.

3
Go, Lars and Wim, go! Any chance multiple streams could be added?...

In principle, yes. But I don't see the concept of multiple simultaneous streams supported in the USB audio spec. And therefore the current installation restricts it to 1 stream. But thinking about it, maybe yes, I'll have to check if there are devices that support multiple interfaces with each having the same parameters.
What DOES work is having a simultaneous input (record) and output (playback stream).

4
Wim and me, we have been working on updating the MMPM subsystem so that it will finally support WAV files with 24-bit and > 65535 Hz (there was a limitation in the MMPM subsystem components that would restrict the sample rate to a 16-bit value).

In fact, we updated the MMPM subsystem to support these sample rates beyond 48000 Hz:
64000, 88200,96000,176400,192000,352800,384000 Hz.

The MMPM subsystem still has an inherent limitation to only support a discrete number of sample rates but we picked the rates that are in common use today. But I think we can live with that and the supported rates can be extended if necessary (but will require an updated USBAUDIO installation, see end).

With this support you can finally use more recent USB audio devices and exploit their full capabilities.
While 16-bit, 44100 Hz stereo (CD-ROM quality) was about the best you could get in 1996, more than 20 years later this is about the minimum sample rate /bit-depth used. It will also pave the way to support USB audio 2.0 devices which normally only offer these higher sample rates.

By the way: UNIAUD would also need this MMPM subsystem update to support WAV files with sample rates higher than 48000 Hz.

Once we have everything nice and polished I will release a new version of my USB device drivers.
It will be necessary to rerun the USBAUDIO driver installation to get everything updated properly.

Lars

5
Applications / Re: Dynamic Icons
« on: January 16, 2018, 12:36:08 pm »
FWIW, that is an ancient and quite obsolete version of the HOWTO. The latest HOWTO and toolkit was version 2.1 released in December 2011.

Alex, what happens if you run "rebuild new themes" from the Theme applet ? Will it bind the resource files (create by rc with the -r switch) to the DLLs in question ? In short: will that also lead to a selection of a specific theme ? Will this change be applied on next system start ? Or will it even be applied immediately ?

Thanks for any help. Lars

6
Hallo,

I have created an experimental version of USBD.SYS that will place attached devices under the corresponding hub they are attached to instead of placing them under the host controller they are attached to.
I think that makes it easier to determine where a device is plugged in. For example, if you use an external USB hub you will see the attached devices under "USB Hub Device_x.y.z" instead of under the host controller the external USB hub is attached to.
I think this logic also better follows the Windows logic.

Would anyone want to try out ? Unfortunately it will not work with the AN stack yet so you will need to (temporarily) install my 10.220 stack. If people prefer this I will try and convince AN to put it in their USBD.SYS.
It's not a big change to USBD.SYS and my HWMAN.DLL extension will still show the proper device names without any change !

Lars

7
Programming / Re: OS/2 kernel requiring speculative execution patch!!!!
« on: January 03, 2018, 02:35:22 pm »
There's also the question of whether this flaw really affects OS/2 as I believe the kernel memory runs in a separate segment, something that is not supported by 64bit mode and I believe gives some protection.

As far as I understand, the problem is that even though you cannot access kernel memory from user space, the speculative execution of subsequent instructions following that instruction will allow you to deduce what the instruction attempting to access kernel memory would have produced as a result.
I cannot see what bearing the Intel segmentation mechanism would have on this. You could simply bypass the segmentation mechanism by using linear addresses in your exploit code. 32-bit code will not undergo the segmentation mechanisms anyway (apart from internal functions written in 16-bit requiring thunking of code and data addresses).

8
Programming / Re: Compiling an OS/2 Driver
« on: January 03, 2018, 10:01:22 am »
If you compile with a 16-bit compiler (which cl.exe is), make sure you include the DDK header file directories before you include the TOOLKIT directories.
In fact, you will very likely not need to include the TOOLKIT header files at all if you include the DDK header files.

Be absolutely sure that you reset/delete the INCLUDE and LIB environment variables before you run the makefile and that you properly define the includes and libraries via the proper compiler and linker switches/directives. I have been caught by the problem of including the wrong header and library files more than once.

Lars

9
Programming / Re: Compiling an OS/2 Driver
« on: January 01, 2018, 12:53:19 pm »
Hm,

unfortunately, Watcom produces debug info that no IBM supplied debugger can use, including ICSDEBUG.EXE (the debugger that comes with Visual Age) and ICAT (the remote source code debugger that can debug either via serial port or via UDP). This is also true if Watcom creates debug info in CODEVIEW format (looks like the CODEVIEW variant that Watcom generates is not understood by the IBM debuggers).

Just for that reason it can occasionally be better to still use Microsoft C 6.0 compiler as that one produces a CODEVIEW format that the IBM debuggers can understand.
If you don't care about source code debugging then of course this is not relevant.

Where that is possible I tend to create 2 makefiles: one for compiling/linking via Watcom and one for compiling/linking via VAC. Then I can develop using VAC and if everything works ok I can switch over to Watcom for the final build.

Lars


10
Article Discussions / Re: ArcaOS Wishlist - 6 months !!
« on: December 30, 2017, 08:37:55 pm »
Here you go with 2 drivers that I have written:

http://hobbes.nmsu.edu/download/pub/os2/system/drivers/misc/mchnchk2.wpi
http://hobbes.nmsu.edu/download/pub/os2/system/drivers/misc/syscall.wpi

The WPIs contain all the source code. While they might not serve a practical purpose for most people, they are a live example of what can be done in a device driver.

And here is another one (including source code).
http://hobbes.nmsu.edu/download/pub/os2/system/drivers/misc/os2pcat3.wpi

The latter is a PSD. Hopefully the source code contains enough comments for people to understand :-)

11
Programming / Re: Compiling an OS/2 Driver
« on: December 30, 2017, 04:57:35 pm »
Hi Martin,

my gut feeling is that you actually want to do more than just compiling a driver. My feeling is that you want to enable others to actually write a device driver, maybe you are thinking about people capable of writing a device driver for Windows but who have no clue about OS/2.

That said, I'd go with Roderick's hint. Have a look at David's driver library (for 16-bit and also for 32-bit).
Don't use the DDK for these purposes:
1) the DDK is a mess. It is unstructured, things are difficult to find.
2) the DDK mostly relies on the old 16-bit Microsoft C compiler and/or masm.exe, an extremly old Microsoft assembler that can only deal with nothing better than an 386 CPU.
2) I do not recommend to take any of the DDK code as being correct or suitable for SMP systems. Fact is, many of the DDK drivers are VERY old. You cannot rely on that code to work on any modern system, SMP systems in particular.

The only thing that is really necessary from the DDK are the header files as they basically define all of the internal interfaces/structures (as far as things have been made public to begin with).

Unfortunately, even with this info there are things about OS/2 that are really special:
1) a 16-bit driver is, well, 16-bit. For example, if you want to read a 32-bit HW register there is usually a HW requirement to read it as full 32-bits. That will require a minimum of assembler code because you will need to use memory instructions that will move a full 32-bit of data. A 16-bit compiler won't generate these instructions. There are more of these issues.

2) You will need to fumble around with virtual addresses: a selector and an offset. That is what most programmers nowadays will have forgotten about. Then there is the additional difficulty to hop back and forth between virtual addresses, linear addresses (a 32-bit offset in a flat 4 GB address space) and physical addresses. The reason for this most likely will be that virtual addresses can only address a "chunk" of memory <= 64 kBytes. More often than not this is not sufficient. For example, USBEHCD.SYS needs to address 128 kBytes of internal management data structures to make isochronous transfers work (something that you need to make USBAUDIO.SYS work, for example).


Lars

12
Programming / Re: VAC3.65 / 3.08 inline assembly? How to insert INT 3?
« on: December 26, 2017, 08:28:03 pm »
If you have the source code, can't you just compile xwlan with source debugging info (ICAT knows CODEVIEW and HLL where unfortunately it no longer understands the CODEVIEW variant that Watcom produces) and then set breakpoints from ICAT ?
If you set a breakpoint via ICAT, that's exactly what it will do: replace the first byte of an instruction with the 0xCC (int3) instruction.
At least that's what I have done over and over again with the USB driver source code.
Of course, the source code will have to be on your ICAT machine (along with the binary with debug info). The binary with debug info will (also, of course) have to go to the MUT.

13
Programming / Re: htonl in REXX
« on: December 26, 2017, 11:49:14 am »
then do this:

c2d(Reverse(d2c(swp,4)))

14
Programming / Re: VAC3.65 / 3.08 inline assembly? How to insert INT 3?
« on: December 24, 2017, 10:36:09 pm »
_interrupt(3) will very likely encode an "int 3" instruction as a 2 Byte opcode (0xCD 0x03).
Just verified with a test sample and it decodes correctly to 0xCC. This is with VAC3.65 and icc /Ti. Idebug stops and the popup says 'A program-generated breakpoint was encountered'.

OK in that case Everything is fine. Thanks for the Feedback.

15
Programming / Re: VAC3.65 / 3.08 inline assembly? How to insert INT 3?
« on: December 23, 2017, 11:57:22 pm »
Here is my smart ass answer to "_interrupt":

_interrupt(3) will very likely encode an "int 3" instruction as a 2 Byte opcode (0xCD 0x03).
The "real" int3 however is a 1 Byte opcode (0xCC). These two instructions are close but not the same and might confuse a normal debugger that expects 0xCC opcode for int3 (if you intend to execute the application under Debugger control and intend to stop it on the int3).

Pages: [1] 2 3 ... 13