There are a lot of free ware open source programs out there. I was just thinking how easy it would be to reprogram, in like one line of text if not less, to include more pixels into the graphics, that would soup up the graphics to the next generation for a more powerful processor. this would be like saying to stretch the graphics more, except they will actually just be condensing the graphics with, i stand corrected, not more pixels, but splitting pixels into more colours. this is because the graphics are pixels carrying a charge, which relies on hardware, not software. this means we could easily have two or three colours into one pixel, giving more definition to them, of course. How about sound? how could we soup the sound up to be more than it is? maybe we could do that by making the program more sensitive, as, the sound card is only 'doing it's best' with some sound engineering programs - we want to get more out of the sound card with only programming, so, we could take a page out of sound engineering and begin the right sound at the right time, again, a line or less of programming code without worrying about the hardware.
When it comes to programming functions, there are ways to shorten it with the use of mathematics. if, say you want to make a 'menu' for something like a 'access program,' where you need to put in 'names and sections' for the information, then typically the programmer would type out the field and optional input parameters or block height and width, how many unknown values of the alphanumeric sort to put in there and then 'link them together.' this would be typical programming, and, it would take a long time to input width, height, x values and link them up. Alternatively, the programmer could use maths for the whole thing. this would be 'x height,' etc, only 'show letters' in field and linking could be done by assigning them 'robot names' to be linked up to each other, of course.
With the actual programming, the whole thing should be, as i have always believed, set up into robots that interlink with information, as a side menu. this will speed up programming time, as they will all be simply typed out - maybe in another font size? - a collection of robots, which are summed up functions, into the cycles of functions, of, "if this, then this." With that in mind, making a access program could be down to fewer lines of code! this would mean that you set up three varying templates for text and numbers, a calculator to differ the values you use and the letters for reference - of course to allow numbers and letters into the same field - and robot names to link the calculations of numeric types, and, include the letters for reference. This is all good and well, but what about when people make mistakes? this could be set up as a block of the operation if the program 'does not comply' or feels confused. in fact, computers never feel confused, as they just do what they are told.
You might be wandering how this changes things? let me explain how programs work, and how i am suggesting they work; Programmer types text for the function. programmer enters text for the operation. programmer types field values for the input areas. programmer types relays for the links. in other words, nearly everything is 'force fed' into the program. Now, what i am suggesting is that the programmer types the fields with x values, so the person may adjust them, types the names of common functions to use later, types links with the if this then this ideal. in other words, the things need to be flexible and so forth. If my estimations are correct, we could make access take up a tenth or less of the file space on windows.
Another thing to remember when programming is that you can copy and paste code for a lot of the things. some call this sloppy programming, but, by editing the robots immediately, you could cut your time i half, except for the amount of text used. This is why you should enter the descriptions of variables or [x]. this would be where you write one robot for working out sums for tens and units and hundreds, or, you write one robot that uses an [x] for a lot of the program, where, the robot simply adjusts to the end user. this saves time, uses less space so it is easier to check for problems, and otherwise will stop from cycling over to the next robot with a miss - remember, it needs to read the whole block of text before it knows not to use it!
You may still be confused as to what my programming will look like, yes? let me try to explain to you how it will pan out for access, which is somewhere between word and excel and a typical accounts program; First you enter the name of the program for keepers sake. then, you begin to write 'white background,' and 'if exit, exit program.' then, you would write the titles and footers of all the screens you want to use, and, the fields of those 'screens.' these we call robots, as, they perform a specific function. Then, you want to, after naming about twelve robots for the menus, make robot fields for the values, maybe up to ten of them? these will be done by coding that the mouse selects the field, so field is [a]. 'set field mouse select [a] or something,' yes? then, you want to insert your numbers into the field, so will display entries as if text - yes, as if text. then, reading text to come up on a simple calculator program - something separate maybe? - that you can find twelve for a cent out there is easy. If you want it to calculate properly, you need to set field [a] to link with field and [x], so that field [x] is added fields [a - v] or so. hell,you can call field [x] where all the sums come to a conclusion field [pop eye the sailor man] for all anyone cares, so long as it is constant. the main thing is that all a - z or so comes to add or relate parameters or instruction to 'bodmas' the instructions as they should be. Then, you stabilize the program by entering exits and "incorrect command or file name" as to merely return to saved program display and functions, and there we go. there is your access, shorter and more powerful than before.
Now it is time to program graphics and sound too! what can we do to make the graphics simpler and quicker, and the sound needs to be clearer, of course, yes? this means we need to use the hardware to it's potential, of course. If we were to observe that the graphics are based on files of programmed pixel generators of lights of different colours, that is all graphics are, pixels that light up. they all have a different charge to relay the right colour to us so we can see them, from the base of sixteen colours in the beginning to billions of colours today. to get the most out of the graphics, we could program pixels of pixels, where the shade carries over the pixel of the pixels, meaning, that each graphic file is listed as a certain colour, and, the file can be coloured in by the artist or programmer, yes? Then, we could also find a way to sensitise the sounds by having files have multiple usage over certain times - they would combine files to make whole new sounds. of course, if all the sounds are used at the same time, they will make 'a loud black noise.' this would be like mixing colours for the palette you are using to paint with.
Programming the r.o.m. chips should be the onus of programming, as, these will control the pathways and speed of the computer more than a c.p.u. will - in other words, you see those little black boxes on your mother board? they will speed up the computer more than r.a.m. and processor speed. i say this because the r.a.m. is plugged into the board, so it needs to go there, get processed, then leave there. I am proposing setting the motherboard up with installed r.a.m. this would see the computer use the 'nervous system' of the bus like a spinal chord and then deliver these things right through it - in fact, the bus should travel through these devices, to dispatch and recoup information quicker, yes? This would see the circuits being less, as the going in and coming out is like 'a huge dam with a little tap,' where if you had a huge wide pipe running through the dam, 'drawing water' from all around the wide radius, it would be much faster,
With the commodore slash new computers we will be manufacturing, there needs to be an easy way to port things over from other programs to our computer. Basic was a r.o.m. chip, that was recorded onto a tape drive, this was the hard disk, i think? the rest of the r.o.m. or read only memory was set up to execute programs ported into the r.a.m. from the tape drive. this means we require hard disk space that interprets the r.a.m. as space used on the hard disk, by storing answers or way points, conclusions and data onto this newly afforded space. this should be done by using the same mechanisms as the porting from records to compact disk, if you ask me, as the hard drive has a similar storage method, having 'a rotating disk.' To 'grab' from c++ to basic, we need to enter commands from c++ - not that many, just the diploma course books or commands for each robot and other 'areas of the program,' into [a + b + c] commands or instructions, code if you will, equals new commands synced with the basic programming outline, or, Turn all the code into robots. this would be where if object or robot [a] is affected by this other robot, they must come to a resolution on a command to be performed, through making a copy of the 'mixed robot.' this would group all robots that are under the same influence to become one robot, that has many operations, and, then copy it like a pyramid, linking them together. the robots should keep their names, so we will see, with commas, which code is inside the robot, and, then roll that whole 'robot' into a program, of course, thus 'compiling,' yes?
Have you ever read those sites that say you can make your own programming language? often i have wondered, how hard can it be? of course, your first attempts will not be very good, as you will make them specifically for certain things, yes? this is why i am going to give a very basic, and, concise outline for what i would like to see in a programming language. First, the bios. the bios uses a special type of language that get's hard wired between the chip and the mother board to 'search for devices.' this should not be changed too much, unless my further gobbledy gook makes you think twice. Then, the actual language. this should be summed up as follows; [1] Executable files. these are when actual interaction takes place. there are six types of executable files, requiring six types of suffixes. graphics, sound, operations, cease operations, cue robot, cease robot. this is my idea of a basic executable file listing for the programing language. [2] Robots. these should be down to 'values and value changes,' for the information and linked display properties for the computer to keep track of and display in text or other means if need be, 'fields' where the values are grouped and 'interaction permissions' or orders for having the robots affect one another. That is about it, i think.
Now comes the idea i have had for a long time. binary uses on and off switches, yes? then i thought of how they get grouped into eight bit parts, and, multiples of eight bit parts. this sounds very slow, as, the computers i had when i was young were indeed slow. so, you could compare this to engines of the first cars becoming what they are today with computers as what was and is, yes? If we were to be honest, this is very slow - imagine a computer that will jump a few levels by being able to recognize 'words?' that would go much faster, and, would lift the standard of computers no end, resembling light years of evolution, like 2100 style computers now, of course. The way the binary gets grouped to perform the operations could be simplified by having, well, more advanced maths, yes? it works of addition at the moment, what if it was to work on multiplication too? running logarithms could be worked out easily at a binary level by having mirrors in the processor and bus to copy over recurring information, like recurring fields for access or excel. Maybe we could program shapes into 'the language?' this could be done by imprinting shapes into the binary circuits, maybe with a shaped transistor. this could carry a 'direct outline' in binary onto the screen, of course, making graphics programming much easier. Then, the full on 'sound bits.' this would be easily achieved by having a 'piano' of 'key system' built into the binary, where, the keys are programmed into respond to the binary that is goading them. Then, the alphabet could be programmed in at a sub binary level. the letters a through z would be twenty six letters, and, they could operate with over clocking a circuit, where, it being made of silicone, will actually not 'suffer' at all.
This is exactly the sort of thing that's going to define computer science for the next few decades. Programmers have been spoiled by massive advances in hardware, and haven't focused on efficiency/innovation in a long time. Now that hardware is slowing down, the next Bill Gates will be a guy like you, coming up with new and better ways of interactive with the machine. Keep going, man. Get a small core of people around you and form a business. Build a kernel, or a language, and change the world.
With programming fields, something that goes into every type of processing document, where you need to have a space to operate in, or, get a alphanumeric character reading out to you, you need only have a direct interface between [x], [z] and the field. This could be summed up as, write, then read, until rewritten, yes? This could be made easier by having [blank], then, [active] for input. Then, it should be, for a spell check, [compare] to a dictionary, and, [sum] for a [listed or other] [input type]. This would sum up the whole robot, yes? For graphics, which is where the real problems with cad key and biology programs are involved, where games especially - a real money maker! - are concerned, we could, based on my first idea, instead of splitting the pixel, seeing as how there are so many anyway, and, there are limits to the hardware while software and programming come down to a mere word or line of text, we could sextet the colours, to include, wait, up to seven by seven, coming to forty seven, times the colours, with the little paint brush going into those six billion odd colours. This would 'rotate the pixel' so that we can mix the colours inside the pixel and then make them sharper, yes?
It is clear that this is all new to you. Keep this passion as you move through new new languages and discover old ones. I strongly recommend moving to linux, and discover bash, sed and awk. Learn lisp, erlang and machine lang. OOL will make you lazy and stupid without it. These langs were developed in the 60s and earlier because every charachter cost precious processing. Invaluable in becoming a ninja.
Okay, seeing as how sound is rather important, even though on the circuit board they are built in today, we could make it easier to put these things together, and, cheaper. I am not sure if I will now demonstrate a similar or better technology, I doubt it will be worse, but in the end it will be cheaper and easier to put together, I bet! If we were to observe that sound is a massive thing, that it carries mass, we need to carry mass in sound waves. Yes, I have proven the wave model long ago, and, I am going to build on that now. The wave model states that sound is carried in waves, like all mass, and, these waves are carried all over the place. This is like when there is 'friction,' there is 'radiation,' like things radiate, okay? This means that a little bit of it, in excess energy, is carried to the senses for us to sense. This is radiation just like the radiation from nuclear facilities, but, it of another kind - yes radiation is energy! So, we want to make sounds or sound cards that carry sound on a mechanism for us to hear, yes? This means we need to find a way, as I have done the physical device already, a programming technique, as the title of this thread, for the sounds? Of course, if we were to observe that sound is carried in notes by arts, and bits by computers, and it would be hard to carry a whole new type of note type to the computer, but a lot more handy, we could maybe program a note as to the name into the computer? This would require a new dictionary, a dictionary of notes and names, yes? Having direct interface where we could belt feed the notes to the computer, or have them read them is not necessary, as, they will, with a small amount of time, be 'fed' into the device, yes? The device itself, even though I have made so many varieties, as I prefer hardware, should work on charges being realized, from the circuit board, to pulses of energy to strike at, mechanically, from the mechanism to the diaphragm to generate the sound, with friction supplying the charge. Charge is not magically transformed into motion, it is a potential energy that carries it - how does electricity strike at a part? If you were to observe that the charge will carry energy, like our blood carries sugar, how does the sugar power our body? Well, it supplied the fuel to be burned by the body, much easier to understand than this, take it fro me! This charge will go into the mechanism, and, as electricity is electromagnetic, where magnetism is the physical force and polarized by the weak force, electricity, the electricity will be sent there, and, attract protons to collect around it and produce motion, okay? This is where we need to program the circuit board, through the bus and other devices, to produce this charge in a way - frequency - or, density of charge to produce this motion, and, then in different charges of motion, of course. Now, the correct language is to say; [name of note] = [charge type] = [charge]. This will send the right note through e bus to the device, hopefully.
