Showing posts with label CPU. Show all posts
Showing posts with label CPU. Show all posts

Saturday, 13 July 2024

What is it with the AMD Adrenaline Software?

Very quick one, I've taken delivery of a new Graphics Card... (oooooo ahhhhh).

And it's a seed change for me as this is my first ever AMD graphics card, so this is of course going in my own main PC, which itself is my first ever AMD CPU powered machine I am therefore all Team Red for the first time ever... EVER!
I have been so excellently impressed with the performance of the Ryzen Zen 2 chip at the heart of my machine and my old EVGA 1080 GTX Superclocked was showing its age.  It was therefore time.

Unfortunately I made a huge mistake... No, it wasn't the model, no it wasn't the price, no it wasn't even paying to import it (because it was cheaper by a margin to have the card fly all the way to me through customs from California than actually buy it here in the UK - Thanks Brexit! - Not).

Anyway, it arrived and I plugged it in, and my monitor didn't come to life; I then found the signal was going to my massive 4K TV (on the HDMI) not my monitor (on the display port - go figure).

That sorted I then needed drivers, so I went to the AMD site and looked and found what it said was the best package to install on Windows 10 64bit for this card....

I don't know ANYTHING about the AMD software, and oh boy is that a mistake.

I installed it and was immediately REALLY REALLY IMPRESSED with it!  Yep, it's beautiful (even if it is backed by Qt and I hate Qt) and smooth and does wonderful things.

Unfortunately, and this is key, it was taking a lot of CPU whilst doing this work... So I closed it... and it STILL took a bunch of CPU, nearly 10%!

Just idle at the desktop, 10% CPU.

I was properly baffled by this, it must be doing something, so I went through all the settings and disabled everything I could see, everything turned off, clean reboot, and it was still taking 10% but now was peaking to 14% on odd occasions just idle!

What the heck, a bunch of goodling and I can find a bunch of folks complaining about exactly this, and one guy properly threatening to boycott their brand unless they explain how to just install the drivers without this software suite.  There was no answer to these please, and they were old posts, like there's been an apparent hard reset of the search results for this kind of question.

I spent a bunch of time trying to fathom this issue to no avail, so I like my forebears in the search results set about trying to find JUST a driver package.  I could not find one,

I therefore just decided to pull the card and possibly return it.  And so uninstalled the AMD Adrenaline Software, it took its time... And really grated on me as it spent about two minutes showing me the text "We value your feedback"... without ever giving me a link or contact in order to tell them anything... and this is during an uninstall process; surely someone when they added this eye stabbing annoying message thought "Oh we need to have them able to give me feedback!" ... Nope, seems not.

Now completely uninstalled and the package opens a website... This website... which I link only for you to see... as it's an advert... for a version of the very card I am uninstalling the software for.... Yes, AMD that's pretty tone deaf, also... WITHOUT YOUR DRIVERS INSTALLED YOU CAN NOT VIEW THAT SITE, so double double own goal there .... Less Advanced Micro Devices and Anyone Might Despair.


Here I am then, flabbergasted, back to a tiny resolution, opening chrome and trying to find just a raw driver package and I can't find one.  My machine has now cooled and I hear the CPU pump has ceased whirring away, as it was constantly with the 10% load on it!

I sat looking for ages when I first installed the card, really ages, we're taking an hour before I went with this Adrenaline stuff.

When suddenly Windows itself kicks into life and installs the Microsoft supplied WHQL driver, and guess what?  Yes, it's the same base driver, and it works absolutely brilliantly... and crucially my machine is not taking any CPU when idle, it's gone quite quen idle, I'm sat now typing this with a YouTube video playing, about 6 chrome tabs open and a copy of Visual Studio Code open too and it is silent, the machine is silent, just as I built it to be (unless under load).

Looking about I see AMD are recruiting software engineers, I have no idea what for, but if they see these pages - I'd suggest a bunch of refactoring is due over there folks.

Wednesday, 10 February 2021

My Desktop PC History

My PC history and I literally mean PC's, so we're talking after my Atari ST, this is a list of the machines I've owned and used in order and a little bit about what I did with them.

486-SX-25 (1994)

The first PC I used was built by a company based in Baseford in Nottingham, it was at college and was equipped with an Intel 80486SX, it ran at 25Mhz, ran DOS 6.2 and a netware network layer.  It had 4MB of ram and basically was very much locked down, that was until we figured out how to quit out of the netware login screen (repeatedly CTRL+C whilst hitting enter fast).  The college had loads of these machines of this specification, the three main IT labs of course but then there were two more directly outside one of the lab doors, another in the head of Chemistry's office and a bunch in the library.

I primarily programmed in Turbo Pascal on these machines, I remember playing about with writing my first games on this in EGA graphics mode.

486-SX2-50 (1994)

My first home PC, it was from Watford Electronics and had their own ISA riser connecting to a dual speed CD-ROM, I remember Encarta amazed me, as well as working out how to just play CD's whilst programming.  I of course did my college work on the machine, and I remember my brother did his too.

The machine came with 4MB of RAM and a 200MB hard drive... MEGABYTE... I remember windows 3.1 ate into the disk significantly.

But DOOM came into view, now at the time I had no idea really what SX meant, but it had effects on DOOM's speed.  One of them was the maths.

I actually programmed around the limitations of t he SX chip without realising it and this came back to save me (or curse me) later.

Later we got Dark Forces and another 4MB of RAM, giving us a total of 8MB in this machine as I went to Uni.

