Showing posts with label 486. Show all posts
Showing posts with label 486. Show all posts

Sunday, 2 January 2022

My first PC from Watford Electronics (1994)

The year was 1994, I had just learned to program in Pascal, I was doing quite well in my A-Level computing course and my parents bought my brother and I a PC... With "Support".

Yes, they forked out quite a whack of cash just months before the Pentium processor came out to buy us a machine powered by an Intel 80486SX2, which ran at 50 megahertz.  It had 4 megabytes of RAM and a 200 megabyte hard drive, as well as a HDD floppy drive!  I was in love with this thing, and I'm a little bit sad when I think about it's fate later on.

We bought this beast from Watford Electronics, it included at home support for a flat fee, I'm pretty sure Watford Electronics never expected this to be an issue, but it was.

We came to use this machine, daily, without really knowing much about it at the time, but a 50Mhz machine was blisteringly fast to us, it had an S3 Trio VGA graphics card in it too and came with WE's own ISA expansion card to add a custom CD-ROM drive, which they touted as being "Dual Speed"... aka slow or very slow.

This was all fine until 1995... Yes a whole year passed.

The few friends with PC's at home had Escom Pentium based machines, having waited to ask their most affluent parents for them that Christmas gone by, and so it was my brother and I played catch up.

Sure, I had all the beans in the bag with Turbo Pascal 7.0 for DOS and my learning more and more about computing, but games were where it was at.

The first title to show some issues was CivII, which I got for my birthday from a couple of friends.  I loaded it up and it stuttered terribly on this machine; I know now that the bespoke card to link to the bus was the blame, it had no buffering and relied on the drive's throughput and this was too slow for the game.  So despite our machine appearing on paper to be more than enough to play, it struggled terribly.

So much so that my mother decided to pack the whole thing up, including my game, and send it to Watford Electronics... I'm not sure what they did with the machine, but it arrived back behaving exactly the same way as it had before, it was sub par by design, they couldn't admit that, but by damn it they had described this machine as being Dual speed and fast enough, so it was by damn it going to be.

And it was such that on a festering hot day in 1995 an engineer arrived, a suited, briefcase carrying engineer... from Watford Electronics... Under the auspices of their repair warranty service arrived to see... What?

Well he saw two kids playing games.  I think he expected an office or a school.

But no two kids and their sweaty sickly close bedroom, and he set about looking at the issues, and sure enough he agreed with us, grudgingly, but he agreed.  And set about trying to sort things out.

He reinstalled the machine, no dice, it was just as slow doing the same tasks with the software reinstalled.

He fettled about with the settings; which I had already done; resulting in things getting even slower.

And in desperation of the perspiration he reached into his bag and pulled out a selection of options, the first was a sparkling Intel Pentium Overdrive chip, which would have overlain the socket 7 and boosted us immensely.  I knew this was pretty damn expensive.  But alas his hand waved over this and selected a 486 DX2-66Mhz, he set up the motherboard and rebooted.

Telling me something I'd not understood until this point... "The SX Chip you have doesn't do floating point maths, it's all integer based".  A slight exaggeration, but about right, the SX was a DX which had failed certain tests, Intel had cut certain traces and so they sold the lower spec chip rather than writing off the failed DX in their ledger.

The DX2 however, only really made a difference in Doom... Which we played already, and it didn't make that much of a difference with the 66mhz to 50mhz jump being so small.

And so it was he reached once more to a different flap in his bag and he pulled out a tray - yes a whole tray - of 486DX4-100 chips... 100Mhz!...

Things ran like a dream then, even with his busting of my mobo jumper settings.

I pushed that chip to 114mhz on very rudimentary air cooling, and it worked well into the 2000's.  I loved that chip, and we got it by bemoaning the system.

The system itself, with the proprietary Watford stuff in it eventually broke down, I had gotten into tower cases too, so the large desktop case of mostly air was left, the hard drive failed, and the machine was itself lost in body but never in spirit.

That 486DX4-100 chip stayed with me a long while, I had it until at least 2003, and in use.

Thursday, 2 June 2016

Software Engineering : My History of Odd vs Even

