AMD Bulldozer: It’s time to settle

As you may remember, AMD’s Bulldozer has always been somewhat controversial, for various reasons. One thing in particular was that AMD claimed it was the ‘first native 8-core desktop processor’. This led to a class-action lawsuit, because consumers thought this was deceptive advertising.

I think they have a point there. Namely, if Bulldozer was just like any other 8-core CPU out there, why would AMD spend all this time talking about their CMT architecture, modules and such? Clearly these are not just regular 8-cores.

AMD argued that the majority of consumers would have the same understanding of ‘core’ as AMD does in their CMT-marketing. The judge basically said: “Well, we’d have to see about that”. This led to AMD wanting to settle, because AMD probably figures that the majority of consumers would NOT have the same understanding, if people would actually investigate, and do a survey among consumers.

Which makes sense, because AMD is still a minor player in all this. Intel is the market leader, and they always marketed their SMT/HyperThreading CPUs as having ‘logical cores’ vs ‘physical cores’. The first Pentiums with HT were marketed as having a single physical core, and two logical cores. That is the standard that was set in the x86 world, which consumers would be familiar with. Intel has always stuck by that. The first Core i7s were marketed as having 4 physical cores and 8 logical cores (or alternatively 4 cores/8 threads). And AMD shot themselves in the foot here… With their marketing of CMT they are clearly implying that their CMT should be seen as more or less the same thing as SMT/HyperThreading. In fact, AMD actually argued that the OS needs a CMT-aware scheduler. Apparently a regular scheduler for a regular 8-core CPU didn’t work as expected.

So, the bottom line is that Bulldozer does not perform as you would expect from a regular 8-core CPU. And there’s enough of AMD’s marketing material around that shows that AMD knows this is the case, and that they felt there is a need to explain this, and also find excuses why performance may not meet expectations.

But you already know my opinion on the matter. I’ve written a number of articles on AMD’s Bulldozer and CMT back in the day, and I’ve always argued that it’s like a “poor man’s HyperThreading”:

This shows that HyperThreading seems to be a better approach than Bulldozer’s modules. Instead of trying to cram 8 cores onto a die, and removing execution units, Intel concentrates on making only 4 fast cores. This gives them the big advantage in single-threaded performance, while still having a relatively small die. The HyperThreading logic is a relatively compact add-on, much smaller than 4 extra cores (although it is disabled on the 2500, the HT logic is already present, the chip is identical to the 2600). The performance gain from these 8 logical cores is good enough to still be ahead of Bulldozer in most multithreaded applications. So it’s the best of both worlds. It also means that Intel can actually put 6 cores into about the same space as AMD’s 8 cores.

So here the difference between CMT and SMT becomes quite clear: With single-threading, each thread has more ALUs with SMT than with CMT. With multithreading, each thread has less ALUs (effectively) than CMT.

And that’s why SMT works, and CMT doesn’t: AMD’s previous CPUs also had 3 ALUs per thread. But in order to reduce the size of the modules, AMD chose to use only 2 ALUs per thread now. It is a case of cutting off one’s nose to spite their face: CMT is struggling in single-threaded scenario’s, compared to both the previous-generation Opterons and the Xeons.

At the same time, CMT is not actually saving a lot of die-space: There are 4 ALUs in a module in total. Yes, obviously, when you have more resources for two threads inside a module, and the single-threaded performance is poor anyway, one would expect it to scale better than SMT.

But what does CMT bring, effectively? Nothing. Their chips are much larger than the competition’s, or even their own previous generation. And since the Xeon is so much better with single-threaded performance, it can stay ahead in heavy multithreaded scenario’s, despite the fact that SMT does not scale as well as CMT or SMP. But the real advantage that SMT brings is that it is a very efficient solution: it takes up very little die-space. Intel could do the same as AMD does, and put two dies in a single package. But that would result in a chip with 12 cores, running 24 threads, and it would absolutely devour AMD’s CMT in terms of performance.

Or perhaps an analogy can make it more clear. Both SMT and CMT partially share some resources between multiple ‘cores’ as they are reported to the OS. As I said, Intel calls them ‘logical’ cores, but you can also see them as ‘virtual cores’.

The analogy then is virtual machines: you can take a physical machine, and use virtualization hardware and software to run multiple virtual machines on that single physical machine. Now, if you were to pay for two physical servers, and you were actually given a single physical server, with two virtual machine instances, wouldn’t you feel deceived? Yes, to the software it *appears* like two physical servers. But performance-wise it’s not entirely the same. The two virtual machines will be fighting over the physical resources that are shared, which they would not if they were two physical machines. That’s pretty much the situation here.

All I can say is that it’s a shame that Bulldozer is still haunting AMD now that they are back on track with Zen, which is a proper CPU with a proper SMT implementation, and they no longer need to market their CPUs as making it sound like they have more physical cores than they actually do.

Posted in Hardware news | Tagged , , , , , , , , , , , | Leave a comment

Steinberger guitars and basses: less is more

Time for a somewhat unusual blogpost. As you may know, aside from playing with software and hardware, I also dabble in music, mostly with (electric) guitars. I recently bought a new guitar, a Steinberger GT-PRO “Quilt Top” Deluxe in Wine Red:

There is quite a story behind this. I think there are various parallels with my usual blogs, such as this guitar design dating from the 1980s, and a lot of engineering and optimization went into this design.

For those of you who aren’t familiar with guitars, I have to say that the guitar world is generally quite conservative. Revolutionary guitar designs do not come along every year, or in fact not even every decade. I think roughly speaking, there are only a few major revolutions in the history of the guitar:

  1. The move from using ‘catgut’ strings (actually nylon on modern guitars) to using steel strings. The ‘original’ guitar, commonly known as classical or Spanish guitar, used strings made from animal intestines, as did most other classical stringed guitars (violin, cello, double bass etc). At some point in the early 1900s, a new type of guitar was developed by C.F. Martin & Company, designed for steel strings instead. These are also known as ‘western guitars’. They have a very different shape of the body and neck. The body is generally larger, which together with the steel strings, allows for more volume. The neck is longer and thinner than a classical guitar.
  2. The development of electric amplification in 1931. Now that many guitars had steel strings, it was possible to develop a ‘pickup’ module that uses electromagnetic induction, which can be placed under the strings, to convert the vibration of the strings to an electric signal, which can be sent to an amplifier and speaker. These pickups are simple passive circuits, with just magnets and a coil of copper wire. They are still used today in pretty much the same form.
  3. The ‘solidbody’ electric guitar, developed by Les Paul in 1940. As guitars became louder because of amplification, feedback became an issue: the acoustic body and strings of the guitar would resonate uncontrollably from the vibrations generated by the amplifier and speaker, which generated a feedback loop. Les Paul solved this by using a solid piece of wood for the guitar body. The body had lost its function as an acoustic amplifier anyway, now that there was electric amplification. A solid piece of wood was much more resistant to feedback.
  4. The Stratocaster guitar, developed by Leo Fender in 1954. It had many interesting ideas, including a body shape that no longer resembled a traditional guitar, but was contoured for ergonomic purposes. It also introduced a new type of ‘tremolo’ system. I will get into more detail on this guitar later.

