There hasn't been much progress on my various topics in information representation, but I think I'm going to switch the order and consider characters ahead of numbers. One reason is that characters are more general, but the other is that usually, each of them takes up smaller space. I'm running across character strings more and more often in my reviews of Assembly language and C++.
I haven't made a whole lot of progress in the hardware, but I'm starting to inch into it, especially in considering video in more detail.
I'm also starting to get a little more detail on the BIOS services.
I'm getting a reasonable, workable picture of assembly. I have enough of the syntax organized to be useful, and I'm familiar with the basic data types. There are still some assembler directives to work on, but I'm making progress on program structure, and on the maechanics.
There's been less progress on BASIC or C, but still a little.
I got an Assembler version of the program I did working (though I had to look at the results in the debugger, since I still don't have output routines). I also got a BASIC Version and a C version working and running.
One of the differences between Assembly language and C is that the roles of the various operators and expressions is different. In Assembly, all the operators are applied and expressions evaluated at assembly time. In C, most of the operators are applied and expressions evaluated at run-time.
Tuesday, April 29, 2008
Friday, April 25, 2008
Small gains
My explorations in the the explanation of video hardware and its operation today were uninspiring, especially since my principal source is seriously outdated. I use it because I want to learn the basics, the older way, in order to see how things have changed or improved.
I did a little more digging into the BIOS. I'd written down a number of the interrupt vectors, and in the process of checking them over, I found that several of them had changed: that is, there were different values in the segment part of the address. I'm not sure what the pattern is. I haven't actually tried disassembling any of them yet, although I may get around to doing that.
I did a little more organization of my notes on assembler syntax and the operations used by the assembler; Directives including symbol definition (the equates, giving names to constants ) and data definition are getting attention. Assembly language devotes more resources to the to the size of its variable than their contents, which are left up to the programmer. As far as assembly instructions I am considering mostly (unsigned, single byte or word) addition, and I'm trying to get a better handle on the various addressing modes used by the instructions. I'm also starting to work on the unconditional and conditional jumps and the call instructions.
I touched only lightly on Basic programming, with a look at the assignment (let) statement.
In C programming, I made little progress in any any one area, but more significant progress in others. The distinction between integer and floating point types is significant, again with most of the emphasis given to the integer types. Well. I'd like to have a better look at floating point arithmetic, but it's not really critical at the moment.
I also gathered some information on the phases of programming design. In the middle, implement (build) or coding stage, I sorted these out into comments; the use of descriptive names for variables and routines, and the formatting of programs, such as indentation and spacing.
I finally decided to group the execution of the program with the last phase: testing and maintenance. This is because in translated language, the assembler and compiler usually turn up a batch of syntax errors, which must be fixed. Then there are linker errors, and finally the logical errors; in which the computer finally does exactly what you told it to do, which is not necessarily the same as what you meant to tell it to do. Testing to uncover hidden bugs is a more advanced process.
I thought I'd try to implement the programming cycle for a problem I borrowed from one of my physics texts. If a man runs a four minute mile, what is his average speed in miles per hour and feet per second? The design wasn't hard for such a trivial problem, but exposed a number of difficulties.
First, in the assembler, I didn't have output methods. I know how to print a character or a string, but a number has to be translated to a character or string in order to display it. Second, several assumptions wound up being hard-coded into the program. I need to go back and document these before I do an updated version.
Methods for doing output are part of the language in BASIC: what was lacking was facilities for defining symbolic constants. Conversion factors "Feet per mile", "minutes per second", Seconds per minute" so I had to use constants.
The version I was best pleased with was the C version. I haven't tried running either the BASIC or the C version of the program yet: I was happy to get through the writing phase.
The answers are 15 mph and 22 ft per second: sure I can do it by hand, but the question is, can I get the computer to do it? Then, for any given distance? Any given time? Distances, time, and speed given in whatever units I like? Then, what if the speed and distance or given, or speed and time? And what if the speed varies? What about other physical quantities,
While the programs may be trivial, they are first steps toward a larger goal. One of the reasons I faltered in my progress in science was that I hated the drudge work of doing conversions between systems of units. If I can get the computer to do it for me, I can go on to more interesting concepts. At least, that's the idea.
I did a little more digging into the BIOS. I'd written down a number of the interrupt vectors, and in the process of checking them over, I found that several of them had changed: that is, there were different values in the segment part of the address. I'm not sure what the pattern is. I haven't actually tried disassembling any of them yet, although I may get around to doing that.
I did a little more organization of my notes on assembler syntax and the operations used by the assembler; Directives including symbol definition (the equates, giving names to constants ) and data definition are getting attention. Assembly language devotes more resources to the to the size of its variable than their contents, which are left up to the programmer. As far as assembly instructions I am considering mostly (unsigned, single byte or word) addition, and I'm trying to get a better handle on the various addressing modes used by the instructions. I'm also starting to work on the unconditional and conditional jumps and the call instructions.
I touched only lightly on Basic programming, with a look at the assignment (let) statement.
In C programming, I made little progress in any any one area, but more significant progress in others. The distinction between integer and floating point types is significant, again with most of the emphasis given to the integer types. Well. I'd like to have a better look at floating point arithmetic, but it's not really critical at the moment.
I also gathered some information on the phases of programming design. In the middle, implement (build) or coding stage, I sorted these out into comments; the use of descriptive names for variables and routines, and the formatting of programs, such as indentation and spacing.
I finally decided to group the execution of the program with the last phase: testing and maintenance. This is because in translated language, the assembler and compiler usually turn up a batch of syntax errors, which must be fixed. Then there are linker errors, and finally the logical errors; in which the computer finally does exactly what you told it to do, which is not necessarily the same as what you meant to tell it to do. Testing to uncover hidden bugs is a more advanced process.
I thought I'd try to implement the programming cycle for a problem I borrowed from one of my physics texts. If a man runs a four minute mile, what is his average speed in miles per hour and feet per second? The design wasn't hard for such a trivial problem, but exposed a number of difficulties.
First, in the assembler, I didn't have output methods. I know how to print a character or a string, but a number has to be translated to a character or string in order to display it. Second, several assumptions wound up being hard-coded into the program. I need to go back and document these before I do an updated version.
Methods for doing output are part of the language in BASIC: what was lacking was facilities for defining symbolic constants. Conversion factors "Feet per mile", "minutes per second", Seconds per minute" so I had to use constants.
The version I was best pleased with was the C version. I haven't tried running either the BASIC or the C version of the program yet: I was happy to get through the writing phase.
The answers are 15 mph and 22 ft per second: sure I can do it by hand, but the question is, can I get the computer to do it? Then, for any given distance? Any given time? Distances, time, and speed given in whatever units I like? Then, what if the speed and distance or given, or speed and time? And what if the speed varies? What about other physical quantities,
While the programs may be trivial, they are first steps toward a larger goal. One of the reasons I faltered in my progress in science was that I hated the drudge work of doing conversions between systems of units. If I can get the computer to do it for me, I can go on to more interesting concepts. At least, that's the idea.
Thursday, April 24, 2008
They still work
Late last night I picked one of my books on numerical methods in C, and found a reference to how floating point numbers are treated in the PC family. I was looking for information on how they are formatted for calculations on the old 8087 math coproccessor and its descendants which were incorporated into later Intel processors, but I didn't find it. I didn't fund as much as I wanted to on numerical methods in general, but I do have book back in Nebraska on the subject. However, information on floating point calculations at the machine level is pretty sparse in all my available materials.
Most of what I looked carefully at in C was rehashing things I've already studied, and likewise with C, Progress in assembly also fairly minimal. I'm inching toward being able to use the BIOS routines, which also brings in looking at the interrupt vector table in low memory.
The larger accomplishment came in testing out the mechanics of programming on the three languages I am working on right now.
The night before last I downloaded Turbo C from the internet, and in the process of trying to set it up, accidentally erased everything that wasn't in a separate directory from my C: drive. I tried to undelete it, and found that Win98 doesn't include the undelete command that Dos 5 used to, and since I hadn't gone through the recycle bin. Those files may be theoretically recoverable, but I'm not counting on it. But they included the autoexec.bat file, which set up my assembler TASM for use: I'm not big on mixing working files with those that the assembler itself uses, so I uses a separate work directory. I also recall a config.sys file, which I think tells DOS how to set up my CD, but I may be able to get that back another way. On the positive side, I did get Turbo C set up.
So, I tried everything out. I had several sample programs available for testing: Assembly language. I also had some experience with what can go wrong with assembly language: First, about four typos kept the program from a program from assembling at all, then it wouldn't terminate properly. I rebooted in DOS mode and tried it there, and after it did what it was supposed to, instead of quitting like a well behaved program should, it started giving me garbage on the screen. The, after a keypress, more garbage. What??? So after another reboot, I went back to the source (for the fourth time.. and found it. Instead of the DOS exit routine at interrupt 21 hex, I had sent it to 21 decimal, which was used on the original IBM-PC to set up for cassette tape services. I have no idea what that routine does now except Nothing Good if you call on it by accident.
The trial of BASIC (GW BASIC if you must know) worked well, except for my dyslexia of the fingers, until I was done and wanted to exit the interpreter. Quit didn't work. Exit didn't work. Bye didn't work. Stop didn't work. So another reboot and a hunt on the Internet for the documentation I'd noticed but glanced over last week. Oh. System is the magic word. Well, that wouldn't have occurred to me.
The trial of Turbo C worked better. I This was the compiler I used to learn C, so I was already roughly familiar with its quirks (once I remembered how to send the compiler output into my working directory instead of mixing it up with the compiler's own files). One of the sample programs used an escape code to create a "beep" sound. So, I wondered, will I get a beep?
No such luck. Down with the beepy DOS, up with the musical"Windows" sound. Could I get something else?...maybe, if wanted to do it bad enough to figure out how.
So, I've refreshed myself on the mechanics. Now, If I only had some creativity...
Moving on to physics, I did a little review of mechanics and the mathematical preliminaries. This is the kind of thing that tends to lead me off on tangents, so I'll mention it more later.
Sometime way back when, I picked up a copy of the chemistry textbook I used in high school. No, the fundamentals of chemistry haven't changed as much in 40 years as the state of the art in computer hardware, but a glance through the contents suggested that some concepts I've been a bit fuzzy about are more clearly explained there than in some more recent college-level textbooks.
I've noticed that I've included some computer jargon. Sorry, there's no help for it: I've reached a point where I baffle the beginners and bore the professionals by belaboring the obvious.
PS. One of the sample programs was one for calculating the worth of your weight in gold. So I had to know. I looked up the current price on the internet and modified the program accordingly, put myself on the scale, and came up at just under 5 million dollars.
Most of what I looked carefully at in C was rehashing things I've already studied, and likewise with C, Progress in assembly also fairly minimal. I'm inching toward being able to use the BIOS routines, which also brings in looking at the interrupt vector table in low memory.
The larger accomplishment came in testing out the mechanics of programming on the three languages I am working on right now.
The night before last I downloaded Turbo C from the internet, and in the process of trying to set it up, accidentally erased everything that wasn't in a separate directory from my C: drive. I tried to undelete it, and found that Win98 doesn't include the undelete command that Dos 5 used to, and since I hadn't gone through the recycle bin. Those files may be theoretically recoverable, but I'm not counting on it. But they included the autoexec.bat file, which set up my assembler TASM for use: I'm not big on mixing working files with those that the assembler itself uses, so I uses a separate work directory. I also recall a config.sys file, which I think tells DOS how to set up my CD, but I may be able to get that back another way. On the positive side, I did get Turbo C set up.
So, I tried everything out. I had several sample programs available for testing: Assembly language. I also had some experience with what can go wrong with assembly language: First, about four typos kept the program from a program from assembling at all, then it wouldn't terminate properly. I rebooted in DOS mode and tried it there, and after it did what it was supposed to, instead of quitting like a well behaved program should, it started giving me garbage on the screen. The, after a keypress, more garbage. What??? So after another reboot, I went back to the source (for the fourth time.. and found it. Instead of the DOS exit routine at interrupt 21 hex, I had sent it to 21 decimal, which was used on the original IBM-PC to set up for cassette tape services. I have no idea what that routine does now except Nothing Good if you call on it by accident.
The trial of BASIC (GW BASIC if you must know) worked well, except for my dyslexia of the fingers, until I was done and wanted to exit the interpreter. Quit didn't work. Exit didn't work. Bye didn't work. Stop didn't work. So another reboot and a hunt on the Internet for the documentation I'd noticed but glanced over last week. Oh. System is the magic word. Well, that wouldn't have occurred to me.
The trial of Turbo C worked better. I This was the compiler I used to learn C, so I was already roughly familiar with its quirks (once I remembered how to send the compiler output into my working directory instead of mixing it up with the compiler's own files). One of the sample programs used an escape code to create a "beep" sound. So, I wondered, will I get a beep?
No such luck. Down with the beepy DOS, up with the musical"Windows" sound. Could I get something else?...maybe, if wanted to do it bad enough to figure out how.
So, I've refreshed myself on the mechanics. Now, If I only had some creativity...
Moving on to physics, I did a little review of mechanics and the mathematical preliminaries. This is the kind of thing that tends to lead me off on tangents, so I'll mention it more later.
Sometime way back when, I picked up a copy of the chemistry textbook I used in high school. No, the fundamentals of chemistry haven't changed as much in 40 years as the state of the art in computer hardware, but a glance through the contents suggested that some concepts I've been a bit fuzzy about are more clearly explained there than in some more recent college-level textbooks.
I've noticed that I've included some computer jargon. Sorry, there's no help for it: I've reached a point where I baffle the beginners and bore the professionals by belaboring the obvious.
PS. One of the sample programs was one for calculating the worth of your weight in gold. So I had to know. I looked up the current price on the internet and modified the program accordingly, put myself on the scale, and came up at just under 5 million dollars.
Wednesday, April 23, 2008
Back from hiatus
For the past month I've added nothing to this blog, because I've been intensively involved in, well, a self-education (or rather re-education) project. My brother has sent me some of my personal library which has been sitting in his garage in Nebraska, and it included about half my computer programming reference library. Another box of books included most of my physics and chemistry references.
So, I've been absorbed in reviewing my computer programming. My skills are old and rusty and somewhat behind the times..actually, I've been 5-10 years behind the technology since the 1970s, and struggle to catch up. I've updated the "About" page on the SKB site to include more of my intellectual history, as well as links to my studies on logic and science fictional world building. I intend to create a "Poor Man's Computing" page to include information on older languages and systems that have been abandoned by the Micro$oft empire in its pursued of the latest and best technology.
Also, since I have my physics and chemistry references now available, I may be doing more work on those sections rather than the history which has been my primary interest for the past while.
So, I've been absorbed in reviewing my computer programming. My skills are old and rusty and somewhat behind the times..actually, I've been 5-10 years behind the technology since the 1970s, and struggle to catch up. I've updated the "About" page on the SKB site to include more of my intellectual history, as well as links to my studies on logic and science fictional world building. I intend to create a "Poor Man's Computing" page to include information on older languages and systems that have been abandoned by the Micro$oft empire in its pursued of the latest and best technology.
Also, since I have my physics and chemistry references now available, I may be doing more work on those sections rather than the history which has been my primary interest for the past while.
Subscribe to:
Posts (Atom)