But basically the SX had no floating point unit, it had only integer mathematics as well as a bunch of other operations being missing.  It was basically a DX chip which had failed QA and had come part of it disabled, but this was a "2" which meant it ran twice as fast as the machines at college.  And that speed difference was reflected in my little home brew games suddenly running twice as fast.

This remained my main and only PC going to Uni, but in my second year of Uni, sharing this machine with my A-Level studying brother I needed my own and these "Pentium" machines had been released.

Pentium-100 (1996)

The power of the penium, with the EDO ram SIMM's was so massive compared to the 486, and this was the first machine I started to program in C on.  Indeed, it was also the first machine I wrote Java on and even played with Linux.  But I never loved this machine.

Running at 100Mhz, it was blisteringly fast to me, but I was still using DOS 6.22 and Windows 3.1 for the most part.

I should have, it was the first machine I bought with my own hard earned money, I did keep it until my final year at uni, but by then I had started to build my own machines.... But I'd also been to work in IT.

HP Pentium-166 (1998)

This was a machine at work, it was mainly a windows 95 platform for me to work with, I soon had Windows 95 at home too, so things balanced up.  All I used this for was some very basic database work, which the prior incumbent in my job had left (and which was awful).

Compaq Pentium-II 233 (1998)

Another work machine and at 200Mhz, it seemed like the things of legend, but this was a compaq deskpro to which all the analysts and myself upgraded, with  massive 17" CRT monitors, they were really nice machines.

I did a bunch of Pascal programming on it, a bunch of Cobol and some database work (I think it was in FoxPro).

Pentium-III 300 (1999)

Returning to Uni for my final year I built this machine myself, I remember this was a slot-1 processor, and I put a whopping 32MB of RAM into it.  I wrote my dissertation on it and networked it to my older Pentium 100.

Voodoo3-2000 AGP.... Which I only sold in 2013 on ebay, at a profit.

Cyrix-150 (1999)

This was actually my pentium 100, but I found the Cyrix chip for sale for only £10 at maplins so bought it and stuck it in the old PC, to find it was a massive performance improvement when compiling and running both C and Java.

Celeron-III 450 (1999)

This was a machine I actually built for a customer, I spent a bit of time making PC's and making money doing so in the late 90's.  And this was one which stuck out to me because it was such a nice performing machine, it included a graphics card (I think it was a Voodoo3-3000).

The build was with a gigabyte motherboard using slot-1, but the processor was socket 370, buying it and using a daughter board was cheaper than buying a socket 370 motherboard, and performed no differently.  It actually made adding the cooler so much easier.

Pentium III 500 (2000)

I bought this after uni, just a new chip, with 128MB of RAM as I set off away from uni.  I just played a lot of games on this machine, dabbled with Java, but I didn't have the compiler suite we used at work to my programming was mostly all in the office.

Pentium III 500 (2001)

This was the office machine I had at the time, I'd had one before, but don't recall it, this one however was by the local computer firm in Redditch and I remember it was a 500mhz Pentium III.

GeForce... At some point at home in 2001/2 I got the first GeForce card at home and started to babble with OpenGL on Linux.

Pentium III 1ghz (2003)

Another office machine, this was a bod standard HP I think, the job here was C++ programming, but coming from a pure Borland using history (all the way from college to now) I was suddenly not in a Borland using shop and... well... I didn't stay at this job very long.

Pentium IV - 1.5ghz (2004)

A prescott Pentium 4... at the high speed of 1.5ghz, this was my first hyper threaded machine, it was built from the ground up for gaming... so it had 1.5GB of RAM (the most I could afford)... the dual thread pentium 4, overclocked to 2ghz on air.

A pair of GeForce 8800GTX in SLi.

I bought it to run Battlefield 1942 really well, and was really very good.  I also played national league Day of Defeat and started my dual obsessions with World of Warcraft and Eve-Online on this machine.

Core 2 Duo 3ghz - Wolfdale - 2.3ghz

I built this machine for my father, he didn't appreciate it at the time.

Core 2 Quad Q6600 - 3ghz (2007)

This was my main driver for years, and the machine I first put into the Cosmos 1000 case.  It had various RAM, disk, graphics configurations until the last iteration being a GeForce 260 GTX (squared) so this was two GeForce 260's on the same card in SLi together.... It was really good.

I spent time coding for Lordz Game Studio on this machine, as well as playing lots and lots of games.

Core i7-920 (2012)

Yeah, we're at Core i7.... the best I could accord for the i7 release set and it went into the same case as the Q6600 was in.  This machine was a main-stay until I actually swapped out the Core I7 (4 cores 8 threads) for a Xeon which was 6 cores and 12 threads... I did that in like 2016... so I've had 12 threads at home for a long old time.

Ryzen 5 3600X (2018) -> Ryzen 9 3900X

Team Red.... Aside from the cyrix I've always, always been Intel... Ryzen turned my head, and the 6c12t 2600 was the first I could get my hands on.  But the motherboard was purchased with upgrades in mind and the same machine now has a Ryzen 9 3900X 12c24t.

It was a mchine built around the 64GB of RAM, dual m2 NVMe and a stack of 4TB disks, all in a corsair obsidian case.

Sunday, 3 May 2020

It Finally Happened... Dead CPU

It's happened, happened in annoyingly mundane circumstances, but happened nonetheless... I've killed a CPU.

The first CPU I've ever ever killed, and I've toyed with and worked with CPU's since about 1994, juggling them and building systems, basically as soon as I was introduced to modular PC's at college I was playing about with them fitting parts and drives and replacing things in the great beige boxes.