And I think that is pretty much it. At least, as far as complete guitars go. There have been small innovations on certain parts of the guitar, but generally these are considered optional extras or aftermarket upgrades, and do not significantly alter the guitar as we know it. In fact, the Fender Stratocaster remains one of the most popular guitars to this day, as does the Gibson Les Paul (originally from 1952, but the models with humbucking pickups and sunburst finish made between 1958 and 1960 became the archetypal model), and most players still use these guitars in more or less the same form as they were originally launched in the 1950s. Most other guitars are also just slight variations on these original guitars, and are mainly different in shape or choice of woods, but do not differ significantly in terms of engineering.

Enter the 1980s

In the late 1970s and early 1980s, there was a big revolution in rock/metal. Namely, we entered the era of the guitar hero, ushered in by Eddie van Halen. What made Eddie van Halen somewhat unique is that he built his own guitar from a combination of aftermarket parts and parts he ‘borrowed’ from other guitars. He used a Gibson humbucker pickup and put it into a Strat-style guitar. He also was a very early adopter of the new Floyd Rose double-locking tremolo:

See the source image


His guitar became known as the Frankenstrat. It became the template of the ‘Superstrat’ guitar, and various guitar companies, including Ibanez, Jackson, Charvel and ESP, would jump into this market by offering Superstrat-style guitars straight from the factory.

This was also the time in which I grew up, and this type of virtuoso playing was what attracted me most. As a result, a Superstrat guitar seemed like the ultimate guitar for me, because it basically offered you the best engineering and the most features. You got the best tremolo systems, the most advanced pickup configurations, guitar necks that were designed for optimum playability (generally thin, wide necks with a relatively flat profile and very large, aka ‘jumbo’ frets), combined with the ergonomics of the Stratocaster body design. I have always been attracted to clever engineering and optimized designs, in any area of life.

Getting back to the Stratocaster

What made these Frankenstrats and Superstrats possible, is the vision of Leo Fender, I would say. Above I said the Stratocaster was one of the big revolutions in terms of guitar design. I have to add some nuance to that statement. Namely, Leo Fender designed another guitar before that, in 1950. The first model was a single-pickup one, known as the ‘Esquire’. He then introduced a two-pickup model, which was initially known as the ‘Broadcaster’. However, because the company Gretsch already sold a drum kit under the name of ‘Broadkaster’, Fender decided to change the name to ‘Telecaster’. This model is still sold today. It can be seen as the forerunner of the Stratocaster, but guitarists also liked the original, so it remains a popular guitar in its own right. Fender also designed the Fender Precision bass before the Stratocaster, where he introduced the contoured body shape.

The Esquire/Broadcaster/Telecaster was one of the first solidbody electric guitars on the market. What made Fender somewhat unique is that Leo Fender was not a guitarist, or even a musician at all. He started out with an electronics repair shop, and then focused on designing and building amplifiers and pickups for electric guitars and basses. So Leo Fender was an engineer, not a guitarist, not a musician, and certainly not a luthier.

When he decided to build guitars, he also approached it like an engineer: he wanted the guitars to be cheap and easy to mass-produce, durable, easy to fine-tune, and easy to repair. This led him to make certain design choices that conventional guitar builders might never have made. One example is that he chose to screw the neck to the body. Another example is in his choice of woods, which were very hard woods. They were very durable, relatively light, and easy to work on. But they delivered a tone that was not necessarily very conventional. It was a very bright and jangly tone. But certain artists, especially country artists, loved this new sound, because it would cut through very well with fast lead playing.

The Telecaster introduced the wood types, the bolt-on neck, and had three adjustable saddles for setting intonation and string height for each pair of strings. It had a cutaway on the body to access the high frets on the neck. And it had two pickups, with a volume knob, tone knob, and a pickup selector switch for easy access below the bridge.

The Precision bass introduced the ergonomic ‘contoured’ body shape. It added a second cutaway above the neck, for even better access to the high frets.

The Stratocaster took these ideas further. It perfected the adjustable bridge by having individual saddles for all 6 strings. It added a third pickup and a second tone knob. It introduced a contoured guitar body, inspired on the Precision bass. And it introduced the new ‘tremolo’ system.

Now, ‘tremolo’ needs some explanation: What Leo Fender called a ‘tremolo’, was actually a ‘vibrato’ system (and funny enough, some of his amps had a tremolo effect, which he called ‘vibro’). Namely, tremolo is a fluctuation in volume. The ‘tremolo’ system on a Strat does not do that. It allows you to lower or raise the pitch, so you can perform vibrato effects, or portamento (pitch slides). But somehow, the name stuck, so even today, most guitarists and guitar builders refer to Strat-like vibrato systems as ‘tremolo’.

Another typical feature of the Stratocaster construction is that the body is a ‘frontloader’. That is, the cavities for all the electronics are routed out from the front of the body. These cavities are then covered up by a large plastic scratchplate which covers most of the body.

Customization through mass production

I think it’s safe to say that the simple mass-production design of the Fender guitars is what gave rise to aftermarket parts. It is very easy to replace a bridge, a neck, the electronics, or even to perform some custom routing. The scratchplate will cover it up anyway, so nobody will notice if the routing is a bit sloppy.

That is how Eddie van Halen could build his own Frankenstrat. And how many other players did very similar things to their guitars. Especially Floyd Rose systems were installed by many guitarists on their Strats and similar guitars in the 1980s.

But, the Floyd Rose is still a part designed to be fitted to a standard Strat-style design with little modification. It still makes use of the same idea of a sustain block under the bridge, which is held under tension by three springs and an adjustable ‘claw’:

This system is rather difficult to adjust, and the large springs also have an additional problem: They are susceptible to vibrations and give a sort of ‘reverberation’ effect. When you hit the strings hard, the springs will start to vibrate along with the bridge and body. When you then mute the strings, you hear the springs ‘echo’. This in turn can be picked up again by the strings and pickups, so the ‘echo’ can also be heard in the sound coming from the amp.

Another thing is that you still have the regular tuners on the guitar, which you need to put the strings on the guitar, and perform the initial tuning, before clamping down the strings with the locking nut. At that point, there are mostly ‘vestigial’. The bridge only has fine-tuners. Over time, the strings may go out of tune to the point where they are beyond the limited reach of the fine-tuners, and you need to unlock the nut, use the regular tuners, and then lock again, and fine-tune.

A third issue with a Floyd Rose is that you can no longer adjust the height of each individual saddle. You can only lower or raise the bridge as a whole, but the relative saddle heights are basically fixed.

So, while the Floyd Rose is an improvement over the traditional Strat tremolo in terms of tuning stability, it is basically just that: an improvement on a design dating back to the 1950s, which has to work inside the limitations of the original Strat design to an extent, because it is meant to be an aftermarket part, which can be installed on existing guitars.

Enter Ned Steinberger

So, what you should take away from Leo Fender and his Stratocaster is that he basically ‘started fresh’, with no preconceived ideas of what materials to use, or what kind of design and construction method. The result was a guitar that had a very unique look, sound and identity, and also pushed playability and versatility to new heights.

