|
|||||||||||||||||||||||||||||||||||||||||||
|
Here an interview with Chris Ludwig, Amiga software engineer, at the World of Amiga Show in London on December 11, two days after he and the other members of the surviving Amiga development team finally left their jobs. ![]() ![]() Actually there's one person still working there, that Jeff Frank, head of hardware engineering and his job at the moment is to liquidate any of the hardware that's left at Norristown. That may have changed since Friday. Friday was the last day at Commodore for myself and for a lot of other people as well. There were 16 of us, engineering staff. ![]() There was not a lot of development going on, mainly because the resource wasn't there, there was not a lot of money to be spent. We didn't have quite the number of people we needed. There were some software ideas being toyed with, there were some hardware ideas being toyed with, but there was no steady development goal... ![]() That is correct. ![]() Yes, but having said that, the deal that we had with HP was a solid one, and I don't think there going to be a problem there. They've got every reason in the world to want that to go through with whoever continues the Amiga. ![]() Towards the very end he wasn't there full time, he was just consulting to us, but when we needed him we could just call him. ![]() Somewhat well. We did have a resident expert, Dr Edward Hepler, the guy who designed the RISC 3D system, and he was there to the end. And he's committed to it so I'm sure that if something happened we'd get him back on board. ![]() It was a Commodore decision. We spent a lot of time looking at available processors and trying to decide which one best met the needs that we had in mind for the future of the platform. We chose it based on a number of different concerns: - first of all, compatibility with existing products. HP, because of their having bought out Apollo (constructor de stations graphics) have an interest that their processor is 68000-compatible, so there's a 68000 compatible emulation mode for the PA-RISC. ![]() Yes, that already. ![]() Its both, basically. The instruction architecture is similar to 68000 in many ways and there's some software emulation tricks that can be done as well, so between those two pieces it makes migrating easy. It doesn't guarantee compatibility, it's not like PowerPC where you have compatibility that's basically out-of-the-box, they haven't got that finished and I don't know that they will, but it makes the migration path much shorter, there's a lot less that has to be done in re-coding. ![]() That's correct. ![]() Exactly. That was one of the principal reasons for choosing the HP chip. Other reasons were we wanted a chip that would allow us a greater degree of control in implementing our own ideas for the 3D half of the work.. For example you can go and buy, for PowerPC for example, if you want to be a PowerPC hardware OEM (Ed: original equipment manufacturer) the PowerPC core, which is a little square portion of the die and then they give you the L-shape around the rest of the die in order to add in your hardware. That's how it basically works if you want to have a PowerPC-based chip of your own. ![]() Yes, exactly. It's been done with other chips. But we wanted to have our own die, our own semi-conductor work on the same die as the HP-RISC. With the PA-RISC, unlike the PowerPC, we're actually allowed to have a free rein over the whole die, so that we can take a HP-RISC core and basically put in pieces that we want, take out pieces that we don't want, add instructions, which is very important for us. We've had a lot of work spent on designing new instructions which allow us to have really fantastic 3D performance, and the PowerPC wouldn't have let us do that, the HP stuff does. ![]() Exactly, that was the plan, we're basically creating a custom PA-RISC chip based on the PA-150, the latest one, that would allow us to have really fantastic performance. ![]() We've got software simulations of the chipset running. We did software simulations of some of the four pieces and they worked, so we're satisfied that... ![]() You mean the Amiga chips? Yes. Essentially, in that one core we'd be taking the planned sound enhancements for AAA as well as all the graphics enhancements that we've designed for the RISC release and obviously the CPU port there as well. You'd still need a digital/analog converter at the end that does the colour tables for the back end of the video, but those are standard parts, it's not something that we have to design ourselves, and you've basically got a one-chip solution, that's scalable. Another reason for choosing the PA-RISC was that the PA-RISC is designed around allowing you to have a multi-processer system, with other processors acting as enabling processors. So that for example we could have a one-chip solution which would be very low cost for games systems for example, that was just our version of the custom PA-RISC, but we could have higher-end systems where our chip is actually just a sub-processer that's doing graphics work and another PA-RISC is doing the! major computation, so you've now doubled the through-put of the system and you still get all of the graphics performance that you have but your competition haven't on the PA-RISC chip, so you've got really tremendous performance. And you can scale that architecture to get quite high-end systems. ![]() It's not quite the same as transputers, it's not infinitely scalable. Transputers obviously give you a lot more scalability in that direction. But its a more tight integration as well. From a software perspective it's easier to code for because you're basically spawning off the graphics sub-tasks to the other chip, it's basically designing it as if you were working with a one-chip solution. ![]() We're looking at 18 to 20 months from inception. When somebody gets the deal and says 'Go forward' and the money's there it'll take about 18 months. It's the whole chip design that needs to be done and software support has to be done... it'll take some time. ![]() Well of course it is, but not to a great extent. That's probably the fastest it could be done. But the amount of resources required isn't tremendously huge compared to what we've had in the past. It's certainly a do-able thing. ![]() Sure, Windows NT runs on PA-RISC and we're not taking anything away that would prevent that. ![]() The plan is simply to port AmigaDos to the chip. So Exec will be ported, graphics will be ported, Intuition will be ported, all portions of AmigaDos that currently exist will be ported, the idea being that the system will be wholly an Amiga, with the capability of running Windows NT as well. Because it's a PA-RISC there will already be native compiled versions of NT. You're basically talking about a box that can run two OS's. Three if you count HP's system. ![]() That's correct, people would have to re-compile their existing software. But, again, because of the chips degree of compatibility with the 68000 line that shouldn't be a gargantuan effort. It should be about as straightforward as it is for Apple people to recompile in order to get their current 68000-based applications to run on PowerPC. ![]() Absolutely. It's a matter of ensuring that there's some vision at the top of the company in order to let something like this go through. Commodore has too often in the past been in the situation of having designed very cool products which just at the very end of the life cycle after we've spent all the money on them don't actually make it to market because the people at the top have a lack of vision and when they see the finished product say "Oh no, they wouldn't wanna buy that." But I don't think we'll see that with the potential buyers. ![]() Absolutely. It really depends on how the buy-out happens. Anyone who's buying the whole company will get the rights to build this computer. But there's been talk that the liquidator may be deciding to sell off the company piecemeal which would mean that if someone wanted to pick up just this technology they could come in with a smaller figure than the full value of the company, and somebody else could buy the right to use the names Amiga, etc. ![]() If it happens fairly quickly I feel personally quite certain that people who were involved would be interested in coming back. It depends on how long it takes. In six months from now if nothing's happened I'm sure they'll all have jobs and they'll probably be quite happy with them. Its maybe not going to be the same spark that we had with Commodore, but you never know. If the money's good, you've got wives and children... ![]() The truth is that he's had very little contact with the engineering staff. He's been around once or twice but beyond that things have been in a vacuum. ![]() Yes, definitely. We've had more contact with teams that have gone away now. At one point Samsung were a potential buyer. ![]() Yes, but that was a long time ago. ![]() Correct. ![]() Sure. I think that having got rid of the engineers and Christmas obviously being dead now, it means the value of the company has probably been reduced quite a bit, and people who lost interest before may be more interested now that the price has gone down. ![]() It's difficult to say. They were obviously interested in the engineering know-how that we had and in a number of the hardware designs that we had. Whether or not they were interested in continuing the Amiga as a product line is difficult to say. ![]() All I can really say is, whoever takes over the company I hope they have a driving instinct and vision to bring forth the best that the platform has to offer. I worry that people may have a short-term view of what to do with the platform, that some of the buyers will have a potential of just wanting to do a kind of smash and grab operation. ![]() I think so. ![]() Yes there are some serious ones. ![]() Yeah... ![]() It's difficult to say. I think that the UK team have a real clear idea of where they want to go, and that's very important. ![]() Obviously the chip-set's gotta be video compatible. One of the major reasons for making sure that we have a low-end version of the chipset is that it would be usable in video games, set-top boxes, and low cost multimedia presentation devices like a cheap television set-top bo, so it's gotta have video compatibility. The blitter portion of the engine will retain peroccupatibility with current blitter stuff. ![]() Yeah, yeah, we'll have scrolling. A number of the current video modes will be available or at least emulated, and then the the new video modes I think you going to be surprised with. There's some great modes. ![]() We're probably going to toss sprites altogether. If you look at how games programmers write games today, very few of them are actually using sprites any longer. They use just one sprite for the main character and they toss out the rest; just because the overhead for sprites, while it's minimal, it's so much easier these days to, especially if you're porting to PC compatibles, to not have to deal with the sprite issue. It just makes more sense to dispose with it altogether and use the real estate that we gain to enhance the 3D abilities. ![]() I don't know that it's definitely out. Dave (Haynie) spent a lot of time getting a system out that would, at least from a hardware perspective, work I think the problem with it is that from a feature-set standpoint it really doesn't buy us enough in the short-term to be useful in the short-term and in the long-term we're better off trying to leapfrog the feature-set entirely so that we have something new and innovative, and that's why we focused on the RISC-3D stuff. ![]() Oh yes, definitely. From what we know reading IEEE magazine and playing with them our system will beat the pants off a Saturn (Sega's coming console). We've designed it around being a really fantastic system, exercising the best of the resources that Commodore's always had, basically designing our own chips rather than going out to someone else and just using an off-the-shelf chip. We've got some really good stuff planned. ![]() Yes it has been hard to market. That's it. It's one of our assets, and getting rid of it by just concentrating on one end or the other would be a mistake. ![]() Yes. Basically the blitter has grown features that allow it to do texture mapping, that allow it to do shading like the new consoles, but faster and with higher quality video modes, so that we've got a greater resolution than the consoles have, because at the high end we're going to need that resolution. We've got completely programmable pixel rates, as you know that's basically a feature that started with AA, that AAA grew some, and this basically continues that growth path so that we'll be able to do a large number of graphic modes. We have true colour modes (24-bit), we have some fairly innovative colour reduction modes, similar to HAM but a bit different, we have YUV modes so it'll be much more simple for us to do PhotoCD support, we've also got some 32-bit modes where we've got a transparency channel as well. ![]() Yes, sure. Obviously that's not the kind of mode you'd want to use for a games system, because it takes too much bandwidth, the graphics take up too much space, but it's there because the same chipset could be used in a high-end system to provide a true-colour, high-resolution desktop interface. ![]() It's all in the one chip. Everything is in there except RAM, ROM, and the RAMDAC for the colour tables. ![]() There's an internal cache for the PA-RISC and then there's some external cache space as well. ![]() Obviously if we're going to go to the trouble of porting the OS to another chip then we have the opportunity at that point to get rid of all the problems that we've had to live with in exec. We would have done it a long time ago but certain internal features of exec made it difficult to do. ![]() Exec won't be an easy port because it's written entirely in assembly code but it's a small, tight core so it shouldn't be too difficult. ![]() Whatever clock speed the Pa-RISC chips are available now. I know they're doing 100MHz, so... ![]() At the moment in-house there are no designs for anything beyond 25MHz '040. I think what we're looking at as a likely prospect would be OEM'ing somebody else's add-on CPU card design and then building those into the box, just as a short-term solution. It's definitely true that we need to have a 4000 with higher specifications on the market and that gives us a quick way of doing that. ![]() I was hired on about three and a half years ago to do multi-media standards. Basically I managed the IFF standard, handling registrations for the forms and so forth and tried within the organization to bring in standards from the outside world and develop our own standards where there weren't already standards in place, and then get developers to adopt the standards. Unfortunately as usual in Commodore there was very little resource to expend towards these efforts so not a lot came of it, but we had some good work. For example CAMDI (Commodore Amiga Midi Driver), which is essentially a MIDI library-style system for allowing MIDI applications to share access to the MIDI ports so that there is automatic merging of the MIDI data. From that work a host of people ended up with another library called Real Time Dat Library which provides the synchronization and timing information from a master clock source which can be generated by the library itself or come externally from ti! me code devices, and then this master clock is distributed to sub-tasks that want it. So for example you can synchronize multiple animation playbacks simultaneously with sound playback because Real Time Library helps all the allocations to keep track. ![]() No, the plan is to bring it all over. That's one of the reasons it's going to take 18 months. A good thing is that having picked an already existing RISC core, even while the hardware work is progressing much of the software work can be started immediately because you can go out and buy an HP Workstation today with a PA-RISC chip in it. Basically we'll have software simulation of graphics sub-systems and whatever graphics abilities are available on the workstation, to the extent that they can emulate, will be used. It's going to be completely different because what we have in our own hardware is obviously going to be much faster, but from our perspective, developing system software, that doesn't matter much and we'll be able to program a significant portion of the OS without having the graphics end of the chipset done. We know what the graphics chipset is going to do and we can write software that emulates that. ![]() Precisely. It has to be that way because 18 months sounds like a long time when you're thinking about how long it will be before somebody's hardware is released, but if you're a software developer, as you well know, 18 months doesn't seem like much at all in order to learn a whole new system and to come out with some decent software for it. ![]() I think you'll find that we tried to maintain the basic chip philosophy. It's obviously not going to be compatible on a register level, so people who have been hitting the hardware all along are going to have to learn all over again! But if you're doing system programming then I don't think you've got anything to worry about. You should be able, at the end, without doing much more than simply recompiling your software, have something that works. That's the goal. We have a huge base of very good software out there. But I think you'll find that even in public domain this is where people go ahead because they wanna be first... ![]() I think that one important point is that the machine will come as a base with outstanding graphics performance. As a system to do 3D rendering, a as system to do commercial video work, you're going to find that our system will be able to compete just as well as Amigas compete today. In 18 months to two years time, when the PCs are coming to where we are today, we'll have gone forward another generation.
|