Author Archive for Andrew Danson

09
Oct
18

Wolfenstein 3d for DOS

Todays game is very well known, and can be considered the grand father of the FPS genre. Wolfenstein 3d was released by id software in 1992. It was extremely popular, selling both in the retail and shareware markets, and received several significant awards. The engine was licensed out and resulted in a number of other games, some I’ve already covered such as Blake Stone and Corridor 7. It inspired others to make similar engines and games of their own such as Nitemare 3d and Ken’s Labyrinth. In this way it really spawned a whole generation of FPS games.

It wasn’t without controversy, partly because of the Nazi imagery used as well as the Nazi party anthem being used at the title screen. Because of this some rules were changed in Germany which resulted in the game and some other media being banned there until quite recently. It was also quite violent compared to contemporary games, although looking at it today it is comparably tame.

Today is actually the first time I’ve really sat down and played through a significant portion of Wolfenstein 3d. I’ve had brief encounters with the game in the past, but never really sat down and spent some time with it. I played through the entire shareware episode in a little over an hour total play time.

You need a VGA graphics card and at least a fast 286 machine. I’ve found that 3000 cycles in Dosbox (roughly a 20Mhz 286/386sx) is sufficient to run the game with the maximal screen size and a smooth frame rate. I quite like the art style, the UI elements are generally very minimalist in a pleasing way whilst sprites and textures are detailed and make good use of colour. It’s impressive in both an artistic and technical sense.

The sound effects are a mix of digitised and adlib sound effects, which generally sound quite good. Although it seems that it can only play one digital effect at a time, which can result in odd sound when in a noisy situation such as lots of nearby enemies. The adlib music is quite good and adds quite a bit of atmosphere to the game. Although I was startled to learn the music used at the title screen is the Nazi party anthem.

There are three different options for control, keyboard, mouse or joystick. I used the keyboard for my play through, mainly as I did it on my macbook. The keyboard works fairly well mostly, but sometimes doesn’t have the aiming precision sometimes. Using the mouse and keyboard works much better, but it wasn’t an option for me this time.

The game play is pretty simple, basically you search a maze like level for the level exit. Along the way you have to gun down enemies, pick up ammo and health as needed, and collect various score items. There are some locked areas which require a key, which are usually found simply by exploring a level.

Because of their maze like structure and how many areas look similar it can be easy to get disoriented and totally lost. There is a simple maze solving algorithm that can help, simply stick to walls on either the left or right hand side. This works well for the majority of the levels, only slipping up where there is a loop in the maze.

Guns are an important part of every FPS game, Wolfenstein 3D has 4 basic weapons. The knife, pistol, sub-machine gun, and a rapid firing chain gun. The best weapon for most use is the sub-machine gun as it’s fast firing, but not so fast as to chew up all your ammunition. The chain gun tends to eat ammunition too fast, so is only really useful when fighting the bosses or a large group of enemies. The pistol and knife are basically starter weapons for when you’re low or out of ammunition.

So how does Wolfenstein 3d hold up today? I’d say it holds up fairly well, although there are some issues. The game play works very well, but does get repetitive after a while. The levels are generally well designed, with secrets to find and plenty of bad guys to shoot, however many areas look the same so it’s easy to get lost. I also found I had to wander empty levels after killing most bad guys but having to retrieve a key or find a locked door. On the other hand the guns are still fun to use, it still very atmospheric, and blasting through the levels is still quite fun. Later episodes shake things up by adding new enemy types and are more difficult.

You can play Wolfenstein 3d online at the internet archive, or you can get a copy on steam or GOG.

This slideshow requires JavaScript.

Advertisements
03
Sep
18

SS20 Desktop: Basic Web Browsing

Last time I looked at the relative performance of the CPU modules I have on hand, the HyperSPARC running at 90Mhz seemed to be the best option for using the machine in a workstation role. Today we begin to test this out by trying to browse the web. This sounds simple, but it’s actually quite challenging to do for a vintage machine as web browsers tend to require lots of graphics processing and there are very limited options available.

