PDA

View Full Version : How to make eeprom boot?



skcode1
June 17th, 2006, 05:29 AM
How to make EEPROM boot Dos 6.22 etc..
Using 28F020 ?

mbbrutman
June 17th, 2006, 06:07 AM
To make DOS (or any other program) bootable, it has to 'appear' as a BIOS extension. The BIOS extension would redirect the machine to jump to the code in your EPROM if a boot floppy or bootable hard disk was not found. Some early machines with DOS built into ROM did this, and I would use one of them as a template.

It's not easy to do. You will need a technical reference manual or some sort of BIOS reference to learn how to make BIOS extensions. You will also probably need an assembler, a DOS technical reference, etc. And I don't know how relocatable the DOS boot code is - it won't be trivial.

skcode1
June 17th, 2006, 07:55 AM
Ok Please give me some Circuits and What are the tools to build One.

mbbrutman
June 17th, 2006, 08:11 AM
It's a major product. I've experimented with BIOS extensions, but not anything like putting DOS in ROM.

If you want to persue this project, go find a machine that has DOS in ROM and learn how it works. Then use that as a template.

What you are asking for would fill a small book.

Chris2005
June 17th, 2006, 08:22 AM
to possibly alleviate the problem of whether dos is relocatable or not, the code could have dos load from rom (or eprom or eeprom) into ram. Or is that the general idea anyway? It's a very interesting topic, but I don't have the brain cells to even get involved right not (I HEARD THAT TERRY --- HE SAID "NEVER HAD"!!!) LOL LOL LOL

skcode1
June 17th, 2006, 08:25 AM
But i cant find one with eeprom boot

modem7
June 17th, 2006, 04:43 PM
The following describes the search/execution of BIOS extensions by the XT's POST.
Other computers are possibly identical in this part of the POST (for compatibility reasons).

20. POST - A search of the memory area from C800:0 to EF80:0 is done (in 2K blocks) for the BIOS extension ROM's that may be located on expansion cards.
When a BIOS extension ROM is found (first two bytes are 55AA), a checksum on it is done. If the checksum is incorrect then the segment of the faulty BIOS extension ROM and the word 'ROM' is displayed (eg. C800 ROM).
If the checksum is correct then the motherboard BIOS ROM hands control to the BIOS extension ROM found on the expansion card. BIOS extension ROM does whatever tests and initialisation that it wants and then returns control to the BIOS ROM on the IBM/XT motherboard. Some BIOS extension ROM's will display messages on the screen.

NOTE:Hard disk controllers for the IBM/XT have a BIOS extension ROM which is normally at C800:0 When control is passed to the controller's BIOS extension ROM, it will issue 1700 series error messages if it finds anything wrong.


Okay. You build your own expansion card containing a ROM that is mapped in memory to start somewhere between C800:0 and EF80:0 (on a 2K boundary). Obviously you must avoid a conflict with any existing BIOS extensions. You set the first two bytes of your ROM to 55AA and you alter the value of some dummy bytes so that the POST sees a correct checksum. That's a piece of cake. The other contents of the ROM will be the fun part.

Obviously it's not as easy as just putting DOS into your BIOS extension. And whatever your BIOS extension does, you must pass execution back to the POST so that:
1. execution of any other BIOS extensions happens, and
2. the remaining POST code runs (it does stuff like enable timer and keyboard interrupts).

However, if you did want your BIOS extension to load/boot DOS, I guess your BIOS extension could do the remaining POST tasks itself, then load/boot DOS. Problem with that is that different computers will have different 'remaining POST tasks'. Throw that idea out the window.

The last thing the XT POST does is invoke the bootstrap loader (via interrupt 19). Therefore maybe your BIOS extension could contain three 'bits' of code. The first bit is what executes when the POST passes execution to your BIOS extension. It simply alters the pointer that interrupt 19 uses to point to the second bit of code in your BIOS extension. In that way the remaining POST tasks get done. The second bit of code in your BIOS extension is a modified bootstrap loader to copy DOS (the third bit in your BIOS extension) from ROM to RAM, then pass execution to DOS.

