Topic: IShow DAC hack attack

[Fanny Pack]

I just bought an ISHOW DAC kit off Ebay.  They are going for only $132 with free shipping!!!!  That makes them the cheapest pre-built-with-a-case laser DAC available by far.  You can hardly build a sound card DAC and but it in a box for that price.  I am going to try to make a Spaghetti driver for it.

[Alfa Romeo]

cool!
I'll be up for testing! keep us advised. have the software already. waiting on driver hack!

[meandean]

 I'd like to get my hands on an 8ch (or more) 16 bit DC DAC that could run at the common audio sample rates and MOST important it would NOT be recognized by Windows as a sound device (and all the garbage that goes with it). Who knows... I might even break down and learn C++ or something to use it.

[Fanny Pack]

What would you do with it?

My tracking number shows my  IShow is in China.  On the way.

[meandean]

What would you do with it?

 The same thing I do with an audio card- only this time, I'd be guaranteed that Wintel is not going to micromanage
the data I'm sending to a dumb DAC.

[Fanny Pack]

But what do you do with an audio card DAC?  You don't have a scanner.  That's why I am wondering.

[meandean]

  OK, so I don't have a scanner now, but I would like to get one. Besides, there are plenty of things to do with DACs- I've held a couple jobs working as a tech on instrumentation gear, it would be a change of pace to be on the software design end.

[James]

I might even break down and learn C++ or something to use it.

That'll be the day!

I've been nagging at you about it for almost 15 years!

You know I'd be thrilled to help you with it.

And that goes for anyone else on this forum too!

I LOVE Generic C/C++ !!! 

Sharing it with someone else makes it even better!

James. 

[Fanny Pack]

I used C for embedded work.  It's nice to be able to cast a memory location to a taco or whatever you want.

[meandean]

I used C for embedded work.  It's nice to be able to cast a memory location to a taco or whatever you want.

  Hmmm.

  I've done some assembler on 70's vintage machines, complete with memory-mapped I/O- a very literal hardware world, but I've never quite understood PC memory. Conventional memory, upper memory, high memory, protected mode, EMS, XMS, multiplexed IRQ's... It's a structure on top of a structure on top of a structure (in the interest of product advancement with backward capability). I suppose that it doesn't matter, in the hope that the OS or language can at least provide the illusion of the literal, as long as you don't get distracted by the man behind the curtain.

[James]

You don't really need to know squat about the "real" memory or the OS with C/C++.

All you need to know is how and when to ask for it and whether you have to pay attention and give it back when you're done.

You can get to some sort of physical address, if you want to, but that is never needed in any kind of application except for those that directly examine....... the memory!

You have extreem precision with the memory, but it's all relative, based on names that you give it.

James. 

[meandean]

  How does all of this 'relative' business translate to direct access to a device?

[James]

Well, this is probably not the right thread for this conversation, but...

C allows you to create a name and associate it with a memory location, much like you do in BASIC. C/C++ has a thing called the address-of operator. If you declare a variable of type int, you can take the address-of the variable name. You never need to actually look at it. You can assign it to another variable that was made to contain an address-of-type-int. That's a pointer!

In C a memory location, although you don't need to know anything about where it actually exists in real memory, can contain the address of any other place in the memory. This is a pointer!

If you create a pointer, you can assign it a value of NULL, which means it points to nothing. If you pass this pointer as an argument to a function that is provided by a device driver, the driver can set the value of the pointer to some "real" thing, like the address of the first pixel of the video ram or the buffer for a sound card, or whatever. You never need to worry about what the actual address is. You only need to know that you gave a name to a pointer and you can use that name to read and write data to the specific device memory location.

Getting at the actual data that a pointer points to is called dereferencing a pointer. It's the value-of function that is the natural compliment and opposite of the address-of operator.

The reason I say it's all relative is because it is! If I create an array of any kind in C, the name of the array is actually the first location of where the array is stored in memory. If I say I want what is found at array_name + 5, the C compiler knows how big each element in the array is and it knows to give me the contents of memory as a thing of the same type, but 5 whole type locations away from the first one. It is also possible to subtract the location of the first element in the array from the location of the last element in the array and tell how many you have. You never need to know the actual address.

James. 

[Fanny Pack]

You don't really need to know squat about the "real" memory or the OS with C/C++.

That isn't quite true in the embedded world that I am working in.  The pointer may be a near pointer, far pointer, huge pointer, etc.  And you have to use them differently.  In these cases, the pointers do not necessarily map to a memory address.  Some are just offsets within their 64K memory block or what have you.

But, even in old 16bit Windows you had to worry about near and far pointers.

[Fanny Pack]

  How does all of this 'relative' business translate to direct access to a device?

It doesn't.  At least not in Windows.  Windows stopped letting you have direct access to devices a long time ago.  But, to get to anything in Windows you have to go through a C or COM API.  You don't need C.  You can any language as long as you map the C API functions into your program.

So, even if you had some different DAC without a audio API on it, you would still need to access it with some other API.  Most likely, it would be the one that the company that made the DAC created.  For example, with the laser DACs, I have to interface with C APIs that the DAC makers provide.