I have managed to get three basic web browsers compiled and working, Lynx, Links and Dillo. I’ve tried building others that are light weight with little success, more main-stream browsers such as firefox are simply too demanding to even try. Three potential candidates for future build attempts are ELinks, Midori and Netsurf.

The first program, lynx is one of the older programs, started in 1992 by students and staff at the University of Kansas it is still updated today. It runs from a terminal and has no graphical capability, because of this it is quite useful for vision impaired users as it works well with screen readers. You would be forgiven for thinking that lacking graphical display is a hindrance on the modern web, but lynx manages to make most pages quite readable. Well behaved/designed websites generally work quite well with some compromises on formatting, I tried google searches, reading on wikipedia and several wordpress blogs which all worked quite well. I was even able to use it to read my email via gmail. Unfortunately there are also plenty of sites that aren’t friendly to lynx (such as ebay), and page formatting isn’t always nice to read. These issues stem mostly from sites that haven’t crossed over to HTML 5, or ones that over use complex formatting. It performs quite well on the Sparc Station.

Links whilst having a similar name is a completely separate project to lynx. It offers the capability to run in a text-only terminal in much the same way as lynx, but can also be used graphically via X, SVGALib, or a frame buffer directly. This makes it quite useful on machines that don’t have a working X server. Much like lynx, well behaved websites are very usable and generally work quite well, again with some formatting compromises. It handles page formatting roughly as well as lynx does, but with the addition of images. This makes some websites like ebay more usable, although the formatting is still wonky at times. I’ve had gmail working on it in the past, but not today due to the current build or changes to gmail.

Example image of Links dithering capability

Dithering example

Performance on the sparc is pretty good, with short delays when images are being displayed for the first time. This happens because my sparc has an 8-bit display and Links will convert images using dithering and colour approximation. To maximise the number of colours it can use Links uses something called a private colour map. This is why other windows have their colours messed up whilst Links is in focus and vice versa. This sounds like it would result in poor image quality, however links manages this conversion quite well. The loading delay would certainly be shorter on 24 bit displays.

Dillo is a light-weight browser with a GUI that looks much more familiar for most users. It requires much more computing power compared to the others, but as a result it tends to display web pages with formatting closer to what you’d expect from the page. I found that many pages worked quite well, but others failed to display anything at all. It seemed to be an issue with SSL, I have the root certificates installed, but it still believed all connections had invalid certificates when clearly they didn’t. However you can see from the screen shot, that sites like wikipedia render exceptionally well.

Performance on the SparcStation unfortunately is quite slow, mostly whilst loading a page. Dillo can consume so much CPU as to even starve the X server of cycles, making it appear the system has frozen (when it hasn’t). From what I’ve read this could be because Dillo is multi-threaded, and is probably starting a number of threads upon loading a page. It may run significantly better on systems with more than one CPU, in my case switching to using the SuperSparc modules would possibly solve this.

Browsing the web on such an old machine was never going to be easy, some things just aren’t feasible such as javascript and video content. However it actually works reasonably well for reading static web pages and doing basic interaction such as posting a comment. Of the three browsers I’ve tried so far I think Links is probably the most usable, it provides images and formats pages reasonably well without consuming too many CPU cycles. Lynx comes second only because it doesn’t show images, it is a good option for text only browsing. Finally Dillo is probably just a smidge too demanding for my particular hardware and fails ungracefully with some sites, although it does provide the prettiest render you also have to wait the longest.

30
Jul
18

Bob’s Fury progress update

You may have noticed that I’ve been playing with a number of homebrew MS-DOS games lately. This has given me a little more motivation to work on my own project, my simple flick-screen platform game Bob’s fury.

