A front panel was used on early electronic computers to display and allow the alteration of the state of the machine's internal registers and memory. The front panel usually consisted of arrays of indicator lamps, toggle switches, and push buttons mounted on a sheet metal face plate.
Packard Bell 250 与 Data General 机器类似，但（值得注意的是）它有一个内置加载程序并配有一个编辑器。因为它有一个延迟线存储器（将其视为类似于磁盘磁道的东西），所以您可以沿着延迟线放置指令，这样当上一条指令完成时，下一条指令恰好出现在“头”下方。谈论优化的痛苦……它有一个伟大的特性；当你感到沮丧时，你可以敲击CPU，机械冲击会让机器忘记一切。一时间非常满足。然后你必须重新开始。
啊，与“你们过去的日子”联系在一起。
(Converting a short remark with lots of follow on questions from OP into a long answer:)
I entered bootstrap loaders through switches on Data General Novas (16 bit machines) in 1969. For an Packard Bell 250 that I toyed with in 1967, there was a Flexowriter equipped with a paper tape reader, to load the program in the delay line memory.
For the Nova, there was one row of 16 toggle switches, and a half dozen other switches whose functions were "Set Memory Address", "Deposit Word and advance memory address", "Single Step" (we used that a lot for early debugging!), "Run" and "Halt", IIRC.
The Nova initially had 4096 words of 16 bit memory, the worlds ugliest RISC instruction set with 4 16 bit registers (stack? who needs a stinking stack?), and something like a 1 microsecond memory cycle time (instructions took several cycles). The machine had a "serial port" that connected to an ASR33 Teletype (10 characters per second), and we splurged for a high-speed paper tape reader and punch.
It initially came as bare hardware, with a paper tape containing a two-pass assembler that read source from, well, the paper tape reader. We initially wrote assembly code source onto punched paper tape directly with the ASR33 Teletype; this including "rubout" punches to wipe out characters that were wrong. Editing was incredibly painful. A cohort wrote a bad editor as the very first thing, that read a paper tape into a buffer in the computer, let us find lines, delete lines, and insert lines
My first job was to implement a Kemeny&Kurtz style BASIC interpreter on this. Two years later we added 4K more words and 100K word head-per-track disk, and I built a multiuser timesharing system on it, both written with that ugly editor. Ugh. I built OSes on various machines for the next 20 years.
The Linkers/Loaders books talks about "linkers", that combine multiple object files. Our assembler didn't bother; it produced, for your assembly code, a directly loadable binary paper tape. That tape was designed to be loaded by a tiny program that was entered, well, back to the opening of this discussion, a 30-odd word bootstrap program entered from the front panel. After each program run (usually ending in "crash") we usually had to re-enter that boot loader; we got pretty good at since we often did it several times a day.
Regarding coding forms: people did write code on such forms, and then somebody else often "punched" them onto paper tape. The purpose of the form was to make sure the person doing the punching put stuff where you said, and made you the coder rather more careful about pensmanship in what you coded (I still print block capitals pretty neatly). It didn't take us long to realize that you could code free-form, and after that I did most of my coding on graph paper with faint lines so it looked sort of neat before typing it into the editor.
You couldn't effectively hack online with the text editor; it didn't hold enough text for you to cut and paste arbitrarily, so you had to edit in one pass and make changes from beginning to end in order. Consequently, newspaper style editing on paper as you coded intially was far more effective. After first coding, we'd run program listings and then write on those listing what edits we wanted to make, before we went and made them. Screen editors with giant buffers are much nicer!
The Packard Bell 250 was similar to the Data General machine, except it (remarkably) had a built-in loader program and came with an editor. Because it had a delay line memory (think of this as sometihing like a disk track), you place instructions along the delay line such that when the previous instrution was done, the next instruction just so happened to be coming under the "heads". Talk about painful to optimize... It had one great property; when you got frustrated, you could just whack the CPU and the mechanical shock would make the machine forget everything. Very satisyfing for a moment. Then you had to start over.
The oldest computer I've programmed is the (not very ancient) PDP-8. To get it to a point where you can start loading from paper tape, punched cards or a disk, you need to enter some bootstrap code from the front panel. You start by setting an address where you want to load code, then you can enter each word via the switches on the front, finishing each word by flipping the (spring-loaded) LOAD switch (this will then increment the word pointer, so you can simply enter the next word).
Once you've loaded your bootstrap, you then load the start address into the address register and flip the RUN switch.
将字节值作为 DATA 语句输入到 BASIC 程序中，使用一个短循环依次读取每个字节值并将其插入保存该字节值的内存中REM 语句的“文本”。
跳转到机器码的入口点地址。
之后我升级到 BBC micro，它的 BBC Basic 中直接内置了一个很棒的 6502 汇编器，因此不再需要如此极端的长度来直接输入机器代码。
啊，过去的美好时光...:-)
Just to divert slightly from the mainframe approach...
My first experience of low-level was on the Sinclair ZX-81. This had a variant of BASIC built in, but you could program "easily" in Z-80 machine code by this means:
Add a REM (comment) statement to a BASIC program. Fill this with characters in order to "reserve" some memory for your code.
Look up the machinecode opcodes in a list, and hand-assemble the machine code as byte values
Enter the byte values into the BASIC program as DATA statements, with a short loop that reads each byte value in turn and POKEs it into the memory holding the "text" of the REM statement.
Jump to the entry-point address of the machine code.
After that I moved up to the BBC micro, which had an awesome 6502 Assembler built directly into its BBC Basic, so it was no longer necessary to go to such extreme lengths to enter the machine code directly.
Early 80s, I was a kid and my family was fortunate enough to own a personal computer-- An "Apple II". Like many programmers, I got started as a kid because I wanted to create my own games. There was a BASIC language interpreter built in called Applesoft BASIC, but it was too slow to do any reasonable animation. The commercial games, at least I was told, were all written in assembly language. So there began the quest... to learn assembly language... which first meant learning MACHINE language... (the direct entry of hexidecimal numbers rather than three letter text codes representing microprocessor instructions).
The Apple II used the 6502 microprocessor. The first thing you had to learn was the memory map, which was the range and purpose of each section of memory (RAM and ROM). Here is a link to the memory map of the Apple ][e: link text
The black numbers on the left margin are the memory locations. Note it goes from $0000 to $FFFF. The 6502 could only address 16^4 = 65536 or 64k of memory. You can see the RAM ended at $BFFF. The $C000-$CFFF range would access any peripheral cards you placed in the computer. For example the disk drive controller would go in slot #6 and would show up at $C600. I felt really cool as a kid that I could reboot the system by typing $C600G which would execute ("G" for "Go") the disk controller re-boot routine in ROM. The space from $E000 to $FFFF was originally just ROM, but the Apple ][e ("e" for "enhanced") let you switch back and forth ("bank switch") and access that extra 8k of memory.
Do you see the graphics and text areas of the memory map? That how you would display to the screen. In those days (pre-GUI) there was a "text" mode where programs in ROM would continually scan memory between $0400-$0800 (= 4*16*16 = 1024 byte locations each corresponding to a place on the screen). It would take whatever ASCII byte was stuffed there and turn it into a character on your monitor. Here is the 6502 instruction set which among other things allowed you to move bytes around: 6502 Instruction Set
And to put it into context, here is a sub-routine from ROM which adds to floating point numbers called FADD: (full floating point routine collection here)
F46E: A5 F4 FADD LDA X2
F470: C5 F8 CMP X1 COMPARE EXP1 WITH EXP2.
F472: D0 F7 BNE SWPALGN IF #,SWAP ADDENDS OR ALIGN MANTS.
F474: 20 25 F4 JSR ADD ADD ALIGNED MANTISSAS.
F477: 50 EA ADDEND BVC NORM NO OVERFLOW, NORMALIZE RESULT.
F479: 70 05 BVS RTLOG OV: SHIFT M1 RIGHT, CARRY INTO SIGN
F47B: 90 C4 ALGNSWP BCC SWAP SWAP IF CARRY CLEAR,
* ELSE SHIFT RIGHT ARITH.
F47D: A5 F9 RTAR LDA M1 SIGN OF MANT1 INTO CARRY FOR
F47F: 0A ASL RIGHT ARITH SHIFT.
F480: E6 F8 RTLOG INC X1 INCR X1 TO ADJUST FOR RIGHT SHIFT
F482: F0 75 BEQ OVFL EXP1 OUT OF RANGE.
F484: A2 FA RTLOG1 LDX #$FA INDEX FOR 6:BYTE RIGHT SHIFT.
F486: 76 FF ROR1 ROR E+3,X
F488: E8 INX NEXT BYTE OF SHIFT.
F489: D0 FB BNE ROR1 LOOP UNTIL DONE.
F48B: 60 RTS RETURN.
Looking at the routine, the first four hex numbers before the colon are the memory address. So if you wanted to run the FADD routine directly, you'd type F46EG (again, the "G" for "go).
The next two hex numbers, $A5 and $F4, are the instruction codes. If you look at the handy instruction set chart, you see that $A5 means "LDA" or load the accumulator. The accumulator was one of the three memory locations (each one byte) on the 6502 processor for you to do computations with (that was nice of them, eh?). The $A5 version of the LDA command meant that the memory location to load was from the so called "zero page" or first $FF bytes of RAM which were mostly reserved for system use (there were a few bytes free for programmer use. Again, that was so nice of them.) The $F4 is the memory location whose contents (one byte) will be transferred to the accumulator. The next line has the instruction $C5 or "CMP" command, again the zero page version, which then compares the contents of the accumulator with memory location $F8. So that's the lowest level known as "MACHINE LANGUAGE" and yes, we'd sometimes type in little programs or mess with memory for debugging purposes.
The next few columns are more readable; you see the actual "LDA" and "CMP" commands and variables X1 and X2 which represent those memory locations. You also see Woz's comments on what the code is doing (comparing the exponents of two floats). This is known as "Assembly Language" and is what was actually typed in. After you typed it in your assembler would compile the byte codes.
Well, I never did manage to create a reasonable game on the Apple ][ but I sure did learn a lot about programming trying!
We still have similar devices (8085 kits, for example) in microprocessor labs in universities - they usually have a hex keypad that you use to enter the machine code into some specified location in RAM, and then you press another key to start execution. Pretty much every computer since the 1950s has had separate RAM, so no, the instructions never go directly into the CPU.
我编程的第一台计算机是 IBM 1620。如前所述，我使用了打孔卡。类似的机器是 IBM 1401。您可以阅读有关 1620 的“引导程序”例程和“引导”1401 的信息。引导程序或引导就像 PC BIOS，因为它们是机器执行以获取其他代码执行的第一个代码。这些机器的引导程序通常会从一张或多张穿孔卡中读取机器代码。启动后可以使用编译器或汇编器。我在高中时使用 1620 学习了我的第一种编程语言 Fortan。
The first computer I programmed was an IBM 1620. I used punched cards, as mentioned previously. A similar machine is the IBM 1401. You can read about the "bootstrap" routine for the 1620 and about "Booting" the 1401. A bootstrap, or booting, is like a PC BIOS in that they are the first code the machine executes to get other code to execute. The bootstap for those machines would normally read machine code from a punched card or punched cards. After booting a compiler or assembler could be used. I was in High School and lerned my first programming language, Fortan, using the 1620.
发布评论
评论（9）
http://en.wikipedia.org/wiki/Front_panel
http://en.wikipedia.org/wiki/Front_panel
（将OP中的大量后续问题的简短评论转换为长答案：）
我在1969年通过Data General Novas（16位机器）上的开关进入了引导加载程序。对于我在1967年玩过的Packard Bell 250，有是一个配备了纸带阅读器的 Flexowriter，用于将程序加载到延迟线存储器中。
对于 Nova，有一排 16 个拨动开关，还有六个其他开关，其功能是“设置内存地址”、“存入字和高级内存地址”、“单步”（我们在早期调试时经常使用它） ！），“运行”和“停止”，IIRC。
Nova 最初有 4096 个字的 16 位内存，世界上最丑陋的 RISC 指令集，有 4 个 16 位寄存器（堆栈？谁需要臭堆栈？），以及大约 1 微秒的内存周期时间（指令需要几个周期）。这台机器有一个“串行端口”，连接到 ASR33 电传打字机（每秒 10 个字符），我们花钱购买了高速纸带阅读器和打孔机。
它最初是作为裸硬件出现的，带有一个纸带，其中包含一个两遍汇编器，可以从纸带阅读器读取源代码。我们最初使用 ASR33 电传打字机直接将汇编代码源写入打孔纸带上；这包括“擦掉”拳头以消除错误的字符。编辑是非常痛苦的。一群人首先写了一个糟糕的编辑器，它将纸带读入计算机的缓冲区，让我们查找行、删除行和插入行。
我的第一份工作是对此实现一个 Kemeny&Kurtz 风格的 BASIC 解释器。两年后，我们又添加了 4K 字和 100K 字每磁道磁头磁盘，我在其上构建了一个多用户分时系统，两者都是用那个丑陋的编辑器编写的。啊。在接下来的 20 年里，我在各种机器上构建了操作系统。
Linkers/Loaders 书籍讨论了“链接器”，它组合了多个目标文件。我们的汇编程序没有打扰；它为您的汇编代码生成了可直接加载的二进制纸带。该磁带被设计为由一个小程序加载，该程序被输入，好吧，回到本次讨论的开头，一个从前面板输入的 30 多个字的引导程序。每个程序运行后（通常以“崩溃”结束），我们通常必须重新进入该引导加载程序；我们非常擅长，因为我们经常一天做几次。
关于编码形式：人们确实在这种形式上编写代码，然后其他人经常将它们“打”到纸带上。该表格的目的是确保打孔的人将内容放在您所说的位置，并使您作为编码人员更加小心编码内容的笔法（我仍然非常整齐地打印大写大写字母）。没过多久我们就意识到可以进行自由形式的编码，之后我在方格纸上用微弱的线条进行了大部分编码，因此在将其输入编辑器之前看起来很整洁。
您无法使用文本编辑器有效地进行在线黑客攻击；它没有足够的文本供您任意剪切和粘贴，因此您必须一次性编辑并按顺序从头到尾进行更改。因此，最初编码时在纸上进行报纸风格的编辑要有效得多。第一次编码后，我们将运行程序列表，然后在这些列表上写下我们想要进行的编辑，然后再进行编辑。具有巨大缓冲区的屏幕编辑器要好得多！
Packard Bell 250 与 Data General 机器类似，但（值得注意的是）它有一个内置加载程序并配有一个编辑器。因为它有一个延迟线存储器（将其视为类似于磁盘磁道的东西），所以您可以沿着延迟线放置指令，这样当上一条指令完成时，下一条指令恰好出现在“头”下方。谈论优化的痛苦……它有一个伟大的特性；当你感到沮丧时，你可以敲击CPU，机械冲击会让机器忘记一切。一时间非常满足。然后你必须重新开始。
啊，与“你们过去的日子”联系在一起。
(Converting a short remark with lots of follow on questions from OP into a long answer:)
I entered bootstrap loaders through switches on Data General Novas (16 bit machines) in 1969. For an Packard Bell 250 that I toyed with in 1967, there was a Flexowriter equipped with a paper tape reader, to load the program in the delay line memory.
For the Nova, there was one row of 16 toggle switches, and a half dozen other switches whose functions were "Set Memory Address", "Deposit Word and advance memory address", "Single Step" (we used that a lot for early debugging!), "Run" and "Halt", IIRC.
The Nova initially had 4096 words of 16 bit memory, the worlds ugliest RISC instruction set with 4 16 bit registers (stack? who needs a stinking stack?), and something like a 1 microsecond memory cycle time (instructions took several cycles). The machine had a "serial port" that connected to an ASR33 Teletype (10 characters per second), and we splurged for a high-speed paper tape reader and punch.
It initially came as bare hardware, with a paper tape containing a two-pass assembler that read source from, well, the paper tape reader. We initially wrote assembly code source onto punched paper tape directly with the ASR33 Teletype; this including "rubout" punches to wipe out characters that were wrong. Editing was incredibly painful. A cohort wrote a bad editor as the very first thing, that read a paper tape into a buffer in the computer, let us find lines, delete lines, and insert lines
My first job was to implement a Kemeny&Kurtz style BASIC interpreter on this. Two years later we added 4K more words and 100K word head-per-track disk, and I built a multiuser timesharing system on it, both written with that ugly editor. Ugh. I built OSes on various machines for the next 20 years.
The Linkers/Loaders books talks about "linkers", that combine multiple object files. Our assembler didn't bother; it produced, for your assembly code, a directly loadable binary paper tape. That tape was designed to be loaded by a tiny program that was entered, well, back to the opening of this discussion, a 30-odd word bootstrap program entered from the front panel. After each program run (usually ending in "crash") we usually had to re-enter that boot loader; we got pretty good at since we often did it several times a day.
Regarding coding forms: people did write code on such forms, and then somebody else often "punched" them onto paper tape. The purpose of the form was to make sure the person doing the punching put stuff where you said, and made you the coder rather more careful about pensmanship in what you coded (I still print block capitals pretty neatly). It didn't take us long to realize that you could code free-form, and after that I did most of my coding on graph paper with faint lines so it looked sort of neat before typing it into the editor.
You couldn't effectively hack online with the text editor; it didn't hold enough text for you to cut and paste arbitrarily, so you had to edit in one pass and make changes from beginning to end in order. Consequently, newspaper style editing on paper as you coded intially was far more effective. After first coding, we'd run program listings and then write on those listing what edits we wanted to make, before we went and made them. Screen editors with giant buffers are much nicer!
The Packard Bell 250 was similar to the Data General machine, except it (remarkably) had a built-in loader program and came with an editor. Because it had a delay line memory (think of this as sometihing like a disk track), you place instructions along the delay line such that when the previous instrution was done, the next instruction just so happened to be coming under the "heads". Talk about painful to optimize... It had one great property; when you got frustrated, you could just whack the CPU and the mechanical shock would make the machine forget everything. Very satisyfing for a moment. Then you had to start over.
Ah, to be associated with "ye olden days".
我编程过的最古老的计算机是（不是很古老的）PDP-8。要使其能够开始从纸带、打孔卡或磁盘加载，您需要从前面板输入一些引导代码。首先设置要加载代码的地址，然后可以通过前面的开关输入每个单词，通过翻转（弹簧加载的）LOAD 开关来完成每个单词（这将增加单词指针，因此您可以只需输入下一个单词即可）。
加载引导程序后，将起始地址加载到地址寄存器中并翻转“运行”开关。
The oldest computer I've programmed is the (not very ancient) PDP-8. To get it to a point where you can start loading from paper tape, punched cards or a disk, you need to enter some bootstrap code from the front panel. You start by setting an address where you want to load code, then you can enter each word via the switches on the front, finishing each word by flipping the (spring-loaded) LOAD switch (this will then increment the word pointer, so you can simply enter the next word).
Once you've loaded your bootstrap, you then load the start address into the address register and flip the RUN switch.
只是为了稍微偏离大型机方法......
我第一次体验低级是在 Sinclair ZX-81 上。它内置了 BASIC 的变体，但您可以通过以下方式在 Z-80 机器代码中“轻松”编程：
之后我升级到 BBC micro，它的 BBC Basic 中直接内置了一个很棒的 6502 汇编器，因此不再需要如此极端的长度来直接输入机器代码。
啊，过去的美好时光...:-)
Just to divert slightly from the mainframe approach...
My first experience of low-level was on the Sinclair ZX-81. This had a variant of BASIC built in, but you could program "easily" in Z-80 machine code by this means:
After that I moved up to the BBC micro, which had an awesome 6502 Assembler built directly into its BBC Basic, so it was no longer necessary to go to such extreme lengths to enter the machine code directly.
Ah, the good old days... :-)
八十年代初期，我还是个孩子，我的家人有幸拥有一台个人电脑——“Apple II”。和许多程序员一样，我从小就开始开发游戏，因为我想创建自己的游戏。有一个内置的 BASIC 语言解释器，称为 Applesoft BASIC，但它太慢，无法制作任何合理的动画。至少我被告知，商业游戏都是用汇编语言编写的。因此，开始了探索……学习汇编语言……这首先意味着学习机器语言……（直接输入十六进制数字，而不是代表微处理器指令的三个字母文本代码）。
Apple II 使用 6502 微处理器。您必须学习的第一件事是内存映射，它是内存每个部分（RAM 和 ROM）的范围和用途。这是苹果内存映射的链接][e: 链接文本
黑色数字左边距是内存位置。请注意，它从 $0000 到 $FFFF。 6502 只能寻址 16^4 = 65536 或 64k 内存。您可以看到 RAM 以 $BFFF 结束。 $C000-$CFFF 范围可以访问您放置在计算机中的任何外围卡。例如，磁盘驱动器控制器将插入插槽 #6，并显示为 $C600。当我还是个孩子的时候，我感觉真的很酷，我可以通过输入 $C600G 来重新启动系统，这将执行（“G”代表“Go”）ROM 中的磁盘控制器重新启动例程。从 $E000 到 $FFFF 的空间最初只是 ROM，但 Apple ][e（“e”表示“增强”）允许您来回切换（“组切换”）并访问额外的 8k 内存。
您看到内存映射的图形和文本区域了吗？这就是您在屏幕上显示的方式。在那些日子里（GUI 出现之前）有一种“文本”模式，ROM 中的程序会不断扫描 $0400-$0800 之间的内存（= 4*16*16 = 1024 字节位置，每个位置对应于屏幕上的一个位置）。它会获取填充在那里的任何 ASCII 字节并将其转换为显示器上的字符。以下是 6502 指令集，它允许您四处移动字节： 6502 指令集
为了将其放在上下文中，这里有一个来自 ROM 的子例程，它添加到称为 FADD 的浮点数：（完整的浮点例程集合 这里)
看一下例程，冒号前面的前四个十六进制数字是内存地址。因此，如果您想直接运行 FADD 例程，您可以输入 F46EG（同样，“G”代表“go”）。
接下来的两个十六进制数字 $A5 和 $F4 是指令如果您查看方便的指令集图表，您会发现 $A5 表示“LDA”或加载累加器。累加器是 6502 处理器上用于进行计算的三个内存位置之一（每个一个字节）。 （这很好，嗯？） LDA 命令的 $A5 版本意味着要加载的内存位置来自所谓的“零页”或 RAM 的前 $FF 字节，这些字节主要保留供系统使用（有几个字节可供程序员使用。同样，这真是太好了。）$F4 是其内容（一个字节）将被传输到累加器的内存位置。下一行有指令 $C5 或“。 CMP”命令，又是零页版本，然后将累加器的内容与内存位置 $F8 进行比较。所以这是称为“机器语言”的最低级别，是的，我们有时会输入小程序或弄乱内存用于调试目的。
接下来的几列更具可读性；您会看到实际的“LDA”和“CMP”命令以及代表这些内存位置的变量 X1 和 X2。您还可以看到 Woz 关于代码正在执行的操作的注释（比较两个浮点数的指数）。这被称为“汇编语言”，是实际输入的内容。在汇编器中输入它后，它将编译字节代码。
好吧，我从来没有设法在苹果上创建一个合理的游戏][但我确实学到了很多关于编程的尝试！
Early 80s, I was a kid and my family was fortunate enough to own a personal computer-- An "Apple II". Like many programmers, I got started as a kid because I wanted to create my own games. There was a BASIC language interpreter built in called Applesoft BASIC, but it was too slow to do any reasonable animation. The commercial games, at least I was told, were all written in assembly language. So there began the quest... to learn assembly language... which first meant learning MACHINE language... (the direct entry of hexidecimal numbers rather than three letter text codes representing microprocessor instructions).
The Apple II used the 6502 microprocessor. The first thing you had to learn was the memory map, which was the range and purpose of each section of memory (RAM and ROM). Here is a link to the memory map of the Apple ][e: link text
The black numbers on the left margin are the memory locations. Note it goes from $0000 to $FFFF. The 6502 could only address 16^4 = 65536 or 64k of memory. You can see the RAM ended at $BFFF. The $C000-$CFFF range would access any peripheral cards you placed in the computer. For example the disk drive controller would go in slot #6 and would show up at $C600. I felt really cool as a kid that I could reboot the system by typing
$C600Gwhich would execute ("G" for "Go") the disk controller re-boot routine in ROM. The space from $E000 to $FFFF was originally just ROM, but the Apple ][e ("e" for "enhanced") let you switch back and forth ("bank switch") and access that extra 8k of memory.Do you see the graphics and text areas of the memory map? That how you would display to the screen. In those days (pre-GUI) there was a "text" mode where programs in ROM would continually scan memory between $0400-$0800 (= 4*16*16 = 1024 byte locations each corresponding to a place on the screen). It would take whatever ASCII byte was stuffed there and turn it into a character on your monitor. Here is the 6502 instruction set which among other things allowed you to move bytes around: 6502 Instruction Set
And to put it into context, here is a sub-routine from ROM which adds to floating point numbers called FADD: (full floating point routine collection here)
Looking at the routine, the first four hex numbers before the colon are the memory address. So if you wanted to run the FADD routine directly, you'd type
F46EG(again, the "G" for "go).The next two hex numbers, $A5 and $F4, are the instruction codes. If you look at the handy instruction set chart, you see that $A5 means "LDA" or load the accumulator. The accumulator was one of the three memory locations (each one byte) on the 6502 processor for you to do computations with (that was nice of them, eh?). The $A5 version of the LDA command meant that the memory location to load was from the so called "zero page" or first $FF bytes of RAM which were mostly reserved for system use (there were a few bytes free for programmer use. Again, that was so nice of them.) The $F4 is the memory location whose contents (one byte) will be transferred to the accumulator. The next line has the instruction $C5 or "CMP" command, again the zero page version, which then compares the contents of the accumulator with memory location $F8. So that's the lowest level known as "MACHINE LANGUAGE" and yes, we'd sometimes type in little programs or mess with memory for debugging purposes.
The next few columns are more readable; you see the actual "LDA" and "CMP" commands and variables X1 and X2 which represent those memory locations. You also see Woz's comments on what the code is doing (comparing the exponents of two floats). This is known as "Assembly Language" and is what was actually typed in. After you typed it in your assembler would compile the byte codes.
Well, I never did manage to create a reasonable game on the Apple ][ but I sure did learn a lot about programming trying!
好吧，如果你回溯得足够远，代码是通过打孔卡输入的。
http://en.wikipedia.org/wiki/Computer_programming_in_the_punch_card_era
Well if you go back far enough code was entered through punch cards.
http://en.wikipedia.org/wiki/Computer_programming_in_the_punch_card_era
从 19 世纪开始，http://en.wikipedia.org/wiki/Punched_card
from 19th century and on http://en.wikipedia.org/wiki/Punched_card
我们在大学的微处理器实验室中仍然有类似的设备（例如 8085 套件）——它们通常有一个十六进制键盘，您可以使用它将机器代码输入到 RAM 中的某个指定位置，然后按另一个键开始执行。自 20 世纪 50 年代以来，几乎每台计算机都有独立的 RAM，因此指令永远不会直接进入 CPU。
您可能需要查看这篇维基百科文章，了解这些培训套件的一些图片。
We still have similar devices (8085 kits, for example) in microprocessor labs in universities - they usually have a hex keypad that you use to enter the machine code into some specified location in RAM, and then you press another key to start execution. Pretty much every computer since the 1950s has had separate RAM, so no, the instructions never go directly into the CPU.
You may want to look at this Wikipedia article for some images of these training kits.
我编程的第一台计算机是 IBM 1620。如前所述，我使用了打孔卡。类似的机器是 IBM 1401。您可以阅读有关 1620 的“引导程序”例程和“引导”1401 的信息。引导程序或引导就像 PC BIOS，因为它们是机器执行以获取其他代码执行的第一个代码。这些机器的引导程序通常会从一张或多张穿孔卡中读取机器代码。启动后可以使用编译器或汇编器。我在高中时使用 1620 学习了我的第一种编程语言 Fortan。
The first computer I programmed was an IBM 1620. I used punched cards, as mentioned previously. A similar machine is the IBM 1401. You can read about the "bootstrap" routine for the 1620 and about "Booting" the 1401. A bootstrap, or booting, is like a PC BIOS in that they are the first code the machine executes to get other code to execute. The bootstap for those machines would normally read machine code from a punched card or punched cards. After booting a compiler or assembler could be used. I was in High School and lerned my first programming language, Fortan, using the 1620.