From then on, most guitars have been more less evolutionary in nature: taking existing guitar designs such as the Stratocaster as the basis, and changing/improving certain details. The Floyd Rose tremolo system is arguably the largest improvement in that sense.

But then came Ned Steinberger. He basically did the same as what Leo Fender did 30 years earlier: He designed basses and guitars without any preconceived ideas, just trying to find the best materials available, and trying to engineer new solutions to create the best instruments possible.

Ned Steinberger was also not a luthier by trade, he originally designed furniture. And as far as I know, like Leo Fender,  Ned did not actually play guitar or bass himself. Interesting fact is that his father is Jack Steinberger, a Nobel-prize winning physicist. So he grew up in a household of science.

Steinberger started on designing basses. He wanted to create a bass that was as light and compact as possible, while also being very durable. This led him to use modern composite materials such as carbon fiber and graphite, rather than wood. Another defining feature of the Steinberger instruments is the headless design. By using strings with ball-ends at both sides, rather than only at the bridge, there is no longer any need for conventional tuning pegs, and the big headstock that they are mounted on. The tuners can be moved to the bridge instead. Unlike the Floyd Rose, these are not fine-tuners, but full-range tuners, made possible with very fine-threaded 40:1 ratio. Also, Steinberger did not sacrifice per-string adjustment of string height or intonation.

Image result for Steinberger L bass

Another defining feature is the active electronics. Where conventional pickups for guitar and bass are passive coils and magnets, active pickups use an on-board amplifier, powered by a battery (usually a 9v block). Because of the amplifier, the signal from the pickup itself does not have to be that strong. This means that pickups can be designed with smaller magnets and different coils. The result is that there is less magnetic pull on the strings, allowing the strings to vibrate more freely and more naturally, resulting in a more natural tone with better sustain. The on-board active electronics also allow for additional filtering and tone shaping. The electronics for Steinberger were designed and manufactured by EMG.

The body is actually a hollow ‘bathtub’ created from carbon fiber, where the top is like a ‘lid’. This allows plenty of space to house all the electronics. And unlike wood, there is no problem with feedback.

Another detail is the use of a zero-fret, rather than a conventional nut. This means there is no special setup required for any specific string gauge or desired string height (‘action’) for the player. The ‘special case’ of the nut is eliminated.

You could say that everything about this bass guitar has a ‘less is more’ approach. The neck and body are reduced to little more than the absolute minimum for the player to hold and play the instrument.

And then, the Steinberger guitar

Once Steinberger introduced their bass, and it became quite popular with players, the next logical step was to create a sister-instrument in guitar form. It looks quite similar to the bass, and it is very similar in terms of design and construction, except for one important detail:

The bass did not have a tremolo system, because these are very uncommon on basses, and are not very practical anyway, given the big, heavy and long strings. However, a guitar had to have one, Ned Steinberger must have thought. He may have seen this as an interesting engineering challenge.

And boy did Steinberger live up to that challenge! Because of his basic design with the double-ball strings and the zero-fret, there was no need for any additional locking of the strings. This basic design was effectively already equivalent to a Floyd Rose, but with the added benefit of having full-range tuners, instead of just fine-tuners. And the basic design of the bridge could easily be made to rotate around a pivot point, like a Strat-style tremolo does, without sacrificing the adjustability of the saddles.

Also, Steinberger could simply add one big spring to the metal base of the tremolo, instead of the multiple springs and the claw found underneath a Strat-style guitar. This got rid of the ‘echo’ problem of the springs. Also, he added a simple adjuster knob at the back, so you could adjust the spring to make sure the tremolo was in tune in its center position. Much easier than the claw and screws on a Strat.

But Steinberger did not just stop there. A characteristic of any traditional tremolo/vibrato system is that all the strings receive the same amount of movement. This however does not affect all strings equally. The thicker, lower pitched strings will have a much bigger drop or rise in pitch than the thinner, higher pitched strings.

While this is good enough for small changes in pitch on chords (a bit of vibrato), or changes of pitch on single notes, anything more advanced will go out of tune. This has only very limited musical application.

