macOS Calling all Programmers

[Macmadant]

hi everyone,

Today i was staring at the back of my G4, and noticed my old Formac ProTv, and thought is there anyway to get that working, then i thought i wander if anyone on macrumors could help, hence this thread, so Xcoders is there anyway any of you could get my old little pro tv card working i know it is possible as formac were doing it but scrapped it due to it stopping there other products from selling. many thanks
Antony

 

[Oats]

writing a driver for a proprietary graphics card from scratch, without an in depth understanding of exactly how the card works, is a nearly impossible task. and since the hardware is proprietary, this task would be impossible for anyone not working for the company who made the card.

 

[Macmadant]

writing a driver for a proprietary graphics card from scratch, without an in depth understanding of exactly how the card works, is a nearly impossible task. and since the hardware is proprietary, this task would be impossible for anyone not working for the company who made the card.

So you couldn't get a copy of the driver for os9 play around with it and make it work with Osx?

 

[robbieduncan]

So you couldn't get a copy of the driver for os9 play around with it and make it work with Osx?

Why can't you do it if it's that easy.

Your total lack of understanding of the complexity of what you are asking is astounding. We would need the source code for the OS9 driver and complete hardware specs of the card to stand any chance. As the driver is available as a binary only it's no help whatsoever.

It's just a black box. We can't see what the driver is doing, how it works, the card interface, anything. Why don't you ask the card manufacturers for a driver rather than asking use to do hundreds of hours of free work on a piece of hardware we don't even own.

 

[weg]

anyone on macrumors could help, hence this thread, so Xcoders is there anyway any of you could get my old little pro tv card working

I'm really amazed by how many people post things like "there's this little Windows application, could anybody just port this for me - what, source code? No of course I don't have it..", "anybody willing to write me a driver for my 10 year old XXX-hardware, what, why would you need specifications?"

 

[Macmadant]

Why can't you do it if it's that easy.

Your total lack of understanding of the complexity of what you are asking is astounding. We would need the source code for the OS9 driver and complete hardware specs of the card to stand any chance. As the driver is available as a binary only it's no help whatsoever.

It's just a black box. We can't see what the driver is doing, how it works, the card interface, anything. Why don't you ask the card manufacturers for a driver rather than asking use to do hundreds of hours of free work on a piece of hardware we don't even own.

Sorry i asked

 

[DavidLeblond]

Don't be so hard on the guy, not everyone is a programmer. If everyone was it would be a major pain to get a job as one, so I'd like to keep it the way it is.

Everyone is right, of course. I'd suggest emailing the company. It would probably not get you anywhere, but it never hurts to ask.

 

[savar]

Sorry i asked

Developer's get bad attitudes when confronted with people who don't understand software development...don't sweat it.

 

[robbieduncan]

Developer's get bad attitudes when confronted with people who don't understand software development...don't sweat it.