The main body of work left is to create the levels for the game and any content required for them. For me this has been the hardest and most time consuming aspect of making the game as it requires a lot of play testing and planning. Recently whilst visiting my folks I had some time to produce a new level, I’ve updated the download to include it.

I’m hoping that it won’t take as long to build the next level, I got one pretty decent tip from watching some interviews of Brenda Romero. Basically the tip is starting at the end/goal and build outwards from there. I had been doing the opposite, which made the process harder, partly because you have to keep where you’re going in mind before having built the area.

The other stumbling block I have is coming up with ideas for levels. There’s not much I can do to stream line this, so it will probably continue to be a road block. I will probably simply make fewer levels for each “episode” so I don’t require as many ideas.

I’ve also released the level editor for any one interested. You can find it here.

27
Jul
18

Dungeons of Noudar 3D for DOS

Today I’m looking at another homebrew game, Dungeons of Noudar 3d made by Daniel Montiero. It’s a simple dungeon crawler game with a similar visual design to something like Eye of the Beholder. After playing with it a while I think it’s in need of some polish, but is really quite impressive from a technical standpoint.

Hardware support is VGA only for the graphics. The main 3d landscape is rendered in a large window and it features fairly detailed geometry. Compared to the basic 3d dungeons that many RPGs had, it offers quite a bit more visual detail. Whilst it doesn’t render fast enough to be comparable to any FPS games, it works quite well for this style of game, which typically doesn’t update the screen as often. The sprite artwork is nice at a distance, but when enemies or items are up close it can be very blocky.

Hardware support for basic sound is included for PC speaker, Adlib and the OPL2LPT. I tried both the PC speaker and Adlib whilst playing using Dosbox. I found that the sounds varied in pitch and length a little, perhaps because of the emulation, it usually coincided with a delayed screen update. The sound effects are fairly basic, and although they sound fine you don’t miss anything by having them turned off. Unfortunately you can only select the sound support with a command line parameter.

The game play consists of some basic puzzles and some bad guys to fight, both within relatively small levels. Puzzles basically involve finding ropes to cut that open doors. Generally this just requires you to explore the level. Enemies roam the levels, the first ones you encounter don’t seem to be very active, but after a few levels they will chase and attack you. Later enemies require you to use specific weapons in order to damage them. If you encounter them without the weapon required you’re generally boned. Luckily you will find the right weapons if you explore the levels thoroughly.

There are some issues which make it more difficult to enjoy. I got stuck on the 3rd level, the prison, and even though I had cut all the ropes I couldn’t find where I had to go next. In a few other instances I reached the level end without having the chance to fully explore the level and find all the items. I think some kind of visual indication on the exit door/location would help greatly, both so you know when you’ve found it and so you don’t accidentally finish a level before you’re done exploring.

I think it could also use the capability to save and load a game in progress, or continue from a check point after death. Not having these features really limited how far I could progress as I’d have to start from scratch each time I started to play. I’d have liked to get further into it, as it was getting more interesting at the point I got up to.

Issues aside Dungeons of Noudar 3d whilst a bit slow to start is an enjoyable experience. The 3d renderer is fairly impressive in it’s capability, even if it’s not fast and the basic game mechanics do work and play quite well. It’s not a deep experience by any means, but it you enjoy dungeon crawlers this might be worth a download. You can get it from his website here.

This slideshow requires JavaScript.

29
Jun
18

Motherboard: MSI 970A-G43

I had almost ran out of old motherboards for this section when my brother gave me this particular board. He gave it to me as he had upgraded to a Ryzen based system and this one had failed. Unlike the others so far this one is actually relatively modern, although by no means current as it is at least about 4-5 years old. It’s not really remarkable in any way, but it has many typical features of modern boards I’ve not yet discussed.

Here’s a picture of the board.

It’s an AM3+ socket board with an AMD 970 + SB950 chipset which was fairly middle of the road performance wise when it was new. Part of the reason for this came down to AMD not having a competitive CPU on the market at the time, this was well before the Ryzen chips had launched. Lets look at some of the features of the board.

