• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
rAm_y_

How low a level do you understand between 'SW' and HW?

13 posts in this topic

Now I am not 100% sure what to ask here as I still don't haven't joined all the dots. So, how well do you understand the underlying connection between hardware and software.

 

For example, we use the word abstraction at this topical level, we can code some assembly language(which I know very little of), assembly it, and hey presto the 'mouse cursor' moves over the screen, or we could colour some pixels in.

 

But what is actually going on at the very base level. If you download mikeOS - a small OS written in assembly - well it is pretty cool, it displays a console type menu and also has a basic compiler. But it's really fundamental compared to modern OS's and I am trying to understand it, but that will be hard until I learn assembly language.

 

So we type in human readable language into the editor, compile/link it, and it magically switches on and off electrical transistors.

 

So say you were given a PC with a blank HD and you were asked to just create a mouse/icon tht you could move around the screen how would set about doing this. I understand that 80/90's 8-bit assembly programmers will have a good idea about this.

 

Where is the root point where we can start everything, does the hardware like mouse input have it's own firmware/software pre-built in that allow use it communicate with it?

 

If an assembler is the most fundamental piece of software how would you load it onto the HD/memory in the first place?

 

I think my real problem is that I just don't understand the complexity/structure and in built software of the hardware itself so I still can't make that connection between the 'software/text' that we see on the screen and the electronics themselves.

 

 

0

Share this post


Link to post
Share on other sites

Well, there's actually already software built onto your mobo which does a bunch of pre-setup work for you when the machine boots (BIOS for example). Then you have the fact that most CPUs actually run micro-code which means they're not just taking instructions, but can be flashed to get around buggy bits of silicon, etc.

 

and all of this is assuming its actually a real COMPUTER you're running on, since it could be entirely virtualized and thus you may not be talking to hardware at all, but software.

2

Share this post


Link to post
Share on other sites

There are a lot of pieces, and all of them are more complex than they appear at first glance. Core classes in operating systems and computer architecture help to clarify a lot of it, as do classes in computer and electrical engineering. Working on the various pieces (eg Linux kernel hacking) can also be very enlightening. But this is not a small or simple topic, and really having a thorough understanding of everything is limited to a relatively small number of people.

0

Share this post


Link to post
Share on other sites
One of things that you have to remember is that your concept of "mouse" is really just an area in video memory being written to in a certain way which would produce a recognizable image as "cursor". this is accomplished by operations at the cpu level that produce a value that the video output understands to be a certain "color". The reason why I use quotations is because these concepts dont exist to the computer, but are manufactured so that you as the user can intetact with the system to produce meaningful results. Assembly is just a human readable form of binary data, and what a higher end compiler does is translate its easier to read langauge into binary instructions for the cpu to assign memeory locations a value that can later be used to do something.
1

Share this post


Link to post
Share on other sites

how well do you understand the underlying connection between hardware and software.

 

That's a philosophy question, in that, at a very basic level, "software" is just a pattern stored in hardware, both on magnetic media and in RAM. A clock outputs pulses which cause a hardware state somewhere to change based on the state somewhere else in hardware. happy.png

Edited by Buckeye
0

Share this post


Link to post
Share on other sites

One of things that you have to remember is that your concept of "mouse" is really just an area in video memory being written to in a certain way which would produce a recognizable image as "cursor". this is accomplished by operations at the cpu level that produce a value that the video output understands to be a certain "color". The reason why I use quotations is because these concepts dont exist to the computer, but are manufactured so that you as the user can intetact with the system to produce meaningful results. Assembly is just a human readable form of binary data, and what a higher end compiler does is translate its easier to read langauge into binary instructions for the cpu to assign memeory locations a value that can later be used to do something.

 

And I know this, to a degree, and this is wha,t I am asking although couldn't put it into absolute words, I think I should really be told, 'go and do a degree in Electrical Engineering' or 'go and work for Intel' or 'buy an old mainframe/punch card computer and start from basic principles'.

0

Share this post


Link to post
Share on other sites

My understanding is that sort of thing is covered pretty well under a CS degree. I would think that would be the place to start looking if you're aim is to make a career in hardware.

