Nitemare 3d for DOS

Today’s game is called Nitemare 3d and was made by Gray Design Associates back in 1994. The company basically consists of one guy, David Gray, who was better known for the adventure games he made. The first being Hugo’s House of Horrors. Nitemare 3d has the same main character, Hugo, who in this game must rescue his beloved Penelope from Dr Hammerstein. It’s in the first person perspective, although I hesitate to call it a shooter, you do have to fight a number of enemies with guns.

Because of the very limited amount of time I’ve had lately, I could only get to the fourth level of the first episode (the shareware one). Gemini of ADG had more of a chance to play it and you can see his review here.

Graphically the game uses a ray casting engine to produce a 3d texture mapped environment, basically the same type as that found in Wolfenstein 3D. The engine run fairly smoothly and has the addition of animated wall textures, but isn’t quite as smooth as Wolf3d. Artistically it doesn’t look as polished as commercial or shareware from a larger software company, but it has it’s own charm and is consistent in its presentation. Some of the death animations in particular are amusing, such as one enemy turning into a flower in a pot!

Sound design is fairly similar in the sense that it’s not as polished as games produced by larger teams, but again it has it’s own charm. The Adlib music is decent and can be quite catchy, it fits the feel of the levels quite well and seems to make quite good use of the card. Digitised effects are used for all the usual game sounds, some are better than others such as the gun shot, but other don’t work as well.

The game controls in pretty much the same way as other shooters from the time, with the addition of a key for slow movement as well as fast. This is sometimes needed as the collision detection requires you to hit almost dead centre, with many shot missing appearing to travel through enemies. You can still land shots, but it’s not as intuitive as it should be.

The weapons mostly fire projectiles that move visibly through the air (except for the revolver with silver bullets) and can end up being blocked by scenery nearby even though the shot itself is passing through empty space. Enemies have no such issues as they fire instant hit weapons, so if they can see you they can shoot.

Whilst the enemies have an advantage in terms of shooting, they are fortunately relatively easy to deal with. The enemies don’t seem to really be the main challenge of the game, at least in the levels I’ve played. The levels are very maze-like and contain many hidden panels which you have to find in many cases in order to progress. I’ve spent more time searching and wandering the levels than doing much active shooting.

Luckily unlike many other early first person games there is an auto-map function. You have to collect magic eye power in order to use it however, which means you’ll have to use the map as sparingly as possible. You can also collect crystal balls which will plot the enemies on the map for you as well, which can be useful in working out roughly where to go next. Both use their power up over time, but can be toggled off and on as you need them.

Another feature to help you find the secret panels is the magic eye icon in the status bar. When you’re looking at a hidden panel one of the middle pixels light up as long as you have some magic eye power left. This is really handy when you suspect a hidden panel is nearby, but is harder to notice during normal game play. This however doesn’t seem to help when finding destructible walls.

So far I’ve found Nitemare 3d a difficult to place game,  it’s definitely not a bad game, but I would have preferred less secrets, or ones not necessary to progression at least. The main reason I stopped at level 4 was simple, I couldn’t find the panel necessary to progress further. After much searching I gave up. The designer, David Gray, even put a walk-through in with the registered version to help with the more difficult to find secrets. All that being said I did enjoy the time I was playing it.

So do I recommend it? Well that depends. If action isn’t as big a deal to you, maybe you’ll enjoy it. If you’re more into shooting bad guys, maybe this isn’t for you. I suggest tracking down the walk-through to make your life easier. Play the shareware episode first and if you like it, David Gray still sells it on his website for about $12 USD.

This slideshow requires JavaScript.

On-Board graphics

Most computer enthusiasts instinctively know that on-board graphics doesn’t perform as well as a discrete graphics card, but why isn’t common knowledge. Today I’d like to shed a little light on why this is.

However don’t take this as a criticism of on-board graphics, as they have their place within the industry to provide lower cost solutions for people who don’t need the ability or can’t afford the cost of a GPU card. AMD in particular have had some very nice graphics processors on-board or on-chip and their current line up of APUs does offer very good performance per cost.

I won’t be talking about any specific hardware, as there is just too much to cover. I’ll be talking about this in a more general sense.