Most peripherals that you could need are integrated, with the exception of the graphics card. There are plenty of USB connectors on the back as well as in header form, although only a few of them are USB3. The on-board SATA controller offers basic RAID capability, and the audio chip is adequate but neither are as good as dedicated cards at their job. Like earlier boards, part of the issue is the location of the audio chip, with it being located near the bottom of the board. This increases the chance of noise and crosstalk affecting audio quality. The LAN chip supports up to gigabit speed as you’d expect.

Like most modern motherboards support for most legacy hardware has been dropped with a few exceptions. There are two PCI ports for old expansion cards, a serial port header, and surprisingly PS/2 ports for keyboard and mouse. With the wide spread use of USB for keyboards and mice these days it’s a little odd to still see old school PS/2 ports.

A big change over older boards is the move away from electrolytic capacitors towards solid polyester capacitors. There are lots of benefits arising from this change, the best of which is the increased lifespan and durability. The downside seems to be increased cost, as there are more capacitors, but I think the trade off is totally worth it. Here you can see the voltage regulation circuits for the CPU, it appears for each voltage there is two caps, 4 FETs and an inductor. Nearby are a further 7 capacitors which could be more bulk capacitance for the voltage regulation, but could also be for the nearby USB ports. Also note the board has marking and holes for a heatsink, but in this instance one is not fitted.

Modern boards don’t really use jumpers for configuration any more, but the front panel header still needs a nice clear silkscreen label. Unfortunately MSI could have done better with this particular board, there are two headers relevant to the front panel, both have labels, but they are both a bit hard to read. If you were handling many of the same board this wouldn’t be a huge issue as you’d learn the layout, but it would be a bit of a pain the first few times. Otherwise there aren’t any issues that make it hard to install or maintain.

This board would be a reasonable choice for many end users who only use their machines for basics such as web browsing and email. My brother used it for lighter gaming loads such as minecraft, which it handled reasonably well with a decent GPU, however it was never suitable for heavier games that are more processor intensive. Being relatively young it’s not really suitable for a retro PC as there is no support for an older OS available.

23
May
18

Freddy’s Rescue Round-up for DOS

Today’s game is an early CGA game originally made for IBM in 1984 by D.P. Leabo and A.V. Strietzel. It was included on software sampler disks that came with many IBM PCs. You play as Freddy who has to rescue all the road runners before the maintenance bots gone rogue harm them. It’s a little bit like Lode Runner, but has a number features that make it different. I saw LGR playing it on a video where he was unboxing a NOS IBM PC and thought it looked interesting.

Being an early IBM PC game, the only graphics supported are CGA, primarily as the other standards hadn’t arisen yet. It runs on the slowest of IBM machines, so there is no scrolling and each room is the size of a screen. Performance on an old 4.77Mhz machine should be quite reasonable with perhaps a little graphical flicker. The game timing works independently of the CPU, so faster machines can play with out issue. Artistically the graphics are quite well drawn for CGA, although you will notice everything is generally a combination of two colours in stripes. This was for use with composite monitors that were capable of showing 16 colours. I can’t show what it would have looked like because dosbox doesn’t display this particular program in its composite emulation mode. PC speaker sound is used for similar reasons, there just wasn’t anything else at the time. The short snippets of music and sound effects are surprisingly quite charming, and suite the game quite well.

The game play has some common ground with Lode Runner, you have to collect the road runners rather than gold and the levels consist mostly of platforms and ladders. There is a time limit for each screen, and you can burn holes in some floors in much the same way, but the enemies (maintenance robots) don’t fall in, they stop and wait for the floor to reappear. On the other hand there are some significant differences. The robots are much less aggressive in their pursuit, and move significantly slower. The levels are larger than a single screen and you use doors to travel. White doors teleport you to the other white door on the screen and are an excellent way of avoiding being caught. Magenta doors travel to other screens within the level, once you collect all the road runners on a screen a second magenta door appears. You only finish a level once all the screens are cleared of road runners and the power-ups that freeze the robots.