So, Steinberger thought: Challenge accepted! And he came up with what he called the TransTrem. As far as I know, it is still the only system of its kind. The ‘Trans’ in the name is short for ‘transpose’. Steinberger pulled it off to make each individual saddle on the bridge move at its own calibrated rate. This allowed him to make each string change pitch at the same rate. Which means that all 6 strings can remain in tune while operating the tremolo. From there, it was a relatively small step to make the tremolo ‘lock’ in a few ‘preset’ positions. This means you could transpose the entire tuning of the guitar up or down by a few steps (E is standard, you can go down to D, C and B, and up to F# and G), and remain in tune while doing so! This means you can change tuning on the fly while playing a song.

Eddie van Halen was an early adopter of the Steinberger guitar, and he composed a few songs that made use of this special TransTrem feature. The song ‘Summer Nights’ is a good example:

And as you can see, the guitar stays in tune during all of this, and sounds good in all tunings and during all trickery that Eddie van Halen pulls off.

Here is also a nice documentary on Steinberger, where Ned talks about how he came to the headless design, and his thoughts about ergonomics. It also gives some nice insights into the factory itself:

Fast-forward: Present day

I don’t suppose Steinberger ever became such a household name as Fender and its Stratocaster. So what happened? Steinberger’s guitars and basses were certainly ‘space age’ technology at the time. Back in the 1980s, people loved futuristic stuff, and initially Steinberger couldn’t make enough of them. By 1987, Ned sold the company to Gibson, one of the largest, and ironically enough, one of the more traditional guitar companies.

But by the 1990s, the futuristic thing got out of style, and I suppose Steinberger went along with it. Perhaps the instruments were too far ahead of their time? Ned Steinberger had moved on to a new instrument company, called NS Design. Somewhere halfway the 1990s, Gibson stopped producing the original Steinberger guitars.

From then on, the Steinberger name would resurface every now and then, usually on cheaper Asian-made guitars. The guitar I bought is a ‘Spirit by Steinberger’, and is made in China. This Spirit-model has been in and out of production a few times. When they were launched initially, I saw one at a shop, and tried it out. I always liked the original Steinbergers, so I liked the Spirit, because it looked and felt like those original guitars. It just was a lot cheaper. But I never bought it.

Recently, Gibson has relaunched the Spirit guitars again, so I figured I’d not miss out this time, and I bought one right away. Where the original guitars were very much high-end guitars, these ones are clearly budget guitars, and it seems that their price and their compact form are the main selling points. It is marketed as a travel guitar, more or less. There also seems to be some renewed interest in headless guitars in general, where some high-end brands such as Strandberg and Kiesel make headless guitars, albeit with ‘traditional’ body shapes. Perhaps that has something to do with the Spirit re-entering production.

My Spirit GT-Pro Deluxe differs from the original in various ways:

  1. It does not have the TransTrem, but a cheaper R-Trem, which does not have the transposing capability, but is otherwise more or less equivalent to a Floyd Rose style tremolo.
  2. It is made of wood, rather than composite materials.
  3. It has passive electronics rather than active.

Not having the TransTrem is a bit of a shame, but not surprising, given that it was a very complex piece of hardware. The R-Trem works quite well in practice, and is much easier to tune and set up than a Floyd Rose is.

The fact that it is made of wood is also interesting. Namely, there is always a considerable discussion about choices of tone wood and construction in guitars. This guitar has considerably less wood than any conventional guitar does. Yet, it sounds remarkably conventional. Also, it does not seem to suffer all that much in terms of sustain. So perhaps this guitar is just making a mockery out of conventional wisdom in terms of guitar building?

The passive electronics are made by Steinberger themselves, which is a bit of a shame in the sense that I have no idea what they are, so I have no frame of reference whatsoever. Combined with the unconventional guitar body, choice of woods and construction, I basically cannot say anything about what makes the guitar sound the way it does.

All I can say is that I quite like how the overall package sounds. The pickups are not very loud, but I’m not sure how much of that is due to the fact that there’s such a small guitar body, and how much of that is due to the pickup design. The guitar seems to have a very ‘clean’ and ‘neutral’ sound to it. It is something I more or less associate with active EMG pickups, but again, I don’t know how much of this comes from the tiny body, and how much comes from deliberately designing the passive pickups to sound like the original Steinberger with EMGs. What I can say however is that the guitar seems to have a very nice top-end. Pinch harmonics sound really powerful and sustain well on the high B and E strings. The guitar body and neck are mostly made of maple, and that is something I would associate with maple.

The quality of the pickups seems very good at any rate. They are extremely low-noise, and you do not suffer from microphonic feedback or other noises (and as I said, no dreaded ‘echo’ from the trem either).

It has a somewhat ‘dry’ palmmuted sound. It sounds okay on the low E string, but lacks a bit of ‘oomph’ compared to my usual guitars on the A and D strings. Again I’m not entirely sure how much of that is down to the overall lack of output of the pickups, or specifically because of the acoustic qualities of the guitar itself (perhaps lacking a bit of midrange).

So it could be that these are very generic pickups, and the guitar just sounds the way it does because of its wood and construction. It could also be that these pickups are very specifically tuned for such an unusual guitar as this one, and regular aftermarket pickups might not work at all in this particular guitar.

But overall, after I set up the guitar to my liking, I find it quite easy to play, and although it takes some getting used to its specific sonal characteristics, it can sound very nice. It has a very unique feel to it. It is extremely light and well-balanced, and you have excellent reach to even the highest frets. It’s so light that the entire guitar shakes when you perform vibrato with your fingers. Coming from the other end of the spectrum, where my first decent electric guitar was a Les Paul, that is very strange indeed. I suppose it also is an indication that I should try to optimize my playing to use the minimum amount of effort required for vibrato, and let the guitar do the work.

I hope to own a ‘real’ Steinberger one day, the original graphite/carbon fiber model with the TransTrem and the active electronics. Sadly they are rare, and since they are so complex, chances are someone has botched them over the years, so buying second-hand is quite a risk (I often find that even with ‘simple’ Floyd Rose guitars… people with no clue have damaged the tremolo system beyond repair). But I will have one, one day! For now I’d settle on just being able to play a real Steinberger someday, just to know what a real one really feels and sounds like.

For now, I’ll leave you with a quick recording I did of a Joe Satriani song:


Posted in Uncategorized | Tagged , , , , , , , , , , , | Leave a comment

Zen2: Credit where credit’s due

So, AMD has released its new Zen2 architecture, codenamed ‘Matisse’, and now available commercially as the Ryzen 3000-series.

And I think I can keep this blog short: Intel has its work cut out, because AMD is back. AMD now has TSMC build their x86 CPUs, using their new 7 nm process. But Zen2 does not stop there. As in: it’s not just a so-so architecture that leverages a superior manufacturing process to push clockspeeds or transistor count into an advantage.

No, Zen2 is actually a very good architecture in its own right. It can compete head-to-head with Intel’s best offerings on IPC, and performance-per-watt is very good as well. Combine that with AMD’s standard weapon of value-for-money, and it feels like we’re back in the late 90s/early 2000s, where AMD’s Athlons would compete head-to-head with Intels Pentium III and 4.

Perhaps most interesting is that they chose not to use a single die, but to spread the functionality over multiple dies, where they can combine different manufacturing processes (something that Intel has done in the past with CPUs and GPUs/IMCs as well, such as the 32nm/45m Westmere).

It seems that Intel’s biggest problem at the moment is that they are still on 14 nm for their mainstream offerings. Now that is a first, as far as I know. Intel has always had the edge in manufacturing, even when their architecture itself was not superior. This allowed Intel to compete back in the Athlon days. But this time, Intel is on the back foot in manufacturing. And for the first time since the introduction of the Core2, Intel no longer has the more efficient architecture either.

So, I suppose we will now wait and see what Intel can do to strike back. What will their 10 nm process bring? And can they introduce a new architecture that once again takes the IPC/performance crown?

But for now, AMD seems to be in a very good place. I think that is good news. I have always said, since AMD had taken over ATi, that problems in the CPU department would hurt the GPU deparment, for the simple reason that the CPU market is larger, and would have their priority. And I think this is what we have been seeing in recent years. With AMD struggling since Bulldozer, their Radeon line was slowly losing grip on nVidia. So hopefully we will now see the reverse: with Zen2, AMD should be able to get back a lot of CPU marketshare, and boost their revenue considerably. And with that, they should be able to invest more in R&D for their GPU line as well, and close in on nVidia once again.

Posted in Hardware news | Tagged , , , , , | Leave a comment

Just keeping it real at Revision 2019

I visited Revision again this year. And I took my IBM PC/XT 5160 with me. And I made a quick release. That release was a plan that I’ve had for a while, and which I mentioned in my previous blogpost: a music disk for the IBM Music Feature Card.

And here is the page. You could download the binaries, but not many people will have the required hardware, I guess. And it will also break many emulators, because IBM Music Feature Card support is not a common feature in emulators (yet). I made sure that the code runs on my DOSBox pre-release with IMFC support, and AMAME, as described in my previous blogpost.


Code was done by me, graphics by VileR of 8088 MPH fame, and the music was done by UP-C.

If you look closely, the graphics aren’t just rips of the original Sega title screens, but they are an impression that combine the title/logo with some in-game view. All this in colourful composite CGA of course.

Likewise, the music is not a straight rip, but is tuned specifically for the IBM Music Feature Card/Yamaha FB-01 with custom SysEx messages embedded in the MIDI data.

System requirements

The minimum requirements are: IBM PC or compatible, 8088 CPU at 4.77 MHz, 128kb memory, composite CGA, IBM Music Feature Card, 360kb 5.25″ floppy drive, PC-DOS 2.0.

Technical info

The code is reasonably straightforward. The MIDI player is based on my pre-processed data format, combined with my streaming disk routine. Why the streaming disk routine, you might ask? Well, I originally developed that for the PCjr MIDI player for the DreamBlaster S2P. The problem with MIDI data is that it has no structure. It is just a linear sequence of note data and delays. So when a part of a song is repeated multiple times, the data is duplicated. The PCjr only has 128k of memory, which is shared with video memory, and your average MIDI file will be too large to fit in memory entirely.

Since that code was already done, and it worked well, even from floppy, I figured I could just replace the code for the DreamBlaster S2P with IMFC code and use the rest as-is. That way, this music disk will run even on PCs with low memory.

In the future I might experiment with data compression. I have tried Trixter’s LZ4 code on some MIDI data, and it compresses really well. For example, the Hang-On song is about 112k, but compresses down to less than 7k. That might be very interesting, especially for PCjr, since it lacks the DMA controller to load from floppy in the background.

There is not too much to tell, other than that. Perhaps that the interrupt controller uses Auto-EOI mode, as discussed earlier. And there’s two cute tricks for the graphics. The first is that I am using a cute trick that is possible in CGA composite mode 6: fade in/out. I had already used that in the sprite part of 8088 MPH. Namely, by adjusting the background colour, you can affect the luminance, so I get 4 levels of luminance to fade the screen. The second trick is made possible because of this: I start with the screen faded to black. Then I load the graphics directly from disk into CGA memory. And then I fade in. This way I do not need any graphics data in system memory at all, which again is very nice for low-memory configurations.

That’s about it for now, hope you liked it!


Posted in Oldskool/retro programming, Software development | Tagged , , , , , , , , , , , , , , , , , , | Leave a comment

The IBM Music Feature Card and Yamaha FB-01

This has got to be one of the most obscure pieces of hardware I have covered so far. A sound card for the IBM PC, released in 1987. And by none other than Big Blue themselves! I am talking about the IBM Music Feature Card:


I suppose this card needs some explanation. As you can already see from the picture, it is a large, complicated card, with a lot more components than an AdLib or a CMS/GameBlaster.

That is because the card features a full-blown MIDI sound module, with its own Z80 microprocessor. The MIDI sound module is based on the Yamaha FB-01:


The rest of the card contains a proprietary MIDI interface. In fact, the entire card is designed and built by Yamaha, for IBM. In concept, it is very similar to the later Roland LAPC-I, which is also a combination of a MIDI interface and a MIDI sound module on a single ISA card, except in that case, it is an MPU-401 MIDI interface and an MT-32 module.

For more background information, you can read the excellent coverage of the IMFC on Nerdly Pleasures.

So, it is an FM sound card then. Is it any good? Technically, yes. Where the AdLib uses the low-end YM3812 chip, with 9 voices and 2 operators in mono, this uses the more high-end YM2164, which has 8 voices and 4 operators, in full stereo. The entire card is well-made, and was quite expensive at the time, aiming more at semi-professional musicians than gamers. Here is an example of Sega’s Afterburner theme converted to FB-01/IMFC:

However, like the AdLib, the card suffers from the fact that most musicians couldn’t really be bothered to make the most of the FM synth, as discussed in an earlier blog.

Anyway, I was fascinated by this card. Firstly because it is so rare, and not supported by a lot of software. Secondly, because it is an official IBM expansion card. And lastly because apparently nobody had bothered to add support for it yet, in DOSBox. So I decided to give it a try.

Is it really a Yamaha FB-01?

The approach to emulating this card appeared to be straightforward: there is the MIDI interface, and then there is the MIDI module, which is allegedly a Yamaha FB-01. Well, as usual, with PCs, it depends on how you look at it.

The MIDI interface is reasonably simple, and it didn’t take me too long to emulate enough of it to get games to detect the card, initialize it, and send MIDI data, which I could intercept. I simply made use of the MIDI code that was already present in DOSBox for the MPU-401, and sent the MIDI data out via the same interface.

This worked, and the only way I could test it, was with a real IBM Music Feature Card, with its MIDI in connected to the MIDI out of my DOSBox machine. But when I sent out an early test-build of this DOSBox for people to test with a Yamaha FB-01, they reported problems. Some instruments were wrong or missing in Leisure Suit Larry 3. What was going on?

Different firmware, that’s what was going on. While the hardware is mostly the same (the IMFC is obviously missing the LCD display and the front panel buttons), the IMFC apparently has an updated version of the main firmware. We studied the manuals of the IMFC and FB-01 closely, and mapped out all SysEx commands. We found that the IMFC supports one command that the FB-01 does not, and Sierra was using this command.

The command in question is the “Parameter List” command. Yamaha implemented an interesting type of SysEx command, which will likely confuse a lot of modern MIDI software. They basically have variable-length SysEx commands, which effectively switch the device into a certain state, after which you can send it a variable (in theory endless) amount of custom commands within that SysEx command.

The FB-01 supports one type of this list command, which is the “Event List”. It basically switches to a Yamaha-specific proprietary extended MIDI mode, where you can send key on/off, control change, program change, after touch, pitch bender and parameter change events, which allow some fine-grained control that normal MIDI does not.

The “Parameter List” however was apparently added to the firmware after the FB-01 was released. Similar to the “Event List”, it allows a variable number of commands. These commands modify the parameters of instrument settings. The FB-01 does of course support changing instrument parameters via SysEx messages. It just does not support the list format, only individual SysEx messages.

So the fix was relatively simple: the state machine has to be implemented in the emulation code. Whenever it detects the start of a Parameter List command, it will go into the parameter list-state. Then every command is in the list is translated to an individual SysEx command on-the-fly (that last part is extremely important, the list could be virtually endless, and you do not want to buffer the whole list before you start converting it). When an end-of-SysEx is detected, it switches back out of the parameter list-state, and Bob’s yer uncle.

Funny enough, we found out that this difference between the IMFC and FB-01 was known in the old days. Firstly, apparently someone once wrote a TSR for King’s Quest 4 and related Sierra games that modified the IMFC driver to be used on a MPU-401 and FB-01 instead. When I inspected the code, I found that this driver also did the same SysEx translation for compatibility reasons.

Secondly, Sierra also provided their own FB-01 driver for some games. Ironically enough, this driver also fails with some games. Why does it fail? Because apparently they translated the IMFC parameter list incorrectly. Namely, the parameter list works on the basis of instrument number. Sierra however translated to parameter change commands based on MIDI channel (the FB-01 supports both variations). The problem here is that there is not necessarily a 1:1 mapping between MIDI channel and instrument, so some parameters are set incorrectly with the FB-01 driver.

What’s a YM2164?

Right, with the basic MIDI problems out of the way, the next big step was to actually emulate the synthesizer part, so that people would not need a real Yamaha FB-01. I wanted to go with a similar approach to Munt, which is an emulator for the Roland MT-32. A Windows driver, which installs itself as a MIDI input device, and outputs the emulated sound to your audio device in realtime. This means that you can use it as a standalone synthesizer as well, using Windows MIDI tools.

The Yamaha FB-01 is a reasonably straightforward device: it has a Z80 microprocessor, some firmware in a ROM, and a YM2164 chip. The firmware for the Z80 contains the MIDI interpreter, which takes care of all the MIDI events, manages the voice banks and configuration, and drives the actual YM2164 chip.

So I figured I could re-implement the MIDI interpreter part myself, based on the SysEx documentation. The biggest problem is the YM2164 itself. This is a very obscure chip, mainly because it was not a chip that was sold to third parties. It was only used in Yamaha’s own products, and a few Korg synthesizers. As a result, you cannot find any datasheets or manuals online, because they were never made public. I tried contacting Yamaha, but they could not provide me with the documentation for the chip either, so it seems to be lost forever.

However, we still have the internets! And as luck would have it, Yamaha actually built modules with the YM2164 chip for the MSX computer range, the SFG-05. BUT! The YM2164 is only used in the later revision of the SFG-05. Earlier revisions used the YM2151. And there is our clue!

Namely, people have studied these different modules, and they are basically identical in terms of sound and operation. Upon studying the firmware, they only found a few superficial differences, in terms of undocumented registers and timer resolution.

And unlike the YM2164, the YM2151 is a common chip, with available documentation, which was used in various arcade machines, and has proper emulation support in MAME. So we can just use the YM2151 emulation from MAME and hook it up to our MIDI interpreter, and it should be a good virtual FB-01!

This was the initial plan. However, due to other priorities, I never finished my own implementation. Recently someone pointed out that MAME actually includes an entire Yamaha FB-01 machine (which indeed uses the YM2151 emulation code to approximate the YM2164). And there is also the AMAME fork, which focuses on using MAME synthesizers, and wants to make them into VSTis.

So I tried experimenting with MAME and AMAME a bit, to see if the FB-01 actually worked. And indeed, it did! This was somewhat of a breakthrough for my IMFC emulation project. Namely, I can now offer full software emulation. There is no physical FB-01 required anymore. This makes the project a lot more interesting for the average DOSBox user.

Here is a quick video I made to demonstrate the whole thing:

Early release

So I have decided to put together a quick release of what I have so far. This is my custom DOSBox build with IMFC support, and a compiled version of AMAME to offer you an emulated FB-01 to complete the chain. You can download it here.

In order to set it up, you need to do 3 things:

  1. AMAME needs two ROMs for the FB-01 emulator, which I did not include because of copyright issues. You will have to find them yourself. One is the FB-01 firmware, which should be in a file called The other is the firmware for the LCD controller, which should be in a file called Place those two files in the ‘roms’ subdirectory under AMAME.
  2. DOSBox needs to be configured to output to the correct MIDI device. In this version, there is no IMFC-specific section in the dosbox.conf file yet. I am re-using the MPU-401 configuration. So set up the MPU-401 as usual: under the [midi] section, you use the midiconfig=n option, where n is the index of the MIDI output device you want to use.
  3. AMAME also needs to be configured to get input from the correct MIDI device. This is done by name. Run “amame64 -listmidi” to get a list of the names of the possible MIDI in and out devices. Then use the -midiin and -midiout parameters to pass these names. I have included an FB01.bat as example, just change the names to the name of your device, and you should be up and running.

A loopback will be required between the MIDI out-device that DOSBox uses and the MIDI in-device that AMAME uses. I have tried LoopBe1 and loopMIDI, but found problems with both. The first seems to filter SysEx commands, which effectively filters out custom voice data from games, which makes it rather useless. The second seems to crash the FB-01 on large SysEx commands. I ended up using my E-mu 0404 USB interface with a physical loopback cable between its MIDI out and MIDI in ports. This works perfectly.

You could also use a real Yamaha FB-01 instead of AMAME of course.

Make a demo about it

The emulation still needs some work (it currently does not fully emulate the 8253 timer on the IMFC yet, MIDI in is not working yet either, and not all commands are fully implemented yet). But in its current state it should be good enough for all Sierra games at least.

I also still want to complete my own virtual FB-01. Firstly, because it should be more convenient to use than AMAME. Secondly, because my code will be a clean reimplementation of the MIDI interpreter, and will not require any copyrighted ROMs.

But for now, I think it is most interesting that the IBM Music Feature Card is now available to a much wider audience. And the next thing I want to do is probably some simple demo/music disk, targeting an 8088 at 4.77 MHz with CGA and an IBM Music Feature Card.

Posted in Oldskool/retro programming, Software development | Tagged , , , , , , , , , , , , , , | 1 Comment

The DreamBlaster S2P: General MIDI from a parallel port

In the interest of catching up, here is the second blog that is long overdue. I want to talk about the DreamBlaster S2P from Serdaco. I received mine over a year ago, and it actually was an early prototype.

The DreamBlaster S2P is based on the DreamBlaster S2 WaveBlaster module. It uses a Dream SAM2695 synthesizer chip. This chip has two MIDI interfaces. The regular DreamBlaster S2 uses the standard serial MIDI interface. The DreamBlaster S2P makes use of the special parallel interface, which allows you to send MIDI data one byte at a time over a parallel bus, such as an ISA bus, or in this case a printer port. It uses a similar approach to the OPL2LPT and OPL3LPT.

When I got it, it was still in the early stages of development, and nobody managed to get it to work properly yet. I tried a few things to see if I could get it working, but sadly it didn’t work. As it turned out, a patch wire was required. Pdewacht got it to work eventually, and he modified SoftMPU to support the DreamBlaster S2P. Based on his working code, I could get mine to work as well. In the final version that is now available, the problem with the patch wire is fixed in the design. A reset button was added to the design as well.

So what can you do with it? Well, the most obvious use case for now, is to use SoftMPU to play games with General MIDI support over an MPU-401 interface. This requires a 386 or better CPU. This is a very early video made by Serdaco when the device was working with SoftMPU for the first time:

The SAM2695 also has an MT-32-compatible mode, and I added a patch to support it in SoftMPU. Here are two early videos I made, to demonstrate.

The first video is an early test, where I use my own MIDI player with a captured MIDI file from Monkey Island (a game with MT-32 music, not General MIDI). First you hear it in General MIDI mode, then you hear it in MT-32 mode:

Pay no attention to the haphazard timing, it was still an early version of the MIDI playback routine. What you can hear is how the instruments sound very wrong in General MIDI mode. In MT-32 mode, the instruments sound much more like how the composer intended.

The second video is with my modified SoftMPU, running the actual game in MT-32 mode:

Also, like with the OPL2LPT, it is possible to patch native support into games. This means you will not need SoftMPU, so you also will not need a 386 or higher if the game does not require it. It can also work with protected mode games, which SoftMPU does not currently support. You can find S2PPATCH here. It currently works with DOOM and other games using the same sound engine (Heretic, Hexen, Raptor: Call of the Shadows, etc.), and with games that use the Miles Audio Interface Library, both 16-bit and 32-bit.

Going retro

However, I think the most interesting application of this device would be with newly written games, demos and other software. The same goes for the OPL2LPT and OPL3LPT. If you write new software, and you already want to support MIDI/OPL2/OPL3 music, it is trivial to add native support for these devices. You will not need SoftMPU, and you will not require a 386. The parallel port protocol is very simple, and takes barely more CPU time than a regular ISA device. So even on an 8088 at 4.77 MHz, these devices are a very realistic target, when used natively.

So I decided to add support for the DreamBlaster S2P to my MIDI player, and tried it on an 8088:

That worked quite well. All the complex timing is precalculated into a simple stream of delay values, adjusted for the PIT resolution, and blobs of MIDI data to send directly to the interface. No problem for an 8088.

So I decided to see if I could go even more low-end. I fine-tuned my assembly-optimized player routines, so they could run on my 128k IBM PCjr:

Even that works fine! It actually streams the data from floppy, because the MIDI file was too large to fit in memory. If you listen closely, you can hear the floppy drive reading the next bit of data. Because the PCjr does not have a DMA controller, it actually pauses the music for a bit. On a regular PC, the read would have happened in the background, and the music would continue playing. I suppose there are only two ways to avoid that: making smaller MIDI files, or using compression to be able to fit everything into memory, and decompress on the fly.

Basically, as far as sound devices for oldskool machines go, I would say that the DreamBlaster S2P is by far the best option on the market. It is cheap, and its sound quality is well above FM synthesis, comparable with General MIDI devices such as the Roland Sound Canvas. And because it is a complete synthesizer chip with built-in MIDI interpreter, it also has an extremely low CPU load for playing music. Much lower than an FM chip. So you have low cost, ease of use, good quality and light on resources. That is a tough act to follow.

Also perhaps good to point out: although these devices come from the DOS scene, they can obviously be used on any machine with a standard Centronics parallel port implementation. In fact, you could probably adapt the interface to various other bus types quite easily as well. All you need is an 8-bit parallel data bus (write-only is enough), and a few control lines that you can toggle (2 to 4 lines is enough). I can imagine a simple adapter for a Commodore 64 userport for example.

Serdaco SDK

To help others to support the Serdaco LPT interfaces, I dediced to make my routines available, in a simple Serdaco SDK. This contains some C and ASM code to initialize the devices and send data to them. It should make it very easy for people developing their own games and demos to add support for these devices.

I have actually had this idea of an oldskool DOS SDK for much longer. I have collected a reasonable amount of code for low-level hardware access on early PCs during my travels. The current Serdaco SDK is a subset of that. I want to release a bigger SDK at some point, which also includes support for regular OPL2, OPL3, SAA1099 (C/MS and GameBlaster), SN76489 (PCjr and Tandy), Sound Blaster, IBM Music Feature Card, Roland MPU-401, CGA, EGA, VGA, MDA, Hercules and related stuff.

I am basically trying to model this somewhat after the Amiga NDK. This is a collection of headers for C and ASM for the Amiga, with definitions for all the custom chipset registers and flags, and also the Kickstart and WorkBench libraries. I want to do the same, but for DOS-based PCs. It should bridge the gap between reading some technical manuals and getting the proper values for registers and such in actual code. I also want to include some basic helper functions and example code, so people can experiment with some code that is known to work on real hardware, and get up and running more quickly. I hope it will also aid the problem of people only developing on emulators, and creating code that doesn’t actually work on real hardware.

Posted in Hardware news, Oldskool/retro programming, Software development | Tagged , , , , , , , , , , , , | 1 Comment

Keeping it real for Outline 2018

It’s been a while, but I’m back. Or at least, I hope to have some more time to blog again from now on. And not just to blog, because many of my blogs are the result of experimentations with software and hardware. So I hope to have time to experiment, write new demos, and generally play around with stuff.

First things first though… A backlog of items has accumulated in the past silent months. And it occured to me that I never even wrote a blog about my last demoscene production, which was the invitation for Outline 2018, released at Revision 2018:

Granted, it is not too spectacular… Some graphics, a nice animation, and just a simple text writer with vertical scrolling, accompanied by some OPL3 music. But still, I’d like to describe some of the development behind it.


The music was done by Diode Milliampere in Adlib Tracker II, making fine use of the OPL3 functionality. Getting the music to play was a technical challenge. Adlib Tracker II may be open source, but it is written in Free Pascal. This makes it difficult to interface with other languages such as C and ASM, which I prefer. The code also requires 32-bit DOS or Windows.

Initially I went looking for an alternative player, and I found a routine in C. There were some problems with it though. The code was rather outdated, which meant it was not compatible with the later versions of AT2. One problem was that AT2 switched to a different compression algorithm. I tried porting the Pascal code for the decompressor myself, and eventually got it working.

However, because of the way the format is designed, you need huge buffers to decompress the pattern data, and the format is also extremely wasteful. Storing entire patterns in memory works fine when you use 4-channel mods, with 64 rows per pattern. However, OPL3 is 18 channels, and AT2 supports higher resolution patterns, up to 256 rows each. This means every single pattern takes up about 130k in memory, so things get very memory-hungry fast.

The same goes for the macro feature that the format supports. This has similar memory-hungry buffers. In short, just to decompress an AT2 file, you already needed about 5 MB of memory. So 16-bit was never going to be an option. I tried skipping the macro feature, and using some simple compression scheme for the pattern data (a lot of values tend to be 0 in every row, so you can store it efficiently by just making a linked list of the used data, and skipping the unused rows). It did eventually play some simple files in 16-bit mode, but you quickly ran out of memory still when there was more pattern data.

Another problem is that the replayer logic is also rather time-consuming with all the instrument and effect parameters running over 18 channels. The lower bound for playing AT2 files is more or less a 486SX-25.

So, I figured that it might be better to just go with my own preprocessing VGM player, which is at the other end of the spectrum in terms of CPU and memory usage. I just captured the music with DOSBox, and used the preprocessed capture data in the demo.


The graphics effects are rather simple. The main text is just a Mode X screen, where I scroll vertically by just updating the screen offset. I simply draw the next screen of text to the page that is currently invisible.

The other ‘effect’ is the animation at the start. This animation was drawn by visionvortex. He supplied it as a set of PNG files. I simply include all raw pixeldata in the EXE file, and copy the frames to the screen one by one, with the appropriate delay. Nothing fancy.

Final version

The party version was rather quick and dirty, but we wanted to release it at Revision anyway, because its goal was to invite people to the Outline party. It worked, but there was a small bug in the initialization routine for the OPL3 chip, which messed up the music.

Another problem was that the animation had quite a few frames, so it took up a lot of memory. This led to an EXE file of 1.7 mb. It also meant that I had to make it a 32-bit DOS release.

In the final version, both things are fixed. The music now sounds the way Diode Milliampere intended it. And I implemented my own simple Mode X RLE compressor and decompressor for the animation frames. The compression worked incredibly well on this animation, so the resulting EXE is only 87 kb. This meant that I could also make the code 16-bit, and fully 8088-compatible.

Posted in Oldskool/retro programming, Software development | Tagged , , , , , , , , , | 5 Comments

An emulator that 8088 MPH doesn’t break?

Breaking news! Or actually non-breaking news!

Just now I have managed to run 8088 MPH in an emulator for the first time, with all effects showing, and giving a reasonably accurate rendition of real hardware. The emulator is 86Box, and I have created a simple ZIP file here for you to try it. Everything should be pre-configured. Just wait for DOS to boot (can take a while), enter the date and time. Then type:

b: <enter>

8088mph <enter>

And you should be good to go. It’s not entirely perfect, the timing seems to go up and down a bit, the cycle-exact end-tune seems to play too fast. But it’s the best I’ve seen by far, and a lot better than nothing.

Posted in Oldskool/retro programming | Tagged , , | 9 Comments

Read any good books lately?

Recently, I have written a few things about Agile methods and Scrum. I feel that they are not the solution to everything, because in certain scenarios they have severe risks and drawbacks. I warned about how certain (sub-)problems cannot easily be solved in an iterative fashion, and require proper thinking, design and perhaps even prototyping before you move into Scrum.

Now, I have been reading the book “Requirements Engineering” by Axel van Lamsweerde. I did not expect the topic to pop up, but there it was. And in retrospect, it makes sense: requirements engineering is very closely related to the problem I was describing. You would not generally take a Scrum-approach, but you’d rather have a more spiral approach, where you refine your results in ever larger iterations (much like how you would first develop a prototype with a small team, and then refine it to the end-product with a larger team).

Van Lamsweerde does one better than that, however. He specifically goes into Agile development and points out that Agile methods only work under specific assumptions. In other words: they should only be applied in specific scenarios, and are not the solution to everything. He lists the following assumptions:

  1. All stakeholder roles, including the customer and user roles, can be reduced to a single role.
  2. The project is small enough to assign to a single small-size team on a single location
  3. The user is available for prompt and efficient interaction.
  4. The project is simple and non-critical enough to give little or no consideration to non-functional aspects, environmental assumptions, underlying objectives, alternative options and risks.
  5. The user can provide functional increments quickly, consistently (so that no conflict management is required) and gradually from essential to less important requirements (so that no prioritization is required).
  6. The project requires little documentation for work coordination and subsequent product maintenance. Precise requirement specification before coding is not an issue.
  7. Requirements verification before coding is less important than early release.
  8. New or changing requirements are not likely to require major code refactoring and rewrite, and it is likely that the people who develop the product, will also maintain it.

He specifically points out that mission-critical software is one area where agility is a poor fit. He also points out that ‘agility is not a binary notion’: For each phase of the project, you can choose to use less or more agility, depending on what is required for that phase. I think this is quite interesting, because Scrum-consultants seem to claim the exact opposite: any derivation from the strict rules of Scrum is considered a ‘Scrumbut’, and they always advise to apply Scrum more strictly.

Now, getting back to the example I gave earlier, where the team developed a system based on queues, where they should have used a database… Quite a few of the 8 above assumptions did not apply in that scenario, so Scrum was a poor choice from the start. The queues-vs-databases example itself immediately points to a violation of assumption 8: major code refactoring was required because of the ‘new’ requirements for prioritizing. But also, the project was a very mission-critical project for the customer. It was also a fixed-price, fixed-deadline project. This would violate assumption 4. The customer was in another country, so 3 did not apply either. I would also say that at least assumptions 1 and 6 were violated as well.

When I first heard of Agile and Scrum, it was mostly related to web-application development. And in retrospect, this makes sense. I suppose (small) web-applications tend to be a reasonable fit for Scrum. However, as we also discussed in the comments of the earlier articles, there are also projects that are highly technical and experimental in nature, and they are a very poor fit for Scrum. A spiral-like approach is much more natural there, where one or two people start by collecting the requirements, and iteratively working out the risks and problematic areas, perhaps developing some proof-of-concepts/prototypes during that time, and then refine the requirements, design etc, so that the project will gradually mature, and it starts making sense to add more people to the project, because there are now reasonably well-defined goals and workloads to be distributed.

The irony of it all, is that Scrum never claimed to be the solution to everything. Take the original paper by Ken Schwaber: Figure 6 clearly shows the Scrum Methodology, defining 3 different phases:


  1. Planning & System Architecture (Pregame)
  2. Sprints (Game)
  3. Closure (Postgame)

The way phase 1 and 3 are drawn in the figure, show that they are not really part of what Scrum is about (the sprints). They are shown in a way similar to the Waterfall methodology in Figure 1.

Schwaber further remarks:

The first and last phases (Planning and Closure) consist of defined processes, where all processes, inputs and outputs are well defined. The knowledge of how to do these processes is explicit. The flow is linear, with some iterations in the planning phase.

So basically Scrum never meant to solve everything with sprints. Not the planning, not the (intial) requirements, and not the system architecture. For some reason, everyone seems to have forgotten about this, and thinks Scrum is about doing everything in sprints, even all the design. That is a recipe for disaster with any non-trivial project.

Anyway, it’s always nice when your findings are confirmed independently by academic sources.

Posted in Software development | Tagged , , , , , , | 2 Comments

Intel tries its hand at a discrete GPU again?

As you may have heard a few months ago, Intel has employed Raja Koduri, former GPU-designer at AMD’s Radeon division. Back then the statement already read:

In this position, Koduri will expand Intel’s leading position in integrated graphics for the PC market with high-end discrete graphics solutions for a broad range of computing segments.

But at the time it was uncertain what exactly they meant with ‘discrete graphics solutions’, or what timespan we are talking about exactly.
But now there is the news that Intel has also employed Chris Hook, former Senior Director of Global Product Marketing at AMD.
And again, the statement says:

I’ll be assuming a new role in which I’ll be driving the marketing strategy for visual technologies and upcoming discrete graphics products.

So, there really is something discrete coming out of Intel, and probably sooner rather than later, if they are thinking about how to market this technology.

See also this article at Tom’s Hardware.

I am quite excited about this for various reasons. It would be great if NVIDIA would face new competition on the (GP)GPU-front. Also, Intel was and still is Chipzilla. They have the biggest and most advanced chip production facilities in the world. I’ve always wondered what an Intel GPU would be like. Even if their GPU design isn’t quite as good as NV’s, their manufacturing advantage could tilt things to their advantage. I’ve also said that although Intel GPUs aren’t that great in terms of performance, you have to look at what these chips are. Intel always optimized their GPUs for minimum power consumption, and minimum transistor count. So they only had a handful of processing units, compared to the thousands of units found on high-end discrete GPUs. The real question for me has always been: what would happen if you were to take Intel’s GPU design, and scale it up to high-end discrete GPU transistor count?

Perhaps we will be seeing the answer to this in the coming years. One other thing I had pointed out some years ago, was that Intel appeared to have changed course in terms of drivers and feature support. In the late 90s and early 2000s, Intel really had very minimal GPUs in every meaning of the word. However, when DirectX 10 came around, Intel was reasonably quick to introduce GPUs with support for the new featureset. Sadly it still took months to get the first DX10 drivers, but they did eventually arrive. It would appear that Intel had ramped up their driver department. DX11 was a much smoother transition. And when DDX12 came around, Intel was involved with the development of the API, and had development drivers publicly available quite soon (way sooner than AMD). Intel also gave early demonstrations of DX12 on their hardware. And their hardware actually was the most feature-complete at the time (DX12_1, with some higher tier support than NV).

Let’s wait and see what they will come up with.

Posted in Hardware news | Tagged , , , , , , | 7 Comments