I've forgotten a lot of my micro-controller education which I took back in the mid 90's (I just don't use it in my day to day work). About 10 years ago I came across the xGameStation.com website and bought one of their educational packages they offered at the time. Though I never started working with I found that the books, CDs, and equipment that were included covered everything that my college course had. I think the main difference was that they provided a PCB to work with while my college course had us wire wrapping IC sockets.

0

Share this post


Link to post
Share on other sites

There's an awesome book called 'CODE' which is a great read. It doesn't get you all the way there (and gets a bit lighter / fluffy near the end through necessity), but is enough in my view to feel comfortable about what is going on at the very lowest level - atleast in a simplified / early computer way. Modern computers and various layers from OS upwards are just extensions / additions. you won't regret reading it.

http://www.amazon.co.uk/Code-Language-Computer-Hardware-Software/dp/0735611319/ref=sr_1_1?ie=UTF8&qid=1405430673&sr=8-1&keywords=CODE

 

1

Share this post


Link to post
Share on other sites

If you are interested to learn low level assembly language on the PC, the "easiest" way is probably to install DOS Box, which is a nice piece of software that you can use to run really ancient software on modern computers.  Mac version is called Boxer.  The thing with DOS Box is that it emulates the environment of old, old "IBM compatible" computers as it were back then, with BIOS, VESA graphics, sound blaster, and all.   Another nice thing with good old dos, is that it ran in something called 'real mode', which basically is non-protected, segmented memory model.  Translated to more understandable phrases, that means you can take over the whole computer, set any graphics mode you want, play audio at the "lowest" level, or take over all interrupts without the operating system protesting at all.  Switching to a VESA graphics mode is fairly easy.  It is just calling one interrupt that is set up by the BIOS.  Then you can write directly into video memory to create all the graphics you want, all without the hassle to write a basic operating system yourself, with complex pre-loaders and loaders and kernel and hard drive interfacing and all those really hard, complex things.  I think what I used back in the day, was masm.

1

Share this post


Link to post
Share on other sites

If you are interested to learn low level assembly language on the PC, the "easiest" way is probably to install DOS Box, which is a nice piece of software that you can use to run really ancient software on modern computers.  Mac version is called Boxer.  The thing with DOS Box is that it emulates the environment of old, old "IBM compatible" computers as it were back then, with BIOS, VESA graphics, sound blaster, and all.   Another nice thing with good old dos, is that it ran in something called 'real mode', which basically is non-protected, segmented memory model.  Translated to more understandable phrases, that means you can take over the whole computer, set any graphics mode you want, play audio at the "lowest" level, or take over all interrupts without the operating system protesting at all.  Switching to a VESA graphics mode is fairly easy.  It is just calling one interrupt that is set up by the BIOS.  Then you can write directly into video memory to create all the graphics you want, all without the hassle to write a basic operating system yourself, with complex pre-loaders and loaders and kernel and hard drive interfacing and all those really hard, complex things.  I think what I used back in the day, was masm.

 

If someone wanted to how software was run on a processor at a low level, I'd advice looking to a RISC processor assembly 1st, like MIPS.  MIPS assembly is easy to understand (compared to intel), and the commands fit nicely into 32-bit machine code.  SPIM is a nice MIPS simulator that you can use to practice assembly.

2

Share this post


Link to post
Share on other sites

I suggest you read CODE. I had the same questions you had, and this book does a great job of clarifying it. I don't think anyone here can explain this better than the author of that book.

0

Share this post


Link to post
Share on other sites

Where is the root point where we can start everything, does the hardware like mouse input have it's own firmware/software pre-built in that allow use it communicate with it?

Ultimately everything is built on analog circuits. But for where software starts, it's at a higher level. Micro controllers and CPUs are circuits that take machine code as part of their operation. This is what allows them to be so general purpose; if you don't need your computer operation to be mutable you can use an application-specific integrated circuit(ASIC). All software is compiled into machine code.
 

If an assembler is the most fundamental piece of software how would you load it onto the HD/memory in the first place?

Memory has a controller built into the CPU. Machine code has instructions for interacting with memory, and the CPU makes memory do the right thing.

A hard disk has a built in controller chip in the enclosure, quite possibly an ASIC. There is a protocol for talking to harddisks and other peripheral hardware (ie hardware that's not part of the CPU operation), usually by mapping certain memory addresses to talk to the device.

Machine code is bit code for assembler, and assembler is source code for machine code; one is efficiently packed, the other is human readable. All software in some form or other becomes machine code, although higher level languages may have an interpreter in the pipeline.


I think my real problem is that I just don't understand the complexity/structure and in built software of the hardware itself so I still can't make that connection between the 'software/text' that we see on the screen and the electronics themselves.

That's computers for you. Layers on layers of abstraction. In fact the point is that you don't need to just to write programs. How machine code is converted into the operations it specifies is the field of computer architecture, which basically describes in digital logic, the silicon in a CPU. Talking to peripherals is it's own field. So is the design of peripherals so that they can talk to the CPU.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0