Here’s a little diagram of how on-board graphics are usually connected to the main system memory and CPU. Where these components actually reside depends on the age of the system. Modern APUs contain everything in this diagram (and more) except the main system memory, older systems had the memory controller and GPU in the North bridge chip on the main board. Some older systems had a separate graphics chip that utilised the main system RAM, and others actually integrated some VRAM on the board. Boards with separate VRAM are completely different beasts, and actually have more in common with systems that have a discrete graphics card.

This story in fact starts off way back in the micro computer era of C64 and ZX spectrum, which essentially had integrated graphics. The graphics chips took up much of the memory bandwidth, essentially slowing down the machines CPU quite severely under certain conditions. Modern PCs with on-board graphics also usually share the system memory with the GPU, and this is where the performance hit usually originates from.

Firstly there is an un-avoidable loss of memory bandwidth in the form of video signal generation. All graphics processors have to actually output to a screen at some point, and this requires reading the entire frame buffer and outputting appropriate data to the screen. This is as true for HDMI and DVI as it was for old school CRTs, except the resolution and colour depth have increased.

Lets take an example, say 1920×1080 at 60Mhz with 32 bit colour. For every frame sent 8,294,400 bytes have to be read (the size of the frame buffer). Do this 60 times a second and you get 497,664,000 bytes per second or about 474.6 MB/s just to output to the screen. Whilst it’s not a huge chunk of the minimum 6400MB/s that DDR3 can deliver, it certainly will reduce the available memory bandwidth to the processor, lessening its potential performance.

On-board GPUs have a significant advantage in some areas, such as the CPU being able to write (draw essentially) directly to the frame buffer, and the GPU being able to read texture data directly from system memory. However this convenience isn’t all roses as we will see.

Lets consider a rendering situation, where the GPU needs to render a number of polygons into the frame buffer. To make it simple lets make the squares of 32×32 pixels (buffer size of 4Kbytes) and we’re going to render a number of them onscreen say 500,000 per frame, now you’re looking at copying 2,048,000,000 bytes which requires both a read and a write, so really in terms of memory bandwidth that’s 4,096,000,000 or about 3.82Gb.

This is a bit of a contrived circumstance, but you can see that it’s easy for a GPU to chew up memory bandwidth when it’s rendering. This can have the effect of starving the main CPU of memory bandwidth forcing it to run slower than it could have otherwise (and vice-versa). In practice that much bandwidth probably wouldn’t be needed as modern CPU and GPU designs incorporate caching, which works very well until you start dealing with data sets larger than the cache. In this case if we were copying the same bitmap repeatedly we could half the bandwidth required as the whole bitmap could be stored in the cache.

So how does this differ from a discrete graphics card?

Here’s another diagram showing how they usually fit in. The graphics card basically contains everything on the right, with the IO interface being the only means of communication with the computer.

Since the graphics card has its own memory the system isn’t burdened with output of the video signal. This graphic memory is usually dual ported, or in the case of modern GDDR5 which is capable of accessing two pages of memory simultaneously (effectively dual ported although only having one). This turns out to be important as it allows both the GPU and CPU to access the video memory at the same time, which reduces latency when writing to the video memory. This used to be a big problem with CGA, EGA and earlier VGA graphics cards that didn’t have dual ported memory and the CPU had to wait for the video signal to access the graphic memory.

This graphic memory also has the distinct advantage that when the GPU is rendering a scene it doesn’t slow down the main processor by consuming the system memory bandwidth.  It does however require the CPU to communicate via the IO bus to issue scene data and rendering commands. Most scene data (textures and meshes) are pre-loaded into the graphic memory so the load on the IO bus is minimised.

The only real disadvantages of the discrete graphics card are slightly increased loading times, and slower access to Graphic memory. Longer loading times arise from the need to pre-load the scene data to the graphic card, whilst the IO bus can be exceptionally fast, the logic in the graphic card and the speed of the system and graphic memory limit the throughput. There’s also usually lots of data to upload, in the realm of gigabytes these days.