Sounds simple, but I don't think it will be. There's a lot of research required.

kb2syd
June 19th, 2006, 10:55 AM
But i cant find one with eeprom boot

Tandy 1000 HX boots from rom. Dos 2.11 I think, but it'll show yuo how it's done. They come up on ebay all the time.

Kelly

Terry Yager
June 19th, 2006, 11:11 AM
Tandy 1000 HX boots from rom. Dos 2.11 I think, but it'll show yuo how it's done. They come up on ebay all the time.

Kelly

I have one in storage that you can have for shipping cost, so you can dump the ROM and study the code. IIRC, it boots to DOS 3.3x and also has the 'DeskMate' shell in ROM. Interestingly enough, that machine also utilizes an EEPROM to store system information.

--T

Terry Yager
June 19th, 2006, 12:01 PM
Oh yeah, BTW, I also have a Zeos palmtop that boots to DOS 5.0 from ROM. I'll try using Mike's program to dump that ROM and send a copy (if it works).

--T

Terry Yager
June 19th, 2006, 12:27 PM
Well, that was painless. (Great program, Mike). Here are the DOS 5 dumps from the Zeos.

--T

Unknown_K
June 19th, 2006, 07:31 PM
How did people boot from an EPROM in a network card socket?

mbbrutman
June 19th, 2006, 08:25 PM
The EPROM in a network card socket would have to look like a BIOS extension. Which is how even modern network cards allow a network boot.

