There's a list... I've seen it on the Ardent Tools...and it goes something like this, with the following machines marked as being "unknown". Here's the results of personal experimentation on the ones I have. I think this came up before at some point... PS/2 Model 35SX - unknown, never tried PS/2 Model 40SX - unknown, never tried PS/2 Model L40 - yes PS/2 Model 56 - probably not PS/2 Model 57 - probably not PS/2 Model 65SX - yes PS/2 Model 76 - Lacuna: no. Bermuda: no PS/2 Model 77 - Lacuna: no. Bermuda: no PS/2 Model 85 - no (0XA, 0X0, 0XF, 0XG, 0X6 models tested) PS/2 Model 90 - no for Type 1, 2 and 4 complexes PS/2 Model 95 - no for type 3 and 4 complexes On the 9585, failure to find anything to boot from on the hard disk produces an I999* series error. Then you will most likely be dumped into system programs if you have a reference partition. Otherwise the system displays the error, prompts for a boot diskette (any DOS boot disk will work) and will stop cold if you press F1 without providing a boot disk. I'll hazard a guess that the 56 and 57 models behave the same way as the 9585 once they have completed IML. At least I can prove that the "Bermuda" systems will dump you into system programs upon a failure to boot up and after displaying an I999* error code. On the systems that won't go into ROM BASIC after a boot failure, I have not been able to determine if the BASIC code is still present in ROM. I guess it could be there for compatability reasons. William Hi William, > ...On the systems that won't go into ROM BASIC after a boot failure, > I have not been able to determine if the BASIC code is still present > in ROM. I guess it could be there for compatability reasons. If I would ever flesh out the call into a program that would check we could be sure: http://www.IBMMuseum.com/Interrupts/INT15h/INT15h22.html ... David David@IBMMuseum.com Hi William, > http://www.IBMMuseum.com/Interrupts/INT15h/INT15h22.html Actually I need to even add to the template: On return the AH register gives the status (like 86h is function not supported) if the Carry flag is set (for an error condition). If Carry is clear, then AX = 0 & ES:BX points to the location of ROM BASIC in the BIOS (the call identifies that it is on only "later PS/2s"). Earlier PS/2s (which may not support the call) and the PC family have ROM BASIC at F600h:0000h. David David@IBMMuseum.com Hi David, > > http://www.IBMMuseum.com/Interrupts/INT15h/INT15h22.html Interrupt 18h transfers control to ROM BASIC, if you see the BASIC screen you are there. You can run the programs from DOS or DOS Window. Here the files & progs I played some three years ago with: www.members.aon.at/mcabase/pub/files/rombasic.zip See README.TXT, note how DEBUG creates a 10 byte COM file jumping to ROM BASIC from the supplied script ROMBAS.SCR. Use as "debug < rombas.scr" to create the COM file. ROMBAS.SCR ------------ N ROMBASIC.COM A 100 INT 18h R CX A W Q UNzal Hi! It looks like (on the 9585-0X6 at least) that ROM Basic is dead or not in that location. I think what I've found is a kind of boot failure handling "stub" in its place. I ran ROMBASIC.COM from a FreeDOS 1.0 boot floppy (no device drivers) with the machine in its normal operating configuration. The screen cleared and moments later the LAN/A's built in RIPL program started running. I pulled the LAN/A and tried again. This time the machine stopped cold with a "I9990305" (no startable device found), which is where it was sitting until I hit CTRL-ALT-DEL (which I don't think is normally effective upon receiving that error code). Before I requested the warm reboot, I tried pressing F1 to see if anything would happen. The machine was completely unresponsive to that keypress. William > It looks like (on the 9585-0X6 at least) that ROM Basic is dead or not > in that location. I think what I've found is a kind of boot failure > handling "stub" in its place. There is no ROM BASIC therefore. Interrupt 18h does not have any return value, you can't check the status. Applicable to PS/2, PC, AT, so the book. > I ran ROMBASIC.COM from a FreeDOS 1.0 boot floppy (no device drivers) > with the machine in its normal operating configuration. The screen > cleared and moments later the LAN/A's built in RIPL program started > running. Seems reasonable, goes to LAN/A instead to BASIC, that is, it goes nevertheless somewhere. UNzal Hi Unal, > Interrupt 18h transfers control to ROM BASIC, if you see the BASIC > screen you are there. You can run the programs from DOS or DOS > Window. Here the files & progs I played some three years ago with: > www.members.aon.at/mcabase/pub/files/rombasic.zip > See README.TXT, note how DEBUG creates a 10 byte COM file > jumping to ROM BASIC from the supplied script ROMBAS.SCR. > Use as "debug < rombas.scr" to create the COM file. > ROMBAS.SCR > ------------ > N ROMBASIC.COM > A 100 > INT 18h > > R CX > A > W > Q Right, I had forgotten briefly about the INT 18h. Even looking to see if there is an INT 18h ISR could fail: AMI BIOSes stub it out to display "NO BOOT DEVICE AVAILABLE" & require a reboot if called. And as William may have discovered with the LAN/A: "Other Uses of INT 18h Some network cards contain boot ROMs so that a system attached to a network can boot without using a hard disk or floppy disk. These ROMs trap INT 18h to gain access to the system." [Programmer's Guide to the AMIBIOS] (that also lets me know I can't use the INT 18h ISR later to jump into ROM BASIC for a programming idea). So why does IBM have a call just to locate the ROM BASIC location? It may be good anyhow, because not using the INT 18h ISR I may have to jump into a specified location. Maybe this needs a side note on which microchannel NIC boot ROMs have their own INT 18h ISR (all by default?). David David@IBMMuseum.com > > I have not been able to determine if the BASIC code is still present > > in ROM. I guess it could be there for compatability reasons. Now if it was there for functional compatibility, I guess BASICA.COM would find it (so it would be enough to just run it) ?? > If I would ever flesh out the call into a program that would check > we could be sure: > http://www.IBMMuseum.com/Interrupts/INT15h/INT15h22.html ... And how about doing a memory scan for a BASIC signature (the code in IBM machines is always the same C1.10 1981 version, right?) Talk to Group Hi! > And how about doing a memory scan for a BASIC signature > (the code in IBM machines is always the same C1.10 1981 > version, right?) That's the only version I'm aware of seeing. After preparing a FreeDOS 1.0 boot diskette (and learning that the 9585-0X6 really doesn't like the EMM386 provided with FreeDOS) I explored the 9585 "X" BIOS. I found a few copyright strings in the BIOS, one reading 1981-1993 and the other reading 1981-1992. I also found an FRU (61G2399) number in there. But there was no sign of the C1.10 version number, 1981 copyright or anything else that seemed like an obvious ROM BASIC. Not having a convenient copy of the BASIC or BASICA programs, that is as far as I can go for now. William wm_walsh@hotmail.com wrote: > Not having a convenient copy of the BASIC or BASICA programs, that is > as far as I can go for now. The 9590-DLG machines that I used in my previous job must have had BASIC in ROM, as we had a suite of BASICA programs that ran on them. This brings to mind a fairly simple test for the presence of ROM BASIC -- make a copy of the PC-DOS 3.3 boot diskette, boot it on the test PS/2, run BASICA. If you get into BASIC, you've got ROM BASIC. Try the same on most clones, it will fail. I'd actually be a bit surprised if any PS/2 did *not* have ROM BASIC. Rick Ekblaw Hi Michal, William & Rick, >> http://www.IBMMuseum.com/Interrupts/INT15h/INT15h22.html > And how about doing a memory scan for a BASIC signature (the code > in IBM machines is always the same C1.10 1981 version, right?) Page now updated a little more. A search for the string at F600h:0000h would be done first (I need the exact text to match, and an offset if any), then if that fails issue the call. With time I'd like to populate (even having the "unsupported" PS/2s, but marking that they had ROM BASIC at F600h:0000h) entries, including the non-standard ROM BASIC locations of particular models. I would think that the BASIC/BASICA stub loader included with PC-DOS 3.3 would have the ROM BASIC location hard-coded to F600h:0000h. It wouldn't run this call, which came at a later timeframe. So unless it searches for the string (or some other identifier) I think it would fail to run on later PS/2s with a non-standard ROM BASIC location. The "Interrupts" section of my domain will eventually have the hardware interrupt responses various PS/2s & other IBM systems give. Right now I'm a little stretched to do a program for this particular function. Maybe in a few weeks I can get to it if nothing else has been done. David David@IBMMuseum.com