• Please review our updated Terms and Rules here

How to make eeprom boot?

Chris2005 said:
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.
 
Contrast that to the AT BIOS, which has hard disk support built in.
 
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
 
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.
 
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
 
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
 
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
 
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.
 
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 ..)
 
"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)?
 
>>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: 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
 
Chris2005 said:
"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
 
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.
 
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
 
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.
 
Chris2005 said:
"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.
 
>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.
 
"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 ;)
 
Chris2005 said:
"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.
Chris2005 said:
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.
Chris2005 said:
And by the way - we might be neighbors soon. Don't that make you feel good ;)
Screams, faints...
 
Back
Top