The way I see it is that if you are willing to buy and own a complex tool you should at least understand the basics of how it works. Whilst I could not strip and rebuild an engine (probably, I've never tried) I do understand the basics of how it works and know what most of the parts are.

So if I go to a garage and ask them to fix something I have an understanding of how complex it is and how long it is likely to take them (and how messy and unpleasant it'll be).

Is it too much to ask for computer users to put in the same level of effort?

 

[demallien]

The way I see it is that if you are willing to buy and own a complex tool you should at least understand the basics of how it works. Whilst I could not strip and rebuild an engine (probably, I've never tried) I do understand the basics of how it works and know what most of the parts are.

So if I go to a garage and ask them to fix something I have an understanding of how complex it is and how long it is likely to take them (and how messy and unpleasant it'll be).

Is it too much to ask for computer users to put in the same level of effort?

I don't know if you are aware of the fact, but you come across as being exceedingly arrogant.

For what it's worth Macmadant, your question was entirely reasonable. You just had the misfortune of running into some programmers that don't know enough to know how to reverse engineer. The "source" of your driver is right there in the MacOS9 binary. And better yet, all the parts of the driver that interface to the card itself (the hard bit to code) can be left "as is".

The hardest job is redoing the interface that faces towards MacOS (9 and X). The good new is that this part is well documented by Apple, so a minimal amount (less than 1 week) of reverse engineering would have a (at least partially) working product.

The bad news is that for anyone to do this, they'll physically need your ProTv, to know if what they are doing is just nonsense, or actually works.

 

[notjustjay]

For what it's worth Macmadant, your question was entirely reasonable. You just had the misfortune of running into some programmers that don't know enough to know how to reverse engineer. The "source" of your driver is right there in the MacOS9 binary. And better yet, all the parts of the driver that interface to the card itself (the hard bit to code) can be left "as is".

The hardest job is redoing the interface that faces towards MacOS (9 and X). The good new is that this part is well documented by Apple, so a minimal amount (less than 1 week) of reverse engineering would have a (at least partially) working product.

With all due respect, YOU are the one that comes across as arrogant.

So you need to find a programmer with strong machine code / assembly code experience, and a reasonable amount of domain knowledge about the product and its capabilities. You would have to make a lot of educated guesses about what the hardware model looks like, how the API is used, how the existing firmware is laid out, and so on.

Can the meaty bits be left as-is? Wouldn't that depend on what fundamental differences there were in the different OS's (event models, access to low-level hardware or OS calls)? I recently (re)wrote a driver for a piece of embedded hardware (a sonobuoy RF receiver) and the actual talking-to-the-hardware was a couple dozen lines of read() and write() calls to a serial device. The other couple thousand lines of code was the interface to the rest of the system, which included setting up threads, buffers, and so on. All of which had to be completely rewritten when we moved from one platform to another (not unlike a move from OS 9 to OS X).

Oh, and this programmer has to have a lot of free time on his/her hands. And be willing to do all this for free.

Sure it's possible, but it's still a lot of work. Could it be done in a week, like you say? With the right guy, it could be possible.

Will the right guy please step up?

 

[notjustjay]

So if I go to a garage and ask them to fix something I have an understanding of how complex it is and how long it is likely to take them (and how messy and unpleasant it'll be).

Is it too much to ask for computer users to put in the same level of effort?

I grew up just as the "home PC" phenomenon was taking off, and I learned on an old Apple ][ machine. At the time, there was not a whole lot of application software available, so whatever I wanted to do with it (except for a few games and Applewriter II) I had to make myself. I remember doing a science fair project in junior high and wanting to show a set of graphs comparing voltage-vs-time on different brands of "D" cell batteries. Today, you'd pop open Excel, enter some data points, create graphs, throw them into PowerPoint, and you were set.

At that time, I had to write a simple etch-a-sketch program, so I could sketch my graphs... then write a display program, so I could display the graphs... and when my disk got corrupted on the night of the science fair (!!), I had to write a "sorry, we are experiencing technical difficulties" program...

We are light-years ahead of that kind of primitive technology, but at the same time we have so much more to understand about the inner workings of our computers and operating systems. Sometimes what sounds easy turns out to be a whole lot more complex underneath, and sometimes what sounds hard turns out to be ridiculously easy. I admit I've distanced myself from all this a little bit by choosing to focus my studies and interests on lower levels, like console programming, embedded firmware, hardware drivers, etc.

 

[mrichmon]

The "source" of your driver is right there in the MacOS9 binary.

The source code for the driver does not exist in the MacOS9 binary. You can probably decompile the MacOS9 binary but that will not produce anything remotely like the original source code. In many cases, particularly when decompiling low-level code such as a device driver, you will not even end up with decompiled source code that can be compiled again to produce the MacOS9 binary. This driver was probably originally written in 'C' or 'C++' and the compilation process for these languages looses significant pieces of information (variable names, code structuring and instruction grouping, etc) that is contained in the source code.

And better yet, all the parts of the driver that interface to the card itself (the hard bit to code) can be left "as is".

The hardest job is redoing the interface that faces towards MacOS (9 and X). The good new is that this part is well documented by Apple, so a minimal amount (less than 1 week) of reverse engineering would have a (at least partially) working product.

Not quite since the structure of device drivers, their calling pattern and the break down of the device driver interface in OS X is completely different from the MacOS9 device driver model. Your claim is similar to saying "well there is a driver for hardware X on Windows, that means that it is only a week of work to produce a Linux driver". The reality is very different.

As a programming languages researcher, I was originally amused and frustrated by the question posed at the start of this thread. On reflection my amusment and frustration was due to the underlying assumtion in the question that making the TV card work with OS X is a trivial problem. My strong negative reaction, and possibly the reactions from others in this thread is not due to arrogance, but rather that my expertise and the years I have spent building that expertise can be so trivialized. Clearly this was not the intent of the original poster, but it is implicit none the less.

Suffice to say that getting an older piece of hardware working with OS X without manufacturer support is a non-trivial undertaking. If it was trivial, then the manufacturer who employees people that have expertise with this particular piece of hardware would have make drivers available. Often with older hardware, the manufacturer no longer has access to the required technical specifications of the old hardware and often does not have an instance of the hardware available for them to work with. These hurdles are also faced by any third party developer since even if the manufacturer wants to support third party development they may not have the information to release.

 

[MacMan93]

Quote:
Originally Posted by demallien
The "source" of your driver is right there in the MacOS9 binary.

The source code for the driver does not exist in the MacOS9 binary. You can probably decompile the MacOS9 binary but that will not produce anything remotely like the original source code. In many cases, particularly when decompiling low-level code such as a device driver, you will not even end up with decompiled source code that can be compiled again to produce the MacOS9 binary. This driver was probably originally written in 'C' or 'C++' and the compilation process for these languages looses significant pieces of information (variable names, code structuring and instruction grouping, etc) that is contained in the source code.

Actually....the source code is there, but when you diasmble the binary it will be in ASM. Finding developers that program an actual computer in asm will be hard to find. If only asm was similar between different devices it might be an advatage for me to learn asm in microcontrollers.....

 

[notjustjay]

Actually....the source code is there, but when you diasmble the binary it will be in ASM. Finding developers that program an actual computer in asm will be hard to find. If only asm was similar between different devices it might be an advatage for me to learn asm in microcontrollers.....

I had to take a lot of courses dealing in x86 assembly code in my undergrad engineering years. At one point I felt that I knew enough to build my own simple Z80-based microcomputer (in theory, anyway). We had to program virtual x86 machines (within a GUI-based CPU simulator that would show you the contents of all memory and registers, etc) and also for a simple board computer with a little keypad and 7-segment LED display.

Programming in assembly (and later TA'ing that class) feels like solving a Rubik's Cube and is still one of the most fascinating and rewarding things I ever did in school. I would not, however, want to use pure assembly for any kind of program that was more than a few hundred lines long.

 

[mrichmon]

Actually....the source code is there, but when you diasmble the binary it will be in ASM. Finding developers that program an actual computer in asm will be hard to find. If only asm was similar between different devices it might be an advatage for me to learn asm in microcontrollers.....

Assembly code is not source code. Assembly code is simply a transliteration of machine code into symbolic statements. The phase "source code" in common usage is used to refer to a high-level language. That is, a language that does not have a direct representation in machine code.

 

[demallien]

The source code for the driver does not exist in the MacOS9 binary. You can probably decompile the MacOS9 binary but that will not produce anything remotely like the original source code.

That would be why I put the word 'source' in quotes... On the other hand, anyone that is halfway reasonable at reverse engineering would never even consider using an automatic decompiler. It's going to be hand-decompiles all the way. I know, I do it as part of my job. That said, it really isn't as hard as people think. You're not decompiling something "compiled" by a human, but by a machine. It may take a day or so to get to grips with how a particular compiler works, but afterwards, it really doesn't take long at all to decompile by hand (notable exception - badly written code with several hundred lines of nested ifs, switches and breaks can be a little difficult, but even there, with experience, it's not too bad).

Not quite since the structure of device drivers, their calling pattern and the break down of the device driver interface in OS X is completely different from the MacOS9 device driver model. Your claim is similar to saying "well there is a driver for hardware X on Windows, that means that it is only a week of work to produce a Linux driver". The reality is very different.

No, it's not the same problem. You can't just grab chunks of existing assembly code and dump it into a Linux repository and expect it to get accepted by the maintainers. If you are just doing it for yourself, then yes, you can, and yes, it will only take about a week to do the conversion.

The thing is, if you are someone that knows how to write drivers for the original target (in this case MacOS9), and you know how to write the new target (MacOSX), then you are going to find that most of the code is going to be boilerplate stuff. The task is going to consist of
a) Writing the new MacOS X driver boilerplate
b) identifying, by reversing the old driver, the modules of code that communicate directly with the peripheral. Understand these modules, and potentially reverse them in full to have some C code
c) plug the identified modules into the appropriate places for your MacOSX driver.
One day each for tasks a and c, and about 3 days for task b. Admittedly there will probably be some holes in functionality, due to a mismatch between MacOS9 and MacOSX drivers, but the thing would at least be partially working. Note, this code would still have bugs. It would also have incomplete functionality, but the main part of what the driver is supposed to do should be in place. Which is what I said in my original post...

Suffice to say that getting an older piece of hardware working with OS X without manufacturer support is a non-trivial undertaking. If it was trivial, then the manufacturer who employees people that have expertise with this particular piece of hardware would have make drivers available. Often with older hardware, the manufacturer no longer has access to the required technical specifications of the old hardware and often does not have an instance of the hardware available for them to work with. These hurdles are also faced by any third party developer since even if the manufacturer wants to support third party development they may not have the information to release.

Yup, npted for the lack of hardware. I made the same point myself in my original post. We do have a spec of sorts, the original binary... I remember in my Air Force engineering classes that an example of an existing product is often used as a specification, so it's even officially recognised as such.

As an aside, there is no commercial interest for the original manufacturer to do ANY support for an old card. the manufacturer wants you to buy their NEW card!

 

[demallien]

With all due respect, YOU are the one that comes across as arrogant.

Why? Because I Pointed out to someone claiming expert knowledge about something which he clearly is not an expert in, and then used that claimed expertise to bash up on a newbie, that such behaviour could be construed as rather arrogant? Or because I state that any programmer competent in reverse engineering could do the task? Neither strikes me as being particularly arrogant.

So you need to find a programmer with strong machine code / assembly code experience, and a reasonable amount of domain knowledge about the product and its capabilities. You would have to make a lot of educated guesses about what the hardware model looks like, how the API is used, how the existing firmware is laid out, and so on.

This is my point exactly. Domain knowledge isn't really needed. The information that you are going to need is already right there in the binaries. You just need to know how to read them!

Can the meaty bits be left as-is? Wouldn't that depend on what fundamental differences there were in the different OS's (event models, access to low-level hardware or OS calls)? I recently (re)wrote a driver for a piece of embedded hardware (a sonobuoy RF receiver) and the actual talking-to-the-hardware was a couple dozen lines of read() and write() calls to a serial device. The other couple thousand lines of code was the interface to the rest of the system, which included setting up threads, buffers, and so on. All of which had to be completely rewritten when we moved from one platform to another (not unlike a move from OS 9 to OS X).

This is a very valid point. But then, I never said that you would have a polished, professional, ready to sell product at the end of a week, but a partially functional product (by that I mean the really big functionality being done - watching TV in this case, other parts, such as the power on/off management etc may not be finished.). Even the big functionality may have bugs in it, causing the system to crash after 10mins, or whatever.

A few more weeks of playing with the project, or even handing it over to other open source programmers now that the product at least partially works, and you could have a reliably working card.

Of course, several weeks of an experienced hardware programmer's time costs substantially more (orders of magnitude more) than a new card with drivers. But if I was between contracts, I may find it a fun project to do to keep my hand in...

 

[MarkCollette]

This is awesome. The skills to do this driver port:

- Have several years programming experience in C, C++, PowerPC assembler, and maybe even 68k assembler
- Know Mac OS 9 graphics driver interface
- Know undocumented behaviours for OS 9 device driver writing
- Know Mac OS X graphics driver interface
- Probably have already written driver(s) before
- Reverse engineering skills, use disassemblers, have an oscilliscope...

All to make a defunct card, which has long been technologically surpassed, work again.

Depending on perspective, one could see this as an awesome way to learn many aspects of low level programming, or as a monumental waste of time. The thread submitter is so far over his head that of course someone has to clue him in. And of course someone has to chime in saying that it is in fact doable.

But, why do the low level programmers even pretend that this is in any way a good idea? And why do the high level programmers have to get so defensive? And why am I posting this response?

 

[savar]

Actually....the source code is there, but when you diasmble the binary it will be in ASM. Finding developers that program an actual computer in asm will be hard to find. If only asm was similar between different devices it might be an advatage for me to learn asm in microcontrollers.....

You are using the term "source code" extremely liberally. If machine code=source code, then logically you're saying that code=source code, which is a totally ludricous proposition.

Source code literally means the source of the machine code. If you wrote it in ASM then asm is your source, and you could conceivably call the output of a disassembler source code as well. But ASM is very rarely used on desktop machines these days.

BTW, learning ASM on microcontrollers is a *great* idea, because although the names of the opcodes vary between architectures, most of them have a lot of similar commands. And once you've learned how assembly works, you get a much better understanding of what a higher-level language is doing behind the scenes. (How parameters are passed, how functions are called, how memory is allocated, etc. etc.)