I've been a avid fan of Intel's processors since my very first PC, powered by an Intel 80486 SX-25 it taught me so much, it also got me into a lot of trouble once, being an SX it was essentially a DX unit with a failed floating point unit at fabrication.  But Intel being the trixsy tech wizards they are, they didn't throw all those chips away, they simply disabled the broken portions, kept the working addition and subtraction sides and sold them under the SX label.

This of course led to some interesting differences between the SX & DX chips, the most obvious being the multiplication behaviour, on a DX to multiply to numbers you simply loaded each into a register and executed the one step multiply.  However, on an SX you loaded the start value, and the denominator into two registers and then looped through for a number of times adding them.  So the pseudo assembly code for it might look like this:

      LDA 3
      LDB 10
MUL:  ADD LDA,LDA
      DEC LDB
      JNZ LDB,MUL
      SAV LDA,RESULT

Where we find us loading up the two registers, then performing an add in a loop until we've added enough times.  This is of course a lot slower than:

      LDA 3
      LDB 10
      MLT LDA,LDB

And, the more you multiply the slower the SX could behave.  It wasn't as simple as this, however, for demonstration purposes we'll assume it was, there's no need to comment telling me I'm a moron (again) I know I am, but this is only a demo.
      
But this little SX machine was the only machine I had, and I was moving my programming skills from the playground of the Atari ST to the PC proper, and so I chose to try and get a lot of juice out of the machine.  On trick I learned was to page through screen memory scanning for shapes, but of course I quickly needed a bunch of math functions.  Using the CMath library was quite slow on the SX, so I started to find quicker home-brew alternatives.

Initially I had no idea I was working around my own CPU's hindrances (I only found this out later, when I realised on a DX2-66 chip I was getting magnitudes better performance).

One hunderance, of function, I worked around was odd & even... To calculate this, you would usually use a remainder, by division, in C this might look like this:

int remainder = 34 % 2;

Remainder would have a zero value for even values

const bool OddEven (const int& p_Value)
{
    return ( ( p_Value % 2 ) == 0 );
}

I was doing this in Pascal at the time, the syntax of which I have forgotten.  But you can see, it is a fairly simple function call, quite non-descript.  My problem on the SX was it ran so slowly.  A lot faster was to convert the value into a string, and inspect the last character!

bool l_IsEven = true;
int l_Number = 42;
char* l_str = new byte[16];
memset ( l_str, 0, 16 );
sprintf( l_str, "%i", l_Number );
int l_lastCharacter = strlen(l_str);
switch ( l_str[l_lastCharacter-1] )
{
     case 1:
     case 3:
     case 5:
     case 7:
     case 9:   l_IsEven = false;
                   break;
}

So, we get a value in l_IsEven more quickly, and it was indeed quicker for me to do this...

However, when I first looked at this problem, I had no itoa, nor sprintf, all I had was integer control.  Indeed, in the programming language suite I started with the only way to get text easily from a value reference to a string of characters was to write them to the screen with "write" and then to move back to the start of the line with a return carriage, and then to "read" the line again.

This was very very very slow, much slower than even the switch statement bastardization above.

So, I set about it the most logical way my 14 year old mind could think of...

It took the number, and did this:

bool l_IsEven = false;
int l_Number = 12354;
while ( l_Number > 10000 )
{
     l_Number = l_Number - 10000;
}
while ( l_Number > 1000 )
{
    l_Number = l_Number - 1000;
}
while ( l_Number > 100 )
{
    l_Number = l_Number - 100;
}
while ( l_Number > 10 )
{
    l_Number = l_Number - 10;
}
switch ( l_Number )
{
    case 0:
    case 2:
    case 4:
    case 6:
    case 8:   l_IsEven = true;
                 break;
}

This of course was totally horrible, and I quickly stopped using it in favour of the string method, and later in favour of the remainder function.

However, this horrible history of code remained in one of my header libraries, at the time they were Turbo Pascal Unit files (TPU), but when I went to University at 18, some four years after writing this original code I had tried to convert some of my Pascal support libraries to C and then C++.

One of the legacy calls I converted, without even looking, with an automatic tool was this very stupid function above... And yes, it ended up in at least one degree level project (oh what a fool I looked).



P.S. I'm sorry to report, I've never owned an AMD processor... However, I did have a Cytrix x86 to upgrade this very Intel Chip!