So what was I doing to finally kill a CPU?

Well, before I explain, let us just lament the chip, it was my Core 2 Quad Q6600, a chip I paid release week prices for, which served me throughout my time playing Eve-Online and World of Warcraft, the chip on which so many gaming marathons in Day of Defeat was carried out and the first chip I really played about with understanding the out of order execution of the new Pentium architecture Intel had foisted upon us (and which I'd tried to ignore for many moons).

Late July 2006 it arrived, I installed a then whopping 1GB of RAM into it and Windows 98 was stuck on it until November when it received Windows Vista, and it worked a charm, equipped with a further 3GB of RAM to a total of 4GB.  Two GTX 8800 graphics cards in SLi it was a beast in it's day.

It led a long and fruitful life in gaming and productivity for me, and so last night 2nd May 2020, a full fourteen years of service later it has gone to silicon heaven.

How did it die?  Right, well, I've been setting up a CCTV system, the neighbours continue to be a source of perturbation for us.  So I had the Q6600 set up in a case with 4GB of RAM streaming to YouTube, however it ran so hot, like a really really hot.  So the plan was to take it out that cramped case, put it into a Bitfenix case with a large 775 cooler.

I get it on the bench, test boot, all fine, remove the ssd and stow it and get to work, all the power out and off, all the cables out the way, unscrew and lift the mobo out, I get my test bench PSU and test boot to the BIOS, all fine.  But I can hear a loud noise, like a whine... I figure it's the power supply, so swap to another power supply, and still hear the same noise... Ohhhhh... what the heck is that?

I reduce to the minimum RAM, and boot... Nothing, what happens is the fan spins a moment then off.... Spins, then off... Spins then off... Oh oh...

I changed the RAM, so change it back... same thing. spin, stop, spin stop... No post.

This whine is getting louder each time I turn on....

I have no idea what it is, I'm suspecting a capacitor or coin whine, I'm suspecting the power supply, not the board.

So, I remove the cooler, and swap a different socket 775 chip into the socket, boots to bios fine, no problem.... Oh oh.... I'm suspecting the CPU is bad.

A visual inspection, it looks fine... I trust the Q6600....

I put it back in, power on again and the whine reappears but instantly goes away, and I smell burning.

Power all off, pull the chip... and sure enough one of the underside surface mount components has gone, I can see its blistered and bubbled up... That CPU is dead, at least to me.

I have no idea what's cause this, I suspect it was age combined with being in this constrictive case and getting so very very hot.

I've decided to retire all my core 2 based machines, I have (well had) three... The Q6600, a X5472 and the wall mounted PC.... The wall mounted project is a little difficult to directly change, I may continue as it is, but the rest of them are to go, they're running too hot and too inefficiently, a now old sandybridge chip will be far more energy and performance efficient.



Thursday, 28 November 2019

From intel to AMD...

Well, that just happened... I bought a Ryzen CPU...

That may not seem a huge revelation, but let me be clear in my PC's I have always (well nearly always) had Intel CPU's.  But the current 3rd generation of Ryzen has Intel on the ropes and I have to get moving with my new PC build.

And I've gone in what may seem a strange direction.

Initially I thought about third gen Threadripper, but I really can not justify the expense, most of my work is done on servers and though I could bring it all onto my workstation for compiles (like LLVM) but really its a convenience and not worthhy of nearly £2500 (after a processor and motherboard).

So what did you do Xel?... WHAT DID YOU DO?

Well, I've gone with an AM4 socket motherboard, a very good AM4 socket motherboard, and I've gone with a 3rd Gen Ryzen Zen 2 architecture processor, but perhaps not the one you'd expect.

You may expect me to have gone with the Ryzen 9 3950X, and you'd be right sometime next year, when they're properly out and in stock and prices have homogenised some.  But today, pre-Christmas, they're like rocking horse shite and costly.

The processor I've gone with then is the Ryzen 5 3600X...

Yes, it's Zen 2, yes it's AM4... Yes it's only 6 cores and 12 threads like my current workstation machine.  But it was only £200.  It comes with the stock cooler, so I cam practice with that before delving into fitting the AIO.

I've gone with an Asus ROG top tier motherboard for this class of processor, and I plan to let it go up to the 3950X with it's 16 cores and 32 threads sometime next year.

Memory, I've gone with two sets of 2 x 16GB Corsair Dominator RGB.  For a total of 64GB of RAM, which is a massive upgrade and maxes out the motherboard.

For that's the big thing I'm giving up, if I had gone with the threadripper3, then I'd have automatically had access to double the RAM slots (8 to be precise) and 128GB of RAM is common as a maximum on the X399... But here on the X370's it's usually 64GB (though some are 128GB).

The motherboard, RAM and processor all come from Amazon, for (to me) the princely sum of £700.  So the whole new machine, with the PSU, AIO, Case and storage I already have has topped me out at £1,100.

Expect build videos and tech tinkering footage soon.

Tuesday, 12 June 2018

CPU Speed : That Time I got Conned

As a technologist I've always been interested in the newest kit coming out, and many moons ago this exact demand for kit made me very mad.

For you see, the previous year I'd built my first 2 ghz machine, and it was very costly.  Hyper threading was new to the market, at least in the Pentium 4 range.  And as usual I had need for more power from my machines.

So I hit the interwebs and found a machine (on ebay I think) which was 2ghz... A nice CPU was mentioned in the specification... But the memory and graphics capability were lacking...

I could make the difference up from my spares bin, so I took the dive ordering this machine as a base on which to work.

It duely arrived, I plugged it in, and was dismayed to find it clocking only around 1.1 ghz.  Baffled, I check the advert, "Dual core 2 ghz chip" was definiately there, with the sub-note "exact type may vary, select Intel or AMD preference".

Back to the machine it is dual core, but it is not 2 ghz, no where near.  So I call them up...  Not even have I explained and the phone was put down on me.

Maybe, just maybe it was a mistake, I call again... Phone rings unanswered.

Paypal dispute time as I pack this machine back up into it's box.

Except, the seller won't refund nor accept a return.  They have meticulos pictures of the machine and documents stating that it's correct and I'm trying to con them...!

The ebay resolution center rule in their favour, I'm obliged to accept the item.  I forget the details exactly, but it was a very protracted affair.  All whilst the machine say unused and I started to build an actual second 2ghz machine for myself.

After about four weeks though, I get the resolution center ruling, and accepting the fact I have this potato (it was still a good price for the potato, just not the fabulous deal I thought I had gotten)...

But one of the documents catches my eye, it said:

"2ghz speed is from our including two processors of at least 1ghz speed"

and in pencil of this digitized photo of the page they've put the processor spec and the maths... 2 x 1.1ghz = 2.2 ghz faster than they had paid for.

You know and I know that's not how processor speeds work, but ebay had accepted it, the conners at the other end of this sham had me very very annoyed by this....

However, whenever I seek people bemoaning the 5ghz tests being carried out by Intel, with external hidden sub-ambient coolers helping, I can't ever stop the phrase... "that's 2.5ghz x 2 easy"... Or thinking my current machine at home is a 48ghz speed (12 x 4ghz).

Thursday, 1 February 2018

Intel Home Server CPU

You're all aware (I hope) of my stack of servers under the desk, however, the main server I use is actually a re-purposed desktop - it's the G33 chipset Socket 775 to Socket 771 running a Xeon E5420...

And I have my plan forming to re-case my main workstation, however, I wondered... As I'm currently very exposed with data not replicated across drives on my little server and the machine being quite high power, whether I might not do better in the short term of recasing both... AND changing the server to an always on box.

This way, I could build a machine around a dedicated new board and chip... I started out with the AMD APU's the 2580 and some others, up to a quad core, and as fabulous as they look on cost they didn't float my boat.

I don't need a lot of number crunching power on the server, so what was my concern?  Well, I'm an Intel guy... Always have been, and think I always will be.  Obviously I started with MOS processors, then moved into the world of Motorolla, but since 1994 I've steadfastly bought and used Intel.

Why? Well, I remember the original AMD offerings, they were copies, and hard to find in the UK market without knocking the quality of other items in your build, so I stuck with off the shelf Intels.

I then build my own Pentium II and III computers, I also found use for Celerons - I've never had anything against them - I had a Pentium IV Prescott when they were literally brand new, then I've had the Core i7 950, plus all the Xeon servers and modding fun.

At work I've always been supplied Intel too...

What options does the market offer in the Intel world?.... Well I spotted the dual core, dual thread Celeron G9300.... Which looks just the ticket for me, it's pretty low power (53W compared to the Xeon E5420 at 80W), it can address more RAM, so giving me expansion options and it had decent reviews.  The trick is to not expect a lot from it, and to actually put it to a good use.  If that use is as an SSH point into my network, a git server, NFS host and squid box, then that might work quite well.

I've therefore drafted a build, you can see it here.... 

If nothing else that case, might be a perfect buy, to get the ball rolling, and guess what!... Tomorrow is pay day.

Friday, 23 September 2016

Reading my Reddit Comments (4001 CPU)

I've recently noticed spells when these pages come up with lots of hits from other sources, by far the most common is google, however, just now and then reddit becomes a source of my views, so I decided to take a look... I was happy, surprise and interested to see the threads... Lets take a look.


By far the most common of my posts to appear in reddit threads are tutorials, an interesting one, at least to me, is my 4001 CPU post.  Of course it is a miss-noma for me to call it the 4001 a CPU... The intel 4001 was a ROM chip, the 4004 was the CPU in that series; strangely no-one spotted that intentional change, and I had thought they would.


Click here for the original post on this blog.

The post is about re-creating an integer CPU in code, it was a forerunner to a series for instructing a class, the next posts, which were planned were to include floating point mathematics, however, the whole series was put on hiatus, and I never returned to the topic.

ninereeds314 on reddit calls me out on this, about my commenting that about 486SX code, where I said: 

"I know this because I once got told off for designing code with my 486SX2 processor - which could only add and subtract in hardware"

He says:

"No - even 8086 had integer multiply and divide instructions. They were slow enough that it was often worth avoiding them and using shift instructions and similar tricks if you could, and they could only work with the AX and DX registers (e.g. for multiply, AX x Source -> DX:AX) but they were there.
The 80386 32-bit versions of DIV, IDIV, MUL and IMUL were very similar, but working with EAX and EDX rather than just AX and DX where appropriate.
It was mostly the 8-bit chips that didn't have integer multiply and divide instructions. IIRC the Motorola 6809 was one of few 8-bit chips to actually have them, but came too late for the peak of 8-bit home computers - I think the best known machine it was used in was the Dragon 32.
Other than that, probably early RISC chips didn't have built-in multiply and divide instructions. One of the principles for RISC (at least years ago) was that every instruction should complete in one cycle, but multiply and divide needed a lot of transistors to do that - in practice they used microcoded algorithms (which was why they were slow)."
He is perfectly correct, my passing comment is slightly out of context, the 486SX could do integer multiplication and division as he says, it could not do floating point however, as it had a defective FPU which they disabled in the factory.  This was what the SX was, a crippled DX, which Intel remarketed as a cheaper chip, rather than throw away.
My article however is about 8-bit code, and I wasn't clear, the 4004 could NOT do direct multiplication of integers, it performed the multiplication by looping, as I had done in my code for the 486SX.  My solution for my code was quicker on the 486SX, which could do the integer add very quickly, but the multiplications were somewhat slower, over 100,000's of calls this did add up, so I avoided it; and in the article I'm only talking about an 8bit integer CPU.  I wasn't clear enough.

However, choralone, comments directly after and spots what I meant, so I know I'm not completely lost.

This discussion continues between ninereeds, choralone and nerd4code, as they discuss more deeply what I'm describing, and indeed I see ninereeds explain that the x87 co-processors, were slower; here he's wrong, once the data was delivered across the FSB to the co-processor they were extremely fast, unfortunately the gated way in which data was shuffled to the cache on the co-processors meant that they were slower, they also only generally ran at 12Mhz, so processing on them compared to a 286 itself was fast, shuffling data to and from them, was quite slow.  As it held the whole bus, with interrupts disabled.

The 387 co-processor was quicker, but could not use a 32bit bus, hence the 486 was designed to have the co-processor (redubbed an FPU) built in, but Intel had fabrication issues, and the photo-lithography techniques of the day left a lot of chips with perfectly functional integer cores, whilst the FPU's were defective... The answer, they severed the link to the FPU, relabelled it the SX and you had an emulating software library call, which vastly slowed the 486SX series down.

About this thread of discussion, I only wished they'd have had it on my actual blog... We like-minded people could have made firm friends!

On the same thread, we spin forward and the user "immibis" picks out my comment about where historically CPU's pick up their first instruction upon power on... he says he finds it hard to believe that they would pick a location in memory.

Well, they did, if a CPU picked 0x00 as it's start point, often it was not clear whether the CPU was reset, just powered, whether all the chips were ready, or the sync signal or whatever technology they had was ready, so it was common practice to have a all lines held low, and then raise on high along with the clock to indicate the start point of the CPU when it was literally first powered on, this high-line in early implementations (and indeed solid state machines before their being silicon) meant they didn't address zero, they in fact addresses a higher part of memory.... 0x800 was a common location for some machines I programmes for early on in my career.

Sometimes, as "jslepicka" points out, it was because the start of the address space was ROM, so the first instruction for execution was in ROM at memory address 2048, the preceding 2047 bytes had library calls, system calls and interrupt handling code in them.  And they were (sometimes) in physically different ROM chips, which could and would be swapped on development machines or embedded devices, so you could upgrade the system calls, patches to calls in these early 2047 bytes often turned into JUMP instructions out to new patches in higher areas of memory beyond the start, and then a series of NO-OP instructions to stop them being used.

However, some early machines had all the RAM at the start, and the ROM on a different address space, so you had to pull a line high to get to ROM over RAM (or vice versa), so you had two different memory spaces to address.  In those systems, you often had the problem that they were dodgy, memory was pretty daggy stuff, and chip failure rate high.

So, common practice, was to skip the first memory RAM chip at boot up, and use the second or third chips, according to the physical wiring diagram.  So the first chip, which would for a matter of pico seconds (or nano seconds, or however long the electricity took to start to flow) have an "over current" or jolt, was NOT being used.  As they genuinely tended to go bad more often, so much so it became routine for vendors, like Digital, to provide a book on how to actually make (with a soldering iron and logic chips!) your own replacement, or expansion memory!



There is also direct evidence of this in the books, of the skipping RAM and ROM, concepts... where you can still see references to the PWRUP functions, which established the power state (or power failure state) of AST (Async-System Trap) entry point addresses.  These AST entry point addresses were never ever 0x00, because... well that's just all the lines pulled low, i.e. no-power, and not indicative of the power being on, or off or in any state really.

Of course, I reference things from way before the PC era, when computers still came with manuals on the actual logic gates within...


Thanks to AlexeyBrin for posting my blog to Reddit, and thanks to all those whom commented, I had fun reading this one.

Thursday, 14 April 2016

Project - Socket 771 to Socket 775 - Xeon Conversion

I've been conducting an experimental project, one I've seen all over the net by others, but which had lots of different information... This is the conversion of a socket 775 motherboard to a socket 771.

First of all, why?... Why would we do this?... Well, the socket 775 is a commercial socket, supposedly sold to us mere mortal customers who buy one machine and one CPU at a time, and the motherboards and processors in the class were/are quite expensive.

We're talking about the Core 2 era, Celeron D, Core 2 Duo, Core 2 Quad.  I remember the Core 2 Quad machine I put together was really rather expensive at the time.  So, between six and eight years on, we're retiring those machines; yet they cost us a lot of money, and despite depreciation rates we users can still make use of these machines.  They can be useful as render farm nodes for 3D or movie work, they can be used as servers, to host basic information, or upload/download points, even as firewalls.  All roles they can fall into easily.

I personally am going to be using the machine I've got as a quiet webserver, retiring a venerably serving Pentium 4 Prescott for this old Dell machine.

So, what is the base machine?

Well, it's a franenstein, the in-laws have had me build them a new machine, so they had an Intel D31PR motherboard holding a Celeron D 450, and one gigabyte of RAM, a totally unhelpfully slow machine.  Even they noticed it was extremely slow.

From my spares they had enough parts to basically rebuild their machine, which I did, and it left me with their old motherboard.  I wanted to upgrade the processor, expand the RAM and add a RAID array controller card, but my budget is extremely low, we're talking £20.

Well on Amazon, I can get a RAID controller card for £13.. This left me £7... Hmm.. Luckily, the IT Department at work were able to donate to me some old DDR2 RAM, so I had the maximum 4GB the board can handle.

£7... Upgrade the processor?.... A challenge... Ebay... Core 2 Duo's and Quads, going for over £25 a pop, most of the Quads were going for £30+.  Way out of the budget.

But there were dual core Xeons for around £4... And I saw this hack out there on the wires, so I set about working.

The first step is to strip everything down, clean it perfectly, and get a scalpel.  The first part of the modification is to remove the tabs from the processor, these tell the user which way to orientate the CPU for insertion, they do nothing else... A consumer CPU is orientated horizontally, so there are tabs top and bottom to stop you inserting the wrong CPU.

And the Xeon has gaps left and right, meaning it'll bounce off these tabs on the socket 775.


Taking the scalpel, I started to cut the tabs, now I DID THIS WRONG!  A much better approach is to leave the current CPU in there, with the tabs engaged into the socket 775 CPU, and then cut between the CPU and the edge of the socket.  So the CPU acts as a guide and the delicate socket pins are protected out of sight below the CPU.



And clean the cuts you make up.



Remove any debris...



Then you need to go back to ebay, and buy a Xeon Socket Modification sticker, this is a little sticker, which will cover two rows of connections on the bottom of the CPU, it will allow most of them to pass through the plastic, but two pins are headed with a little connector, and behind the sticker these connectors actually swap the two pins over.

So, two pins, and the orientation, that's all that's different about a Socket 771 and a Socket 775 CPU.


The stickers are bar shaped, so they indicate which pin to swap, but lay the CPU down with the notches to the top, and from the bottom count 10 connectors from the bottom right, moving left... Voila, stick it down carefully.

Insert into the Motherboard socket now, so the notches are to the "top" of the socket, add the heat-sink assembly, and build it back up on your work bench.


Now, some videos and advice says you need to go to sites, and download patches for your motherboard.  During my project here I've found most Intel brand motherboards do not need any patching, only third party boards.  It seems Intel include all the microcode for all their processors (this is only a guess, I have no proof other than using five different intel boards, and two none-intel boards and always having to patch the non-intel branded ones, whilst the intel ones just work).

Then powering on...


It worked, I've gone from a Celeron D 430 to a Xeon 5130.  They're very similar processors, but the Xeon has dual cores and a much faster FSB.



My YouTube play list, for my crappy videos covering this project can be found here:

Wednesday, 4 June 2014

Virtual CPU - ROM & Interrupts

Interrupts are ways for hardware, and sometimes other pieces of software, to break into the flow of your CPU processing and tell it do something else.

This is my very friendly way of describing interrupts, unfortunately a lot of sources of good information drop people into the idea of these mystical beasts far too quickly.  I'm going to try not to drop you all in it.

Lets think about our CPU, and how we know it operates, our CPU has a Run function, which has a loop within.  This loop fetches an operation to carry out from the memory pointed to by the program counter and it acts on that instruction.

As we've seen from example programs we can also jump to a new memory address.

And if we took a close look at the Intel published datasheet from the prior post we'd also see that there are many other kinds of jump, jumps when things are equal, jumps when they're not, jumps for the sake of jumping...

Well, an interrupt is a special kind of jump instruction, which when the interrupt is signalled (triggers/fired - whatever term you want to use) gets inserted as the next instruction for the program to carry out.

The Interrupt instruction is special, because it tells the CPU to jump off to some piece of code elsewhere, but also remembers when that piece of code is complete to come back and pick up exactly where the CPU left off.

Like a function call in other programming languages, but at the CPU level.  In our programs therefore we now need to think about what state the CPU is in before and after an interupt is carried out (or handled).

Because the code in the interupt function might change the state of the CPU, and sometimes we don't want this.

A good example comes to mind from the very first real (i.e. not BASIC) programming language I learned, Pascal.  In Microsoft/Intel PC's running the MS DOS Operating system (16 bit) the BIOS had a set of standard interrupts, the standard interrupt number 11H (hexidecimal) was for the mouse, if this interrupt was triggered the mouse had moved, but we didn't want the state of the processor to have changed within our program, so when the interrupt handler was defined in our code we used to have to say:

"PUSH REGISTER STATE"

Before the interrupt code was run, and then when the interrupt processing was complete we would say:

"POP REGISTER STATE"

Lets look how an interrupt might work in our CPU Run function:

From left to right, we see our Program on our CPU... Then we see the Interrupt get signalled (some how) and the program counter is pointed to the new piece of code "A"... The Run function continues through the interrupt instruction codes and then returns to your program at "B", by setting the Program Counter back to point at your original programs' "next" operation.

The interrupt code could have changed any of the CPU registers or status flags, so it is at point "A" we must be able to Push, or save the current CPU state.  Then at Point "B" we must be able to Pop, or load the saved CPU state back into the machine proper.

We say "push" and "pop" as the structure we use to save and restore the CPU state is called a "stack".  I'll come back to that later, but you can check out an explanation of stacks here if you're eager to understand what we're talking about.

In our CPU however, we're not going to add a stack just yet, we're just going to add a set of mirror values for each CPU member variable.  In early silicon this would have been totally impracticle because of the cost of adding redundant duplicates of everything would have been far too costly... Those early chips might have therefore saved their registers off to memory.

Whatever they did the essence is the same as what we're now going to make our code do... it saves all the values somewhere.


So what might cause an interrupt and what might the code in an interrupt actually do?

Well, the most basic interrupt you will probably use today is the keyboard, as you press each key an interrupt is generated going off to the processor telling it that a key stroke has arrived.

The processor can then pick up and action the key stroke, adding it to data, or changing status however we instruct it to.

So where does the code for our Interrupts come from?  At the most basic level in your machine they come from the BIOS.  So the BIOS handles the key stroke, some store or queue many key strokes at once, and then they are handled by the processor as and when the Operating System software wants to accept them.

How might we add interrupt code to our CPU?  Well, from the last post we mentioned ROM's... We're going to write a ROM class and add to it key handling.


Right we've implemented our ROM class, then added the interrupt, now we can move into an interrupt and return from it, we also have the push and pop instructions added, so op codes 200, 201 and 202 are important to the interrupting process.

When we go into an interrupt the CPU changes state to start reading from the offset into the ROM, and it is up to the ROM code to return from that interrupt code.  The CPU has no idea when the interrupt is finished.  So the last instruction from our ROM function for an interrupt must be to return from it!

What might an interrupt series of byte codes in our ROM look like?  That's up to you!

In the next post in our series I'm going to write some platform specific code to let us read characters from the keyboard, until I do that however, we'll just pretend an interrupt has been called...

Friday, 30 May 2014

Virtual CPU - Signed Addition Clean Up & ROM Discussed

In today's CPU post I want to just clean up the signed addition example, we've covered the electronics but I've had a couple of messages asking how I might integrate switching into the CPU.

Well, simply for our Virtual CPU I'm going to include the signed addition based on the signed mode flag... We already had this signed mode flag in the CPU, and we default the flag to false or "off".

So that is a simple "if" statement within the "Add" function.

To integrate the switching we invent two new OP Codes, one to switch into Signed processing and one to switch to Unsigned processing.


I'll leave you guys to think about how the programmer has to remember which mode they were in, and hence what the bit patterns they have represent.

I'm also going to leave multiplication whilst in Signed Mode as an exercise for you to address yourselves, if you want to mail me your solutions, I'll happily take a look (if I find a minute).

So our op codes now run from zero to twenty-seven.  So with 28 operations what could a machine do?

You might think not very much, but the real 4004 (though not yet the same instruction codes as our virtual code) operated with just 46 instructions total, more than our code at present, but still not a lot.  Intel have kindly published scanned copies of their original datasheets and so we can peek into the depths of their instruction set here:


Numerically we can see almost immediately their instructions 2 and 3, are about Fetching... Fetching Immediate and Fetching Indirect (from ROM)... What is Fetching?  Well, in other machines, many assemblers and in our Virtual CPU the concept of Fetching is called "Loading" and we Load0 and Load1.  Both those instructions load from memory into the CPU, this is "Immediate" it immediately moves a value from volatile storage into the processor.

Indirect for our CPU would actually be the main program loading a program from a file, the file is our ROM or non-volatile storage and we load it into the RAM to use it.  However, we don't fetch from ROM.

I had been asked to add a ROM to the Virtual CPU, however, all a ROM is is addressable memory which can't be changed, so if you wanted to create a ROM yourself you can, create a byte array in your program, load from a disk file, or just insert data into the array upon construction.

And then add two new Op Codes you want to fetch from the ROM.  You can then add the ROM to your CPU as a reference...

I hope this gives you some ideas and you go a head and try to write a small ROM.

Next on our agenda will be "Interupts"... Stay Tuned.

Wednesday, 21 May 2014

Virtual CPU - Signed Addition & Endianess

From yesterdays post then, we should have learned something and perhaps even gone to look for a solution, you may have even coded a solution into the CPU code we're working on...

The solution I'm going with however is a total cheat, I'm going to add the Cout of the last adder back onto the result as a single full-adder...


Essentially we add the carry out into the first bit again.  But we only want to do this when using a Signed value... so we'll cheat and use out "Signed" flag to do this new function or the original function... Lets get on with creating "AddTwoSignedBytes":

void Electronics::AddSignedTwoBytes (
byte& p_Register0,
byte& p_Register1,
byte& p_Result,
bool& p_Overflow,
const bool& p_Debug)
{
bool l_CarryIn = false;
bool l_CarryOut = false;
bool l_Sum = false;

// For each bit we need to mask the
// right most bit out of the register
// meaning, we start at 00000001 and
// for each loop move the register
// so the bit we're interested is over
// the 8th position.


// Our mask never changes
byte l_mask = 0x01;

// For each bit we run the masking 
// then adder and handle switching
// the result into the register.
// You can find more efficient ways!
for (int i = 0; i < 8; ++i) // 8 bits in a byte
{
if ( p_Debug )
{
std::cout << "Cycle: " << i << std::endl;
std::bitset<8> msk { l_mask };
std::cout << "Mask: " << msk << std::endl;
std::bitset<8> reg0 { p_Register0 };
std::bitset<8> reg1 { p_Register1 };
std::cout << "Register 0 [" << reg0 << "]" << std::endl;
std::cout << "Register 1 [" << reg1 << "]" << std::endl;
}

// Get the A & B bits by shift & masking
// the register
bool A = ( ( ( p_Register0 >> i ) & l_mask) == 1);
bool B = ( ( ( p_Register1 >> i ) & l_mask) == 1);

// We have the carry in and the A & B now, so
// we can call the adder
// Because the Carry out, and the Sum, are separate
// in our code here, we don't need to alter "reg0" or
// "reg1", we can just logically add the bits set
// into the p_Result below!
Adder(A, B, l_CarryIn, l_CarryOut, l_Sum, p_Debug);

if ( p_Debug )
{
// This should be a value from our Adder trace table!
std::cout << "Adding: " << A << " " << B << " " << l_CarryIn << " | " << l_CarryOut << " " << l_Sum << std::endl;
}

// The carry out simply becomes the carry in
// I'm sure you can see one way to optimise this already!
l_CarryIn = l_CarryOut;

// Now the register change based on sum, but
// we also output the binary
if ( p_Debug )
{
std::bitset<8> resultBefore { p_Result };
std::cout << "Result Change: " << resultBefore << " -> ";
}

// Now the logic
// Now instead of pushing the logical
// summing into "Register0" parameter,
// we push it into the p_Result parameter!
if ( l_Sum )
{
// Mask is shifted, and always 1 in the i position
// so we always add a 1 back into the target
// register in the right location
p_Result = p_Result | ( l_mask << i);
}
else
{
// We know the mask is ON, so inversing it and moving it
// will give us an always off...
p_Result = p_Result & ~(l_mask << i);
}

// The register changed, so finish the debug statements
if ( p_Debug )
{
std::bitset<8> resultAfter { p_Result };
std::cout << resultAfter << std::endl;
}
}

//======================================
// Add the carry out to the first bit again
bool A = ( ( p_Result & 0x01) == 1);
// Take the first bit
Adder(A, l_CarryOut, 0, l_CarryOut, l_Sum, p_Debug);
// Now the logic
// Now instead of pushing the logical
// summing into "Register0" parameter,
// we push it into the p_Result parameter!
if ( l_Sum )
{
// Mask is shifted, and always 1 in the i position
// so we always add a 1 back into the target
// register in the right location
p_Result = p_Result | 0x01;
}
else
{
// We know the mask is ON, so inversing it and moving it
// will give us an always off...
p_Result = p_Result & ~0x01;
}
//======================================

// The final carry out becomes our
// over flow
p_Overflow = l_CarryOut;
}

So with this code, we need to test the function, lets add a new test function:

void Electronics::TestSignedAdd()
{
byte l_A = -127;
byte l_B = 7;
byte l_result = 0;
bool l_Overflow = false;

AddSignedTwoBytes(l_A, l_B, l_result, l_Overflow);

std::cout << "Testing signed add:" << std::endl;

int l_v = 0;
for (int i = 0; )

std::cout << "(" << (int)l_A << " + " << (int)l_B << ") = " << (int)l_result << std::endl;
}

Now, before we run the code, what do we expect to see?.. Well, we expect the value of -120, which has the the binary pattern 10001000.

Lets run the code and see...


What the hell just happened?... 129 + 7... That's not what our code says... and the answer is 136... What is going on!??!?!

Calm down, calm down, everything is fine... The binary pattern of the result is correct... see...


So what is with the values we see on the screen, if our register holds the binary pattern for -120, our result...!?!?!

Well, the signed binary for -120 is the same patter as the unsigned value 136!  Its as simple as that, our CPU is working its our C++ which has thrown us a curved ball.

The cout stream took the byte we send and converted it for display, but the byte itself has no knowledge of signing, it is infact an unsigned char when we defined it as a type.  So the binary might be perfectly fine, but the interpretation of that binary is wrong.

This is a case of being careful with how you test your code, and is an example where at least two tests are needed to confirm a result, never take the result of just one test as canonical.  Always try to find some other way to test a value you calculate, or validate your input, or put a bounds around your system.  Because when something goes wrong you always need to second check yourself before complaining to others.

In the case of this code cout is showing the unsigned values, and that's fine, we can ignore it because to get the true binary we can just use bitset...

#include <bitset>
std::bitset<8> l_binary (p_Result);
std::cout << l_binary << std::endl;

This is a lesson to learn in itself, always to check & recheck your code.

But now we have to think about the reprocussions for this in our CPU, even if we've set the signed flag the data are being stored unsigned, the memory is storing the values just as patterns of binary... And this is an important thing to keep in mind when you're programming, when you are working with a CPU, how the value is expressed is more important than how it is stored, because (hopefully) the binary representation is going to be the same all the time...

OR IS IT?

Unfortunately not, our binary we've dealth with so far is what we could call "Little-Endian" that is the lowest value assigned to a bit in the byte starts on the right, and we read the byte from right to left.  Essentially the opposite way we would read this very English text...


If we read the byte the opposute wa around then the values would be reversed:


This is called Big-Endian.

Intel processors have pretty much always been little-endian, whilst other firms have used big-endian, notable platforms using big-endian processors are the Motorolla 680x0 family of CPU's.  Yes, those of Atari ST's and Amiga's, the original Mac.. They all had bit-endian CPU's.

Some said this set a gulf between the two, and emulating between the two systems is very time consuming, because to emulate a big-endian processor on a little-endian machine used to mean a lot of overhead in converting between the binary representations.

Our CPU is going to suffer from this problem, because we've built it, and its adder to use little-endian principles, e.g. we start the adder loop from 0 to n-1, where as for a big-endian machine we'd want to start the adder loop at n-1 and go down to 0 to complete an addition.

A challenge would be to go back over our whole CPU and convert it for Endianess, making it a generic, configurable hardware implementation of a generic 8bit logical operating unit... I'm not going to do it, I'm just here to guide your experience.