When it came to the game controls I was quite lost at first, as there is basically no documentation with the game telling you how to play. I managed to work out basic movement fairly quickly, as they are just the arrow keys, but it took some time to find out how to jump and make holes in the floor. This left me puzzled as there were road runners I couldn’t reach without using these features. You jump by pressing the space bar and left or right, which will jump over a one tile gap. Pressing space bar on its own will dig a hole in the floor in front of Freddy, as long as it’s a floor where that is possible. Once I learned the controls they worked quite well, just the lack of documentation made it hard. The other main issue is that Freddy basically only moves in whole tile increments. If you release the key whilst he is half way between tiles he will keep going until completely on the next tile. This only really caught me out at the edges of platforms as I’d overshoot and fall off the edge.

The level design is generally fairly good, there aren’t many areas where you can get trapped by a single bot. Although if you set the difficulty level to normal or hard there are more bots chasing you which is significantly harder. The bots behave differently to the bad guys in Lode Runner in a way which makes it harder. They spread out and cover a larger area of the screen. Where the Lode Runner bad guys can be bunched together with some clever movement, effectively making them easier to avoid. Luckily you have a couple of tools in avoiding the bots, such as digging holes, using doors (when you can reach them), and the dots that freeze the bots.

I’d say Freddy’s Rescue Roundup is a bit of a hidden gem despite IBM making it public domain and the fact it was distributed with IBM PCs. Most of the usual places I look for DOS games didn’t have it, but it can still be found on some abandonware sites . It could be because of its age, it’s not as well remembered, either way it’s certainly interesting and still quite fun to play. If you happen to own an old PC with CGA and possibly a composite monitor this is worth giving a go.

This slideshow requires JavaScript.

16
Apr
18

SS20 Desktop: Renewed Vigour

Last time I had started to finally get to grips with the system hanging issues, having found out much of the problem came down to the SMP kernel issues related to the on-board SCSI that are still prevalent within NetBSD releases. I was fortunate that I’d been given a chance to try out a patch that made SMP much more stable (although not perfect). This gave me essentially 4 different configuration options. After thinking about it, I decided it would probably be prudent to make some measurements to hopefully determine what the best way to go is.

I have three Mbus modules (pictured above), a dual CPU SuperSparc @ 50Mhz, a single CPU SuperSparc @60Mhz and a single CPU HyperSparc @ 90Mhz. The clock speeds can be a little misleading as there is a little more to each module. The SuperSparc modules each come with 1Mb per CPU of cache where as the HyperSparc has only 256Kb, and the dual CPU module runs on a slower Mbus @40Mhz whilst the other two run at 50Mhz. Additionally the rough guide to Mbus modules, an essential site for anyone with a sun machine like mine, suggested that the SuperSparc CPUs would actually perform better on a per clock basis. Given all this it’s not really clear which the best performers will be. From here on in I’ll abreviate SuperSparc to SS and HyperSparc to HS

Today we’re going to look at the results of some of the intensive benchmarks I’ve put the modules through, and at the end the best choice of configuration given the hardware I have on hand. All the tests are run with the same OS (NetBSD 7.1) and hardware with the exception of the Mbus modules under test.

The first set of benchmarks are aimed at measuring basic CPU speed. The benchmarks I’ve used are Dhrystone (version 2.1), Whetstone and both the double and single precision versions of the linpack benchmark. These tests are measuring single threaded performance of the modules.

Just looking at these charts it’s obvious that the HS is the fastest of the three modules. Given its higher clock speed that is to be expected, but it also attained higher scores per clock for all the tests except whetstone. The linpack tests show a large difference with the HS running about 12% faster per clock for double precision and about 22% faster per clock for the single. The Dhrystone test showed a much more subdued advantage, only running about 7% faster per clock. The Whetstone test showed the HS was slower, doing floating point arithmetic by about 11% slower per clock cycle.