Chris2005
June 20th, 2006, 07:04 AM
you can save portions of memory with debug (as long as they're no bigger then 64k-1 or 65,535 bytes). You can save sequential portions too but it can be a little confusin sometimes yer know. You can save it to a file also. If anyone needs help...uh ask someone else LOL. Kidding, it's been a while since I played with it.

Chris2005
June 20th, 2006, 07:13 AM
I really don't understand why it has to be done as a bios extension. And forget about designing an expansion card, there's empty rom sockets on your PC mobo (and empty rom space). After all the POSTs and crap get done, the computer attempts to load something from either hard disk or floppy disk or finally ROM (BASIC - if it's true blue). Seems to me you could just fiddle with that or copy those routines and load the files into ram. I guess that's an oversimplification, but all the other stuph seems unnecessary.

"I have one in storage that you can have for shipping cost, so you can dump the ROM and study the code. IIRC, it boots to DOS 3.3x and also has the 'DeskMate' shell in ROM. Interestingly enough, that machine also utilizes an EEPROM to store system information."

Dude, if no one claims it, I'm interested.

mbbrutman
June 20th, 2006, 08:30 AM
How do you get a machine to boot DOS from RAM without putting DOS into RAM in the first place?

The job of the BIOS extension is to tell the machine to put a copy of DOS in RAM from an EPROM after the normal hard disk and floppy disk boots have failed because there was no media.

The BIOS extension is an EPROM somewhere on the machine that is in the correct address range. (0xD000:0000 - 0xF000:0000). If empty sockets on your motherboard are addressable, then fine. Another cheat is to use a network card with a boot EPROM on it as a simple card to hold your new EPROM.

Your method would alter the machine BIOS. I'd rather extend it with another EPROM.

Terry Yager
June 20th, 2006, 09:42 AM
Dude, if no one claims it, I'm interested.

Ok, if skcode1 doesn't want it, it's all yours.

--T

Chris2005
June 20th, 2006, 01:18 PM
"Your method would alter the machine BIOS. I'd rather extend it with another EPROM."

If the BASIC interpreter is done that way (as an extension) then I guess that's the way to go. So I guess what you're saying is if there's no hard disk, nothing in the floppy drive and (presumably) no ROM-BASIC to boot to, it boots into ROM-DOS.

Chris2005
June 20th, 2006, 01:22 PM
but "extensions" as I'm to understand, get executed (their code) just because they're there. It's not conditional in otherwords. And after you hand over control to DOS (once it's loaded into ram) you're not handing control back to the system BIOS, or at least there would be no reason to.

modem7
June 20th, 2006, 04:56 PM
I really don't understand why it has to be done as a bios extension.
It doesn't. You can of course replace your existing BIOS ROM's with altered ones (providing there's enough space for DOS, or you can put DOS in a unused ROM socket [either on the motherboard or a card]). You end up with a machine-specific solution.

A 'pure' BIOS extension solution (if done correctly) is a multi-machine solution.

modem7
June 20th, 2006, 04:59 PM
If the BASIC interpreter is done that way (as an extension) then I guess that's the way to go.
It isn't done as an extension. For example, in the source for an XT BIOS, one of the last things that is done is to invoke the boot strap loader via an INT 19h. The code executed by INT 19 attempts to load sector 1, track 0, head 0 from floppy 0. If that fails, the 'resident' BASIC is invoked via INT 18h

Note that the BIOS doesn't attempt to boot from the hard drive. Why? The XT BIOS knows not of hard drives (nothing whatsoever). All hard drive support is provided by the BIOS extension on the XT's HDD controller. So that the hard drive is looked for as a possible boot device in an XT, I'm guessing that one of the things that the initialisaion code in the controller's BIOS extention does is to alter the INT 19 vector. Thus the boot strap loader in the controller is what gets executed. That boot strap loader attempts to boot from the floppy. If that fails an attempt is made to boot from the hard drive. If that fails (and a resident BASIC is present) the controller then jumps to BASIC.

mbbrutman
June 20th, 2006, 06:43 PM
Contrast that to the AT BIOS, which has hard disk support built in.

Terry Yager
June 20th, 2006, 07:51 PM
This is all very confusing to me. I have several computers that boot DOS from ROM, or in some cases, FlashRAM. All of them 'see' the ROM as if it were a disk drive, not as memory. The solid-state drive(s) are assigned drive letters, just like any other disk drive. How does that work? I mean, I can see writing the boot-loader to look at the ROMdisk to load DOS from, but how do you convince it that the mem chip is actually a drive? How much modification to the BIOS does that require?

--T

mbbrutman
June 20th, 2006, 08:07 PM
The boot sequence for a machine is generally floppy, hard disk, and then either an error message or Cassette BASIC if the machine is true Blue.

Clones don't have Cassette BASIC, so most of them just spit out an error message saying 'Boot Failure' or 'No Operating System'. For a machine with something built in (like DOS), jumping to that built-in thing at that time would be logical.

Even doing something simple, like just getting the lower levels of DOS and COMMAND.COM would be helpful. You'd let the machine boot from DOS in ROM, then pop in a diskette and go. If you needed a different DOS, you'd just pop that in first and let the machine boot like it normally would. In the case of a hard disk you could get to DOS if the hard disk didn't have the system files or otherwise failed.

If a machine is simulating a floppy, then it must have really big EPROM around somewhere with the contents of that virtual floppy. (I doubt it would be a full sized floppy being emulated .. 64 or 128K makes more sense.) The BIOS knows that it booted using either a real floppy or a virtual one. If it used a virtual one, then it doesn't talk to the diskette controller for reading blocks of data .. it talks to the 'other' device. Bootable CDROMs and bootable USB devices work this way ... the BIOS has a higher level interface to say 'give me a block of 512 bytes' for these devices, instead of setting up a floppy diskette access.

A BIOS extension woould work fine for this too. Look at the PCjr as an example. A game on a cartridge that wants to hijack the boot process to put you in the game looks like a BIOS extension that never returns control back to the boot process. A more enlightened version hooks INT19 and then returns control back to BIOS. When that is done, if there is a floppy in the machine it will boot. If not, the machine executes INT 19 to go to Cassette BASIC. But if you hooked Cassette BASIC with your own code, then it would go there instead.

I suspect that the clones that booted into DOS when no floppy was present did exactly that.

Terry Yager
June 20th, 2006, 08:41 PM
The little Zeos assigns drive letters A: & B: to the two PCMCIA slots, and if an SRAM card is present in the slot, it becomes a read/write drive of whatever capacity the card (2Mb currently). The ROMdisk that it boots from is assigned C:, and it contains the system (including command.com and the config & autoexec files) and some of the built-in software. It also assigns two other letters to solid-state devices, D:, which is also read-only and contains more of the built-in software, and E:, which is read/write, but the really weird part is that it has non-volitile characteristics as well, since some more of the built-in software is also installed (at this point, the lil' wisps of smoke begin wafting from my earz). I'm thinking that perhaps the E: drive is either a FlashDisk or mebbe an EEPROM.
Oh yeah, the config.sys loads two different disk-related files, ROMDRIVE.SYS and VDISK.SYS, but I don't believe E: is strictly a RAMDisk, even though vdisk is loading (by now, the smoke is billowing out full-force).

--T

Micom 2000
June 20th, 2006, 11:44 PM
I imagine the handhelds like the Zeus had a much different process. I just acquired an Atari Portfolio.
It boots to a PC card first or in it's absence to a ram partition that contains DOS.

I also have a Sharp PC3K which contains DOS System in ROM which it calls C: as well as a nonvolatile D: and a volatile E: whose contents are lost when powered down. It also uses PC cards for drives A: and B:.

Both were made by Distributed Information Processing(DIP), a UK company. The PC3K was to be the second generation Portfolio but when Tramiel turned it down was quickly snapped up by Sharp.

I don't think you can compare the remarkable handheld technology (1989-1991) to the much more primative era of the PC/XT/PCjr/AT. Even the Atari ST/Amiga/Mac which had built-in OS in ROM were much different beasts. Only when I am smoking can I get to first base with following the processes of these machines. User friendly? BS !!
The whole development of OS' has to estrange us ordinary mortals even further from the processes of in/out, fi/fo , and interrupts. Point and click, and revere, nay, worship the magic witchcraft of modern technology.

Lawrence

Terry Yager
June 21st, 2006, 06:49 AM
I've read on a webpage or two that my Zeos PPC is either a rebadge or a clone of your Sharp PC 3000, but so far, I haven't been able to confirm this.
I did some further experimentation in the wee hours, and I'm now convinced that the E: drive is a RAMdisk, and that the files are copied to it (from somewhere) after a hard reset. I confirmed this by copying the files to another drive, then deleting them. A three-handed salute didn't bring 'em back, but a full-system reset did. The files are then non-volitile, thanx to the backup battery, so they survive even a hard reset (I think). I'm a little less confused now, but I still smell a little smoke...

--T

Chris2005
June 21st, 2006, 06:50 AM
Terry: I would have to say if you construct a proper set of drivers for a device, you can make it look like anything. As an aside, there used to be (I could swear) a program that became a virtual disk drive, in a different sense then what you're talking about though (but then again maybe the same thing). It looked, to the os, like a floppy drive, and you could unpack images to it, and have a structure that again appeared to the os like it was looking at the file structure of a floppy disk.

>Look at the PCjr as an example. A game on a cartridge that wants to hijack >the boot process to put you in the game looks like a BIOS extension that >never returns control back to the boot process.

Are those games handled as bios extensions? This occurred to me not that long ago (duy doi). When you plug a cartridge into a Peanut or anything else for that matter, you're gaining access to the same buses that a built in rom chip has. It really makes no difference whether you plug in a cartridge or plug in an ancillary rom chip (provided you have empty sockets, which the PC and XT have). Seems that way anyway. I don't know by which mechanism roms get "added" onto the system though.

>I don't think you can compare the remarkable handheld technology (1989->1991) to the much more primative era of the PC/XT/PCjr/AT. Even the Atari >ST/Amiga/Mac which had built-in OS in ROM were much different beasts.

Despite the advances in technology, the principles are largely the same, even today. Imagine booting off a parallel port (no big feat these days while I think USB boot is somewhat common). You need to write the code that'll peer at the data present on the parallel port lines, perform some sort of acknowledgement, have it present another set of data, etc. Did a PC in that era or even long after have this feature? I may not be the right person to ask, but not to my knowledge.

mbbrutman
June 21st, 2006, 06:59 AM
PCjr cartridges are BIOS extensions. They are mapped into memory between C000:0000 and D000:FFFF, or they can override the system ROM (F000:0000 to F000:0000) entirely. And if you are clever, you don't even need to use a straight EPROM in a cartridge. Some of the cartridge 'patched' the system ROM in real-time by grabbing the bus and responding to certain memory requests, while letting others go to the normal system ROM.

(This allowed these cartridges to alter ROM without infringing on the copyright by copying the ROM to the cartridge.)

They follow the same rules for BIOS extensions too ... they have the 55AA signature in them.

I've thought about booting from a parallel port device, and it certainly could be done with a ROM BIOS extension. The parallel port in its simplest form is just 3 I/O ports. Parallel port devices are not bootable because nobody had a convienent place to put the extra required ROM chip needed for each particular parallel port device.

There was a hard disk adapter for the PCjr that sat in the modem slot that had this particular problem. The modem slot at I/O ports, but not a place for a ROM BIOS extension. So you could put the controller in the modem slot, but you had to boot from floppies to get the device driver into memory before you could use the hard disk. The solution was elegant .. put the ROM BIOS extension on a cartridge! (And that came later ..)

Chris2005
June 21st, 2006, 07:02 AM
"PCjr cartridges are BIOS extensions. They are mapped into memory between C000:0000 and D000:FFFF, or they can override the system ROM (F000:0000 to F000:0000) entirely."

How is that done (the overriding part)?

Chris2005
June 21st, 2006, 07:08 AM
>>If the BASIC interpreter is done that way (as an extension) then I guess >>that's the way to go.

>It isn't done as an extension. For example, in the source for an XT BIOS, >one of the last things that is done is to invoke the boot strap loader via an >INT 19h. The code executed by INT 19 attempts to load sector 1, track 0, >head 0 from floppy 0. If that fails, the 'resident' BASIC is invoked via INT 18h

So therefore might not this be the "easiest" way to add rom-dos to a system? Replace the BASIC roms (on a reel peecee) with a chip/s that had the system files (plus some amended form of the boot record). Possibly w/o even having to modify the bios roms.
And remember, you can plug reel peecee roms into a clone (provided it's a true one). I guess the situation gets more difficult once you start getting into the funkier clones.

Terry Yager
June 21st, 2006, 08:06 AM
Terry: I would have to say if you construct a proper set of drivers for a device, you can make it look like anything.

Yes, but where do you put those drivers? Do they have to be included in the BIOS ROM, or are they called as extensions like any other ROM?

--T

Terry Yager
June 21st, 2006, 08:09 AM
"PCjr cartridges are BIOS extensions. They are mapped into memory between C000:0000 and D000:FFFF, or they can override the system ROM (F000:0000 to F000:0000) entirely."

How is that done (the overriding part)?

Yes, I think that's my question too. Is it just a simple bank-switching scheme?

--T

mbbrutman
June 21st, 2006, 08:26 AM
They were ingenious .. some sort of TTL logic (hidden in a PAL device) that scans the bus for the address it wants. If a non-interesting address is on the bus, the cartridge does nothing. If the CPU presents an interesting address, the PAL on the cartridge raises the line that indicates that it is replacing the system ROM, responds to the bus request, and then lowers the line.

I reverse engineered the behavior based on the technical description of the cartridge interface. I need a logic analyzer to prove it. The only thing that seems wrong is that the PAL on the cartridge would have to raise and lower the line that says 'I'm the System ROM' pretty darn quickly to get the timing correct.

Terry Yager
June 21st, 2006, 09:53 AM
OK, so DOS allows for user-defined 'block devices', but IIRC, such a device shows up as a drive letter. I don't know if the DOS-in-ROM chip could be defined in this way or not, since it's a DOS function (Catch-22?).
I'm also reminded of some of the ol' backup tape-drives which were hung off from the floppy controller, but didn't show up as a letter, they could only be seen by the backup software.
So how does all this come together? (Am I even making any sense? I'm kinda over my head here.).

--T

mbbrutman
June 21st, 2006, 10:36 AM
The resident portion of DOS would have to be in memory, somewhere, just as though it was booted. The virtual drive would require a device driver to access .. at a minimum it would look like a RAM disk device driver. A more sophisticated one would bank switch the pieces of the virtual drive in as it needed it to avoid sucking up a huge amount of address space.

kb2syd
June 21st, 2006, 11:20 AM
"I have one in storage that you can have for shipping cost, so you can dump the ROM and study the code. IIRC, it boots to DOS 3.3x and also has the 'DeskMate' shell in ROM. Interestingly enough, that machine also utilizes an EEPROM to store system information."

Dude, if no one claims it, I'm interested.
Chris:
I have a "spare" HX if the other one doesn't come through for you. It is a basic unit, and it may or may not have a floppy drive.

Chris2005
June 21st, 2006, 04:41 PM
>Yes, but where do you put those drivers? Do they have to be included in >the BIOS ROM, or are they called as extensions like any other ROM?

If yer talking about the drive thingees on yer palmtopper thingees, dunno. A driver (the code) resides between some of the system files (can't remember which order they get loaded, prolly io.sys, msdos.sys then duh command.com). There have been a WHOLE LOT of bios' since the early days, and untold things were added, depending on what machine we're talking about. There's nothing saying something has to use the standard device driver mechanism introduced with DOS 2.0. Code is code in the final analysis. Mechanisms have been added so you can stitch things on in a standard setting (i.e. 100% compatible), but if you got some interesting code, you can stick it wherever ya want ;)

>The only thing that seems wrong is that the PAL on the cartridge would >have to raise and lower the line that says 'I'm the System ROM' pretty darn >quickly to get the timing correct.

That's way freaky. The Peanut in reality had some interesting stuph going on under the hood. And remember the Jr used a Video Gate Array to make the video appear as if it was in the upper half of the B block (and thereby retaining CGA compatibility), when in reality it could be anywhere, and in fact was low down in memory. The Tandy 1000 may have been similar. So I guess it's not that big a deal to be able to *virtually* switch things in and out of portions of memory (the initialization code (POST, etc.) HAS to start at F000:FFFF (or FFFF:0000) - an 80x86 operating in real mode is wired internally to start loading code starting with that location as soon as power is applied. And don't ask me to translate those addresses into 32-bit. nuh uh).

>So how does all this come together? (Am I even making any sense? I'm >kinda over my head here.).

>The resident portion of DOS would have to be in memory, somewhere, just >as though it was booted. The virtual drive would require a device driver to >access .. at a minimum it would look like a RAM disk device driver. A more >sophisticated one would bank switch the pieces of the virtual drive in as it >needed it to avoid sucking up a huge amount of address space.

The expanded/extened memory scheme things also come to mind.

Chris2005
June 21st, 2006, 04:43 PM
"Chris:
I have a "spare" HX if the other one doesn't come through for you. It is a basic unit, and it may or may not have a floppy drive."

So put one in! And read my lips - T*A*N*D*Y*6*0*0*0 - that's what you need to be concerned with pal.
And by the way - we might be neighbors soon. Don't that make you feel good ;)

kb2syd
June 23rd, 2006, 04:42 AM
"Chris:
I have a "spare" HX if the other one doesn't come through for you. It is a basic unit, and it may or may not have a floppy drive."
So put one in!

Yeah, and I probably have a spare one for it. Paid more for the drive (it is a special one) than I did for the HX without one.


And read my lips - T*A*N*D*Y*6*0*0*0 - that's what you need to be concerned with pal.
This weekend is field day. After that I should have some time to finish the 6000 for you.


And by the way - we might be neighbors soon. Don't that make you feel good ;)
Screams, faints...

modem7
June 24th, 2006, 02:09 AM
I'm also reminded of some of the ol' backup tape-drives which were hung off from the floppy controller, but didn't show up as a letter, they could only be seen by the backup software.
--T
My understanding is that the use of a floppy controller was simply a convenient way of getting commands/data to/from the tape drive.
Obviously a tape drive that mimicked a floppy drive (and thus appeared as a drive letter) would be way too slow.

Chris2005
June 24th, 2006, 07:10 AM
I have one of those old drives, by Colorado or something. It's plugged into my ATjr (actually an AMTjr after IBM made them change the name). Good luck finding working tapes for it though I guess.