I hope this goes some way to at least beginning to explain why on-board graphics as they are implemented now won’t achieve the same performance as a system with equal but separate parts. It’s mostly the fact that system memory is shared between the two that hampers both the CPU and GPU from achieving maximum performance. If in the future AMD or Intel were to change their chips such that the GPU on-board had its own separate bank of memory, you’d start to see on board graphics become more competitive with graphic cards. This would require either dedicated memory on the main board or an extra socket for it which would add to the cost, so I feel that would be unlikely. After all on-board graphics is all about reducing the cost.

Motherboard: Biostar M6TBA

Today’s motherboard is from a Taiwanese manufacturer called Biostar Microtech International (know as Biostar for short). They are one of the old guard of PC motherboard manufacturing having started in 1986, although until finding this board I haven’t used much or any of their hardware. In the past Biostar have made boards for OEMs as well as the high-end, mid and lower-end of the market. These days they seem to be focusing on higher end parts. This particular example is a M6TBA ver 1.3 which from the date codes on the board appears to be made in 1998.

Here’s an overview of the board.

It supports slot 1 processors up to 800 Mhz surprisingly, this would have been faster than any of the Pentium II chips available at the time. It was probably a forward looking design, perhaps with the capability to support a Pentium III in a slotket, although this isn’t documented in the manual. The slot 1 system was implemented by Intel for a few reasons, but mainly they wanted to move away from the ageing socket 7 standard, partly because it was limiting the memory bandwidth and partly because it was used by many of their competitors.

They initially designed another socket, which was called socket 8, this saw limited production as there was a problem with how the cache was integrated onto the CPU. It actually had two separate dies on the one package, which proved to be a production problem that increased wastage when either a cache die or processor die turned out to be faulty. The slot 1 design solved this problem by putting the CPU and cache in separate packages on an installable module. They did miss an opportunity to put the voltage regulation on the module, which would have made the slot 1 more flexible and future-proof.

The board is pretty standard fair for it’s time, having an Intel chipset ( 82243bx being the north bridge) with PCI, ISA and AGP slots, which were all fairly standard for the time. It supports up to 384MB of RAM in three 128MB SDRAM modules, which was quite alot of memory at the time. Many people had 64Mb-128Mb.

Here’s a close up of the front panel header and the CPU configuration jumper block (the ones with yellow jumpers). The front panel is marked, adequately,  but not really nicely. The CPU configuration block has no markings at all, requiring you to look up the manual, which luckily is still available. Looking at this block it is unclear what speed of CPU was installed, as according to the manual these settings don’t match any of the speeds. Perhaps the board can detect the speed automatically.

 

An unusual feature of this board is the un-populated footprint next to the main power supply connected. It looks like a large heatsink was to be attached to the board with a linear voltage regulator, something you don’t normally see. It could be leftover from when the board was in the prototype phase, and thus not used in production, but still on the layout. Whatever the reason, the size of the heatsink foot print leads me to believe it was going to be dealing with a significant amount of power.

Speaking of power supply, check out the bulk capacitors next to the CPU slot.

Some of the capacitors are visibly bulging, a sure sign they are failing. Sometimes a board will continue to function like this, but it usually means the board is about to fail. You can replace these components, but it’s tricky soldering on these multi-layer boards, it’s easy to damage them. It’s something I haven’t been brave enough to attempt yet.

Another interesting feature is this chip here, an SMC FDC37M602. It’s a Super IO chip which integrates floppy disk controller, serial ports, PS/2 ports and a parallel port. It’s quite some distance from the boards floppy connector, so I’d say the chipset is supporting that, at a guess I’d say this chip is driving all the rear port with the exception of the USB ports.

The thing I noticed however was the copyright notice on the chip, the date reads 1994 from a company called American Megatrends, a software house known for writing BIOS ROMs for PCs. This particular board however uses an Award BIOS which of course comes from a rival company! Not so much a technical achievement, but interesting to see.

Beginning to sum up this board, it’s not really ideal for the technician working on it. Mostly due to the CPU configuration jumpers having no markings at all. Otherwise it’s very similar to working on other boards of the same vintage. This would have been a more expensive board at the time, mostly because Intel boards and CPU’s tended to be more expensive. It has lots of standard slots allowing for upgrades and expansion. So it’s not all bad, just a bit inconvenient to change CPU with.