Both SS modules performed about the same relative to their clock rate, which indicates the Mbus speed wasn’t a large factor in these tests, and that the data size was likely smaller than that of the L2 cache (1Mb). I would have expected the dual 50Mhz module to be slower in single threaded tasks as the Mbus is slowed to 40Mhz (as opposed to 50Mhz the others use).

I’m not sure how I feel about the results here, the data set size for the tests was almost certainly too small to even exceed the capacity of the HSs 256Kb cache. I’m not sure what to make of the linpack results, but the dhrystone and whetstone results seem to indicate the HS core is better at integer and string operations and the SS core is better at floating point.

I selected the next benchmark because it offered speed measurements over a range of data sizes. The Sieve of Eratosthenes is a simple algorithm for finding prime numbers within a finite numerical space. Rather than explain it myself look here on Wikipedia for more details. One of it’s key features is that it is quite hard on a CPU’s memory bandwidth, and it’s use of the cache is quite sub-optimal. I omitted testing the 50Mhz SS module.

The results are quite interesting. The HS enjoys an advantage of about 14% per clock when the data set fits within it’s cache, but suffers quite a performance drop once the data set gets larger. Despite being 30Mhz slower the SS is faster for data sets small enough for its cache but too large to fit in the HSs cache. I suspect this gap would be widest at just below 1Mb data size, but the program didn’t allow control over that. The worst data point shows the HS as 44% slower per clock. This is quite surprising, as the SS is not much faster than the Mbus speed (only 10Mhz faster) I didn’t expect the advantage in that data size to be so large. After 1Mb data size is exceeded, the HS starts to catch up again, but the data points don’t get large enough to know if it ever achieves equal relative performance again. I’d imagine that once the data is large enough both modules would perform close to the same as memory bandwidth becomes the limiting factor.

The next benchmark is similar in that there is measurement over a range of data sizes, but the algorithm is significantly different. The algorithm used is heapsort, a relatively efficient sorting algorithm used in many places. You can find more details here on Wikipedia. One of it’s characteristics is that it is much more cache friendly. Again I omitted testing the dual 50Mhz SS.

Looking at the graphs this test really requires some points at larger data sizes. I can only really guess, but I’d imagine that the performance would eventually converge given that memory bandwidth would eventually become the dominant factor. The previous test indicates that there may even be a window in which the SS performs better, but without actual data we will never know.

Given that I’ll be using this machine as a desktop workstation I ran a benchmark known as x11perf. It simply tests the maximum speed of components of the X11 protocol. It’s often known just as X for short, and is basically the software that unix systems use to interface to video displays.The chart shows performance relative to the dual 50Mhz SS (the yellow line represents it). A 2 is twice and fast, and 0.5 is half as fast. Each point on the X axis is a test, like line drawing for instance, there are so many tests (over 300) it wasn’t practical to separate and chart them individually. Out of interest I ran the dual 50Mhz SS with a MP kernel to see if it made any appreciable difference.

There are some quite interesting features of this chart. Firstly you’ll notice that both the faster modules have tests that are significantly slower than the dual SS (30-35% slower at worst). This is because those tests are CPU bound, and with a dual CPU module both the X server and client can have a whole CPU to itself. Typically those tests involve little actual drawing to screen, like plotting points.

In general the dual 50Mhz SS is slower than the faster modules. The SS @ 60Mhz is about 1.15 times faster on average and the HS is 1.75 times faster on average. The HS is in general the best on the raw performance numbers, with some odd exceptions. Some tests seem to favour the SS @ 60Mhz, which would be down to cache size.

Relative to their clock speed, the 60Mhz SS does better than the HS, but I’d imagine this would be due to the SBus limiting the maximum through put to the frame buffer. The SBus only runs @ 25Mhz so is almost certainly going to slow down a faster CPU when drawing.

