![]() |
中国DOS联盟-- 联合DOS 推动DOS 发展DOS --联盟域名:www.cn-dos.net 论坛域名:www.cn-dos.net/forum |
| 游客 | 登录 | 注册 | 会员 | 搜索 | 中国DOS联盟 |
|
中国DOS联盟论坛 现在时间是 2026-08-10 15:59 |
共 47,811 主题排行 / 349,897 发帖 / 今日 0 篇 / 48,255 会员排行 |
| DOS疑难解答 & 问题讨论 (解答室) » 问:电脑是怎么从ROM启动的... |
| 可打印版本 6,323 / 31 |
| 第16楼 aria | 发表于 2004-10-03 00:00 |
| 高级用户 发帖 243 积分 924 | |
|
想问一下:既然不能用ram那么ss段是怎么设的呢?不能用call了吗?
|
|
| 第17楼 yzz163 | 发表于 2004-10-05 00:00 |
| 中级用户 发帖 96 积分 335 | |
|
1。提供rom里面程序的相关资料和教程。------------------好象写BIOS的公司永远也不会提供的吧。2。一部分程序在ROM中运行,不能用ram---------------------------这样说,好象不妥吧?ROM是只读的,这句“一部分程序在ROM中运行”应改成“CPU将读取ROM中的代码”。
|
|
| 第18楼 aria | 发表于 2004-10-05 00:00 |
| 高级用户 发帖 243 积分 924 | |
|
1.我觉得不对.例如AMI就提供了一套sis芯片组的bios源码另外还有freebios,openbios等2.没有理解你的意思
![]() |
|
| 第19楼 yzz163 | 发表于 2004-10-06 00:00 |
| 中级用户 发帖 96 积分 335 | |
CPU马上就从地址FFFF0H处开始执行指令 关于此句我有些疑问,地址的概念似乎是针对RAM(内存)来说的,而BIOS代码指令在ROM(无论是否可擦写)中。而这个地址FFFF:0,据我所知,是ROM“映射”到RAM中的起始地址,而这个“映射”的过程肯定是在POST过程之后的,因为必须首先检测RAM的有效,才可能映射。也就是说,在POST之前地址FFFF:0应该是不存在的,那么CPU又怎么从此处开始执行呢?。 关于显卡的BIOS也存在类似的问题,而且C0000也似乎并非“显卡BIOS”,我只知道早期的PC机中曾把它用作彩色显示器的屏幕缓冲区(640*480*16),而现在的显卡已不再如此使用。 ----------------------- 以INTEL586为例,在复位信号结束后,南/北(具体要看芯片组)桥将使CPU发出读指令(第一条开机指令的第一总线周期),即CPU在自己的地址引脚上放:FFFF0。然后通过南/北、I/O芯片在BIOS的地址引脚上产生FFFF:0信号,BIOS的地址引脚A0-A7为低电平,BIOS被选中。BIOS将在自己的数据线引脚上放代码5B3AH(Award BIOS),I/O芯片、南/北将该数据传到CPU地址线上,最后由CPU读取并执行。 (通过短路ISA槽的A10 IO CHRDY和B10 GND脚可使CPU始终处于上述的“第一条读指令”状态,——其实就是读主板BIOS ROM里存放的第一条指令。这时你可测一下ISA的地址线A0-A19应全为高电平:1,即十六进制的FFFF) 这是我对CPU上电后如何读取BIOS指令的理解,也是我维修“致命故障”主板的理论依据。希望大家共同探讨。 “地址的概念似乎是针对RAM(内存)来说的”这不对吧?不管ROM、RAM对CPU来说都是一样的,即:通过地址线、数据线来访问他们的每个存储单元的。同样CPU访问其他设备也是一样的吧。当然ROM的“映射”要在后面来实现。 另外POST里好象要检查前64K内存吧? |
|
| 第20楼 yzz163 | 发表于 2004-10-06 00:00 |
| 中级用户 发帖 96 积分 335 | |
|
aria:
1、你的BIOS原码是那个型号的主板上的,是实用的吗?能E-MAIL我吗? 2、ROM会运行程序???!!! 那CPU干什么? 所有的程序代码都是由CPU来执行的,RAM、ROM、只是放程序代码或数据的“容器”。 |
|
| 第21楼 aria | 发表于 2004-10-06 00:00 |
| 高级用户 发帖 243 积分 924 | |
|
呵呵又学到了很多谢谢关于源码:那个是一本叫<<BIOS研发技术剖析>>里面的压缩后有6M多
|
|
| 第22楼 cdl | 发表于 2004-10-07 00:00 |
| 中级用户 发帖 107 积分 340 | |
以下是引用aria在2004-10-3 16:16:20的发言: 在对ram进行有效测试之前,不可以用ram。堆栈段是哪里并不重要因为不会用到,当然call是不能用的。可以使用所有的寄存器,寄存器默认是好的。 |
|
| 第23楼 cdl | 发表于 2004-10-07 00:00 |
| 中级用户 发帖 107 积分 340 | |
|
关键点:bios空间不在1M空间之内,光用20根地址线是无法访问的。正常情况下在实模式中是读不到bios的,就算你用ffff段也好。其实问题并不难,自己做个试验,把bios读出来看看不就知道了。如果能正确读出bios,fffffff0处一定是编码为EAH的转移指令。
|
|
| 第24楼 yzz163 | 发表于 2004-10-07 00:00 |
| 中级用户 发帖 96 积分 335 | |
|
关键点:bios空间不在1M空间之内,光用20根地址线是无法访问的。正常情况下在实模式中是读不到bios的,就算你用ffff段也好。其实问题并不难,自己做个试验,把bios读出来看看不就知道了。如果能正确读出bios,fffffff0处一定是编码为EAH的转移指令。--------------------------"自己做个试验,把bios读出来看看不就知道了。" 你是在计算机正常启动后用程序读的?还是在CPU通电复位后用"专用硬件"(这时计算机还没完成自检)对BIOS进行单步跟踪的?
|
|
| 第25楼 cdl | 发表于 2004-10-07 00:00 |
| 中级用户 发帖 107 积分 340 | |
以下是引用yzz163在2004-10-7 15:42:55的发言: 我是编程把整个flash全读出来了。“专用硬件”我没用过。 |
|
| 第26楼 cdl | 发表于 2004-10-07 00:00 |
| 中级用户 发帖 107 积分 340 | |
|
关于bios映射到ram:bios映射到ram不是必须的,只是在rom中运行速度太慢。为了让执行速度更快而映射的,如果应用程序不是经常调用bios的话,没必要映射到ram空间,这样可以节省ram资源。特别是用windows操作系统的用户根本就没必要映射,因为bios的基本功能都是实模式代码,保护模式无法使用,windows下的硬件驱动都是重新加载的,不会使用bios的功能。
|
|
| 第27楼 yzz163 | 发表于 2004-10-12 00:00 |
| 中级用户 发帖 96 积分 335 | |
|
我是编程把整个flash全读出来了。------------------你是在计算机启动后在用程序读BIOS的吧?这时BIOS应该是被映射到内存里了把,不同的操作系统可能被映射的地址不同吧?但现在我们讨论的是在CPU复位后的第一条指令:即如何读取BIOS的.
|
|
| 第28楼 yzz163 | 发表于 2004-10-12 00:00 |
| 中级用户 发帖 96 积分 335 | |
|
bios空间不在1M空间之内,光用20根地址线是无法访问的。-----------------------------对于X86系列的CPU,在复位后,就工作在X086模式即"实模式",这时它只能用20根地址线.当然对于其他类型的CPU可能不同.
|
|
| 第29楼 cdl | 发表于 2004-10-12 00:00 |
| 中级用户 发帖 107 积分 340 | |
|
在286之前地址空间是20位的,只需要16位的段寄存器和16位的IP就够了,而286的地址空间是24位的,386的地址空间是32位的,地址产生方式与286之前的CPU有很大的区别。在386以后的计算机中,BIOS是放在最高地址空间的64K处,第一条指令是在FFFFFFF0处,CPU复位后第一条指令并不是由CS左移4位+IP计算地址的,虽然复位之后cs=FFFFH,但是CPU产生的第一条指令的地址和它毫无关系。基址是由另外一个寄存器(该寄存器无法直接访问)产生,CPU复位后该寄存器的值是确定的并保证由该基址和EIP=0000FFF0H,寻址到FFFFFFF0H处,第一条指令是长跳转指令,执行第一条指令后cs重新装入,同时基址寄存器也重新装入。
|
|
| 第30楼 beiyuly | 发表于 2006-10-13 20:59 |
| 初级用户 发帖 40 积分 95 | |
Originally posted by willsort at 2004-10-2 00:00: bios在进行ram shadow之前,cpu的指令是从bios om中拿到的,那个时候没有ram,也就是说机器还不知道有ram,只有在进行ram shadow之后,才会在ram中放入印象,这才从ram中的指令执行. |
|
| 上一页 1 2 3 下一页 |
|
[ 联系联盟系统管理团队 -
中国DOS联盟 -
标准版 ] Sponsored by ifanr Inc | © 2001–2023 |