The last and final test is one called Ramspeed. It’s basically designed to measure the memory bandwidth. I opted for the more general integer and floating point tests over the specific reading and writing tests as they are more likely to represent a computational load. There are 4 tests, Copy creates two buffers and copies data from one to the other, Scale creates two buffers and copies data from one to the other, but scales the number by some constant, finally Triad creates 3 buffers and adds two of them together (scaling one by a constant factor) and storing the result in the third buffer. All buffers are the same size. The tests I’ve chosen only test with buffers that are 32Mb in size, so much larger than the caches of either of the modules. You can select the buffer size and some tests available in the program test a range of sizes.

The results are pretty bad for the HS, it achieves slightly better speed only for the copy operations, which shouldn’t be surprising as the Mbus should be a limiting factor. However for the other tests the SS performs quite a bit better, so much in fact I ran the tests many times just to make sure. This would appear to be down to the memory and cache architecture of the modules, not just the cache size, although that is certainly playing an important role in the HS failing to perform. The HS does have significantly smaller L1 cache only having a 8k instruction cache versus a 20k Instruction and 16k data L1 cache in the SS core.

Having now spent a couple of weeks testing these modules I think we’re starting to get a picture of what these chips can do relative to each other. The HS is clearly faster as long as any data isn’t larger than its cache. The SS on the other hand isn’t as fast at it’s peak, largely due to a lower clock speed, but handles larger data sets significantly better. The X11 test showed that it is quite beneficial to have multiple CPUs in a workstation, even if only for basic X11 applications. However it also shows the HS being quite a good choice. I think the tests also show there was some merit to the idea that the SS modules performed better relative to their clock speed, but it also shows this is highly dependent on the work load.

So what am I going with and what would I recommend. With the hardware I have I’ll use the HS @ 90 for running the machine as a workstation as that makes it snappier to use in general. The flip side is that if I were to use the machine for a computational load, such as compiling a number of packages, number cruching, or a basic server the two SS modules would almost certainly perform much better as long as the job could be divided between the CPUs. Even the SS @ 60Mhz has a good chance of doing computation better on it’s own. The HS on it’s own is disadvantaged by not being able to multi-task as well, I have noticed that X is in general less responsive when the machine is under load (compared to both SS modules together), so a second HS module would probably be a nice addition in the future.

If money was no object and I could have any parts at all, both Ross and Sun had decent offerings. The fastest SS is 85-90Mhz, two of these would certainly be quite fast. However I’d imagine they probably wouldn’t be as fast as any pair of HS modules over 125Mhz. So in the end the HS modules would be the way to go if you had access to anything. As it stands, looking around online it’s actually really hard to find faster modules for a reasonable price. Among the SS modules those over 60Mhz are quite expensive and largely not available. The HS parts have a similar problem, but you can get 90Mhz – 133Mhz parts at fairly decent prices, although faster modules still command a high price, and slower modules wouldn’t be worth it. Again with what’s available the HS seems the way to go.

I’ve tried to be as thorough as possible, but if you want to see the raw data  and gnumeric spreadsheet with calculations and charts you can find them here.




Blogs I Follow

Enter your email address to follow this blog and receive notifications of new posts by email.

Advertisements

Mister G Kids

A daily comic about real stuff little kids say in school. By Matt Gajdoš

Random Battles: my life long level grind

completing every RPG, ever.

Gough's Tech Zone

Reversing the mindless enslavement of humans by technology.

Retrocosm's Vintage Computing, Tech & Scale RC Blog

Random mutterings on retro computing, old technology, some new, plus radio controlled scale modelling.

ancientelectronics

retro computing and gaming plus a little more

Retrocomputing with 90's SPARC

21st-Century computing, the hard way

lazygamereviews

MS-DOS game reviews, retro ramblings and more...