Interrupt 18h on an 8088 to trigger "retro" BASIC mode
TK
I have an IBM XT computer with an Intel 8088 CPU, the computer has
576kB of memory and thus cannot really compete with my Mac Mini.
Regardless, I've played around with it a bit during Xmas vacation as
I've had some time to spare. If I remove the harddrive, it boots
directly into IBM Basic.
The computer normally runs MS-DOS 4 as it is installed on the 10MB
harddrive. I wrote a quick program using DEBUG, in order to drop into
BASIC mode again. The interrupt in question should be 18h.
I run the simple instruction:
INT 18 -- This triggers BASIC mode immediately
So, it triggers BASIC mode, and all looks "fine". However, the
keyboard is not functional. I can't type anything. Is DOS still in
control of the keyboard, perhaps, or may something else be wrong?
Thanks!
Rod Pemberton
news:7b9d8387-3eeb-473e...@j25g2000yqa.googlegroups.com...
All I can do is make some *wild* guesses:
DOS installs interrupt routines. This also changes the IVT table. These
routines may be incompatible with BASIC.
BASIC could be overwriting DOS memory since DOS isn't normally present when
BASIC loads. If a DOS interrupt routine is being called which has corrupted
memory, ...
It's possible that DOS reprograms the PIC's differently than the BIOS and
therefore as needed by BASIC.
It's possible that an EOI for keyboard etc. is not cleared.
It's possible that interrupts may need to be disabled.
If I were trying to locate the issue, I'd start by saving a clean IVT - one
not modified by DOS. The clean IVT should only point to BIOS, video BIOS,
or BASIC ROM routines. Then, I'd load the clean IVT prior to executing INT
18. You'll need a custom bootsector routine to bootup and save the clean
IVT to disk. You'll also need a custom DOS program to load it. If BASIC
works, then it's a DOS interrupt routine or a memory overwritten issue. If
BASIC doesn't work with a DOS free IVT, it's something else: PIC, EOI, etc.
DOS saves info on some of the IVT's it changes. Other modified IVT vectors
can be determined from the IVT table itself. However, generating a good IVT
after the fact from that info is difficult. DOS expects all changes to the
IVT to be done through an intterupt call, not directly to the table. But,
you shouldn't be calling DOS directly or indirectly, so just reloading the
table should work. IIRC, DOS doesn't relocate the IVT so an LIDT in RM
shouldn't be necessary.
Rod Pemberton
Frank Kotler
Reminds me of the system I started on. The original price of that 10M
drive would probably buy you a complete system, these days!
I don't know the answer to your question. Have you tried writing this to
a (two byte) disk file? Or do you just run it from debug? It *might* be
that debug is the one who is "still in control of the keyboard"(?). Let
us know if you figure it out.
You may be disappointed when you get into basic. As I recall, ROM-basic
is pretty puny - you'd want "BASICA" (advanced!) to "do" anything...
like save your program to disk.
Congratulations on finding an 8088 that still boots! Will your Mac Mini
still be running after such a time? :)
Best,
Frank
s_dub...@nospicedham.yahoo.com
<do_not_h...@nospicedham.notreplytome.cmm> wrote:
> "TK" <torbjo...@nospicedham.gmail.com> wrote in message
>
> - Show quoted text -
Dos 4 is pretty new for an XT class. It probably does overwrite the
Basic area..
Vintage ibmdos though can be found here:
http://www.retroarchive.org/dos/disks/
assuming your 5 1/4 floppy drives are working, and you have thr proper
media yet.
hth,
Steve
TK
wrote:
> TK wrote:
> > Hello gents,
>
> > I have an IBM XT computer with an Intel 8088 CPU, the computer has
> > 576kB of memory and thus cannot really compete with my Mac Mini.
> > Regardless, I've played around with it a bit during Xmas vacation as
> > I've had some time to spare. If I remove the harddrive, it boots
> > directly into IBM Basic.
>
> > The computer normally runs MS-DOS 4 as it is installed on the 10MB
> > harddrive. I wrote a quick program using DEBUG, in order to drop into
> > BASIC mode again. The interrupt in question should be 18h.
>
> > I run the simple instruction:
> > INT 18 -- This triggers BASIC mode immediately
>
> > So, it triggers BASIC mode, and all looks "fine". However, the
> > keyboard is not functional. I can't type anything. Is DOS still in
> > control of the keyboard, perhaps, or may something else be wrong?
> > Thanks!
>
> Reminds me of the system I started on. The original price of that 10M
> drive would probably buy you a complete system, these days!
>
> I don't know the answer to your question. Have you tried writing this to
> a (two byte) disk file? Or do you just run it from debug? It *might* be
> that debug is the one who is "still in control of the keyboard"(?). Let
> us know if you figure it out.
Yes, I tried both ways, a 2 byte .COM file and also directly from
DEBUG.
>
> You may be disappointed when you get into basic. As I recall, ROM-basic
> is pretty puny - you'd want "BASICA" (advanced!) to "do" anything...
> like save your program to disk.
Yes, I agree, however it was rather just the task of triggering it w/o
having
to remove the harddrive. I don't think I'll be using it for anything
useful ;-)
as I'd much rather just write some Assembly using DEBUG (unfortunately
nothing
like TASM, etc is available on this computer, and it only has 5 1/4"
floppy disks
so I can't copy files over from another computer in my vicinity)
>
> Congratulations on finding an 8088 that still boots! Will your Mac Mini
> still be running after such a time? :)
>
I doubt it! The IBM is built like a tank, and even though some of the
4164 memory
chips had failed, I could just remove the bad ones and allow the
system to work. I
doubt you could do the same in a few years with the Mac Mini, unless
you were really
good at soldering tiny connections off the onboard memory. :)
> Best,
> Frank
TK
<do_not_h...@nospicedham.notreplytome.cmm> wrote:
> "TK" <torbjo...@nospicedham.gmail.com> wrote in message
>
> news:7b9d8387-3eeb-473e...@j25g2000yqa.googlegroups.com...
>
>
> > I have an IBM XT computer with an Intel 8088 CPU, the computer has
> > 576kB of memory and thus cannot really compete with my Mac Mini.
> > Regardless, I've played around with it a bit during Xmas vacation as
> > I've had some time to spare. If I remove the harddrive, it boots
> > directly into IBM Basic.
>
> > The computer normally runs MS-DOS 4 as it is installed on the 10MB
> > harddrive. I wrote a quick program using DEBUG, in order to drop into
> > BASIC mode again. The interrupt in question should be 18h.
>
> > I run the simple instruction:
> > INT 18 -- This triggers BASIC mode immediately
>
> > So, it triggers BASIC mode, and all looks "fine". However, the
> > keyboard is not functional. I can't type anything. Is DOS still in
> > control of the keyboard, perhaps, or may something else be wrong?
>
> All I can do is make some *wild* guesses:
>
> DOS installs interrupt routines. This also changes the IVT table. These
> routines may be incompatible with BASIC.
>
make sense, indeed.
> BASIC could be overwriting DOS memory since DOS isn't normally present when
> BASIC loads. If a DOS interrupt routine is being called which has corrupted
> memory, ...
>
> It's possible that DOS reprograms the PIC's differently than the BIOS and
> therefore as needed by BASIC.
>
> It's possible that an EOI for keyboard etc. is not cleared.
>
I could look into the ISR register, and look at which interrupts
are waiting for an end of interrupt (EOI) ?
> It's possible that interrupts may need to be disabled.
> If I were trying to locate the issue, I'd start by saving a clean IVT - one
> not modified by DOS. The clean IVT should only point to BIOS, video BIOS,
> or BASIC ROM routines. Then, I'd load the clean IVT prior to executing INT
> 18. You'll need a custom bootsector routine to bootup and save the clean
> IVT to disk. You'll also need a custom DOS program to load it. If BASIC
> works, then it's a DOS interrupt routine or a memory overwritten issue. If
> BASIC doesn't work with a DOS free IVT, it's something else: PIC, EOI, etc.
I see... So the first thing I will then try is to create a custom
bootsector routine to
bootup and save the clean IVT to disk. I presume I will be using 5
1/4" floppy disk
to store the bootsector, as overwriting the harddisk would be a bad
idea.
As far as I can see from the web, the IVT will be found from 0x0000 to
0x03fff.
> DOS saves info on some of the IVT's it changes. Other modified IVT vectors
> can be determined from the IVT table itself. However, generating a good IVT
> after the fact from that info is difficult. DOS expects all changes to the
> IVT to be done through an intterupt call, not directly to the table. But,
> you shouldn't be calling DOS directly or indirectly, so just reloading the
> table should work. IIRC, DOS doesn't relocate the IVT so an LIDT in RM
> shouldn't be necessary.
Thanks!
TK
Hmm, thanks for the tip. Now if could only hook a 5.25" disk drive
onto a modern "PC" so I
could copy the files over.
wolfgang kern
"TK" posted:
> Hello gents,
Hi,
> I have an IBM XT computer with an Intel 8088 CPU, the computer has
> 576kB of memory and thus cannot really compete with my Mac Mini.
> Regardless, I've played around with it a bit during Xmas vacation as
> I've had some time to spare. If I remove the harddrive, it boots
> directly into IBM Basic.
>
> The computer normally runs MS-DOS 4 as it is installed on the 10MB
> harddrive. I wrote a quick program using DEBUG, in order to drop into
> BASIC mode again. The interrupt in question should be 18h.
> I run the simple instruction:
> INT 18 -- This triggers BASIC mode immediately
Yeah, it's supposed to do so if ROM-BASIC exists at all :)
> So, it triggers BASIC mode, and all looks "fine". However, the
> keyboard is not functional. I can't type anything. Is DOS still in
> control of the keyboard, perhaps, or may something else be wrong?
> Thanks!
You can't use any DOS-functions if your BIOS boots in BASIC-mode.
The (good olde) ROM-BASIC will support only BIOS-functions like
INT 10h/13h/16h/1Ah.. but sure not any of INT 21h (unknown by BIOS).
__
wolfgang
wolfgang kern
"TK" said:
...
| As far as I can see from the web, the IVT will be found from
| 0x0000 to 0x03fff.
you got one 'f' to much yet :)
Real-mode IVT spans only one KB,
default is 0000:0000 to 0000:03ffh, 256 entries, four bytes each.
Lowword = offst, highword = segment (aka paragraph).
__
wolfgang
s_dub...@nospicedham.yahoo.com
>
> - Show quoted text -
Well, it is difficult for me to guess your level of knowledge and your
exact XT hardware, but if you have a good selection of floppies with
software on them then is it possible that one of those is bootable.
Have you gone thru each of them to see if the floppy is readable?
Then try booting each one by placing it in the A: drive with the power
off, then turning the power on to see if the floppy is bootable? - you
can use the reset buttom also to reboot.
The Boot order is supposed to be: floppy, else (hd if present) or Rom
Basic. Some add-in hd controllers may default to hd, floppy, basic,
or floppy, hd, basic.
The rom basic allows you to 'peek' memory you if you have the basic
manuals, you can do some rudimentary programming to dump the IVT to
the screen, or other memory areas.
There was IIRC an additional program 'basic' on disk which added
functionality to the RomBasic.
You might ask of family and friends if someone has an old computer
collecting dust, you might find one newer than the XT that has both 5
1/4 and 3 1/2 floppy drives, to help you move files across formats.
Your XT probably has a serial DB-25 port on it. You may already have
a floppy with software to control the port by way of a communications
software like PROCOMM. You may be able to set up a peer to peer link
between computers to tranfer files back and forth thru the serial
port. If the 10mb hard drive came with the system, the previous
operator probably had that software on it. On my XT clone, I use
msdos 3.3, there is rudimentary control of the serial port using the
mode command.
You might also try searching for 'retro' computer sites whose members
are often helpful.
http://www.vintage-computer.com/vcforum or such
Nowadays there is alot of information available thru the web, you can
probably find pdf's of the original ibm documentation for it which are
very specific as to the hardware and bios software. oh, yes..
http://www.retroarchive.org/dos/docs/index.html
http://en.wikipedia.org/wiki/IBM_5160
etc.,
Steve
Steve
TK
>
> Nowadays there is alot of information available thru the web, you can
> probably find pdf's of the original ibm documentation for it which are
> very specific as to the hardware and bios software. oh, yes..
>
> http://www.retroarchive.org/dos/docs/index.html
>
> http://en.wikipedia.org/wiki/IBM_5160
>
have no software such
as PROCOMM, in order to transfer files serially. I think I might look
for a 3.5" floppy
drive for this XT, so I can work with moving files between it more
easily.
About the PEEKing in memory using the ROM-BASIC, why not. It's only a
1kB table, and I need to fetch
4 bytes at a time, writing them down on a piece of paper. Then I
could write an Assembly program using
MS-DEBUG, which overwrites the IVT table before issuing INT 18. :-)
Will see how well my PEEK job goes first!
Regards,
TK
TK
> Will see how well my PEEK job goes first!
>
So the result of my PEEK job is here. It took some time since I had to
manually type
all of this from photographs I took (the XT is in another room and I
don't have a laptop
here). ;-)
Now, I just need to load this into 0000:0000 to 0000:03ff before I
call INT 18.
-- snip snip --
0000:0000 23 FF 00 F0
0000:0004 23 FF 00 F0
0000:0008 5F F8 00 F0
0000:000C 23 FF 00 F0
0000:0010 23 FF 00 F0
0000:0014 54 FF 00 F0
0000:0018 23 FF 00 F0
0000:001C 23 FF 00 F0
0000:0020 A5 FE 00 F0
0000:0024 87 E9 00 F0
0000:0028 23 FF 00 F0
0000:002C 23 FF 00 F0
0000:0030 23 FF 00 F0
0000:0034 23 FF 00 F0
0000:0038 57 EF 00 F0
0000:003C 23 FF 00 F0
0000:0040 65 F0 00 F0
0000:0044 4D F8 00 F0
0000:0048 41 F8 00 F0
0000:004C 59 EC 00 F0
0000:0050 39 E7 00 F0
0000:0054 59 F8 00 F0
0000:0058 2E E8 00 F0
0000:005C D2 EF 00 F0
0000:0060 00 00 00 F6
0000:0064 F2 E6 00 F0
0000:0068 6E FE 00 F0
0000:006C 34 4D 00 F6
0000:0070 44 57 00 F6
0000:0074 A4 F0 00 F0
0000:0078 C7 EF 00 F0
0000:007C 00 00 00 F0
0000:0080 00 00 00 00
0000:0084 00 00 00 00
0000:0088 00 00 00 00
0000:008C 00 00 00 00
0000:0090 00 00 00 00
0000:0094 00 00 00 00
0000:0098 00 00 00 00
0000:009C 00 00 00 00
0000:00A0 00 00 00 00
0000:00A4 00 00 00 00
0000:00A8 00 00 00 00
0000:00AC 00 00 00 00
0000:00B0 00 00 00 00
0000:00B4 00 00 00 00
0000:00B8 00 00 00 00
0000:00BC 00 00 00 00
0000:00C0 00 00 00 00
0000:00C4 00 00 00 00
0000:00C8 00 00 00 00
0000:00CC 00 00 00 00
0000:00D0 00 00 00 00
0000:00D4 00 00 00 00
0000:00D8 00 00 00 00
0000:00DC 00 00 00 00
0000:00E0 00 00 00 00
0000:00E4 00 00 00 00
0000:00E8 00 00 00 00
0000:00EC 00 00 00 00
0000:00F0 00 00 00 00
0000:00F4 00 00 00 00
0000:00F8 00 00 00 00
0000:00FC 00 00 00 00
0000:0100 00 00 00 00
0000:0104 00 00 00 00
0000:0108 00 00 00 00
0000:010C 00 00 00 00
0000:0110 00 00 00 00
0000:0114 00 00 00 00
0000:0118 00 00 00 00
0000:011C 00 00 00 00
0000:0120 00 00 00 00
0000:0124 00 00 00 00
0000:0128 00 00 00 00
0000:012C 00 00 00 00
0000:0130 00 00 00 00
0000:0134 00 00 00 00
0000:0138 00 00 00 00
0000:013C 00 00 00 00
0000:0140 00 00 00 00
0000:0144 00 00 00 00
0000:0148 00 00 00 00
0000:014C 00 00 00 00
0000:0150 00 00 00 00
0000:0154 00 00 00 00
0000:0158 00 00 00 00
0000:015C 00 00 00 00
0000:0160 00 00 00 00
0000:0164 00 00 00 00
0000:0168 00 00 00 00
0000:016C 00 00 00 00
0000:0170 00 00 00 00
0000:0174 00 00 00 00
0000:0178 00 00 00 00
0000:017C 00 00 00 00
0000:0180 00 00 00 00
0000:0184 00 00 00 00
0000:0188 00 00 00 00
0000:018C 00 00 00 00
0000:0190 00 00 00 00
0000:0194 00 00 00 00
0000:0198 00 00 00 00
0000:019C 00 00 00 00
0000:01A0 00 00 00 00
0000:01A4 00 00 00 00
0000:01A8 00 00 00 00
0000:01AC 00 00 00 00
0000:01B0 00 00 00 00
0000:01B4 00 00 00 00
0000:01B8 00 00 00 00
0000:01BC 00 00 00 00
0000:01C0 00 00 00 00
0000:01C4 00 00 00 00
0000:01C8 00 00 00 00
0000:01CC 00 00 00 00
0000:01D0 00 00 00 00
0000:01D4 00 00 00 00
0000:01D8 00 00 00 00
0000:01DC 00 00 00 00
0000:01E0 00 00 00 00
0000:01E4 00 00 00 00
0000:01E8 00 00 00 00
0000:01EC 00 00 00 00
0000:01F0 00 00 00 00
0000:01F4 00 00 00 00
0000:01F8 00 00 00 00
0000:01FC 00 00 00 00
0000:0200 00 00 00 00
0000:0204 00 00 00 00
0000:0208 00 00 00 00
0000:020C 00 00 00 00
0000:0210 00 00 00 00
0000:0214 00 00 00 00
0000:0218 94 4C 00 F6
0000:021C 94 4C 00 F6
0000:0220 94 4C 00 F6
0000:0224 94 4C 00 F6
0000:0228 94 4C 00 F6
0000:022C 94 4C 00 F6
0000:0230 94 4C 00 F6
0000:0234 94 4C 00 F6
0000:0238 94 4C 00 F6
0000:023C 94 4C 00 F6
0000:0240 94 4C 00 F6
0000:0244 94 4C 00 F6
0000:0248 94 4C 00 F6
0000:024C 94 4C 00 F6
0000:0250 94 4C 00 F6
0000:0254 94 4C 00 F6
0000:0258 94 4C 00 F6
0000:025C 94 4C 00 F6
0000:0260 94 4C 00 F6
0000:0264 94 4C 00 F6
0000:0268 94 4C 00 F6
0000:026C 94 4C 00 F6
0000:0270 94 4C 00 F6
0000:0274 94 4C 00 F6
0000:0278 94 4C 00 F6
0000:027C 94 4C 00 F6
0000:0280 94 4C 00 F6
0000:0284 94 4C 00 F6
0000:0288 94 4C 00 F6
0000:028C 94 4C 00 F6
0000:0290 94 4C 00 F6
0000:0294 94 4C 00 F6
0000:0298 94 4C 00 F6
0000:029C 94 4C 00 F6
0000:02A0 94 4C 00 F6
0000:02A4 94 4C 00 F6
0000:02A8 94 4C 00 F6
0000:02AC 94 4C 00 F6
0000:02B0 94 4C 00 F6
0000:02B4 94 4C 00 F6
0000:02B8 94 4C 00 F6
0000:02BC 94 4C 00 F6
0000:02C0 94 4C 00 F6
0000:02C4 94 4C 00 F6
0000:02C8 94 4C 00 F6
0000:02CC 94 4C 00 F6
0000:02D0 94 4C 00 F6
0000:02D4 94 4C 00 F6
0000:02D8 94 4C 00 F6
0000:02DC 94 4C 00 F6
0000:02E0 94 4C 00 F6
0000:02E4 94 4C 00 F6
0000:02E8 94 4C 00 F6
0000:02EC 94 4C 00 F6
0000:02F0 94 4C 00 F6
0000:02F4 94 4C 00 F6
0000:02F8 94 4C 00 F6
0000:02FC 94 4C 00 F6
0000:0300 94 4C 00 F6
0000:0304 94 4C 00 F6
0000:0308 94 4C 00 F6
0000:030C 94 4C 00 F6
0000:0310 94 4C 00 F6
0000:0314 94 4C 00 F6
0000:0318 94 4C 00 F6
0000:031C 94 4C 00 F6
0000:0320 94 4C 00 F6
0000:0324 94 4C 00 F6
0000:0328 94 4C 00 F6
0000:032C 94 4C 00 F6
0000:0330 94 4C 00 F6
0000:0334 94 4C 00 F6
0000:0338 94 4C 00 F6
0000:033C 94 4C 00 F6
0000:0340 94 4C 00 F6
0000:0344 94 4C 00 F6
0000:0348 94 4C 00 F6
0000:034C 94 4C 00 F6
0000:0350 94 4C 00 F6
0000:0354 94 4C 00 F6
0000:0358 94 4C 00 F6
0000:035C 94 4C 00 F6
0000:0360 94 4C 00 F6
0000:0364 94 4C 00 F6
0000:0368 94 4C 00 F6
0000:036C 94 4C 00 F6
0000:0370 94 4C 00 F6
0000:0374 94 4C 00 F6
0000:0378 94 4C 00 F6
0000:037C 94 4C 00 F6
0000:0380 94 4C 00 F6
0000:0384 94 4C 00 F6
0000:0388 94 4C 00 F6
0000:038C 94 4C 00 F6
0000:0390 94 4C 00 F6
0000:0394 94 4C 00 F6
0000:0398 94 4C 00 F6
0000:039C 94 4C 00 F6
0000:03A0 94 4C 00 F6
0000:03A4 94 4C 00 F6
0000:03A8 94 4C 00 F6
0000:03AC 94 4C 00 F6
0000:03B0 94 4C 00 F6
0000:03B4 94 4C 00 F6
0000:03B8 94 4C 00 F6
0000:03BC 94 4C 00 F6
0000:03C0 94 4C 00 F6
0000:03C4 94 4C 00 F6
0000:03C8 94 4C 00 F6
0000:03CC 94 4C 00 F6
0000:03D0 94 4C 00 F6
0000:03D4 94 4C 00 F6
0000:03D8 94 4C 00 F7
0000:03DC 94 4C 00 F6
0000:03E0 94 4C 00 F6
0000:03E4 94 4C 00 F6
0000:03E8 94 4C 00 F6
0000:03EC 94 4C 00 F6
0000:03F0 94 4C 00 F6
0000:03F4 94 4C 00 F6
0000:03F8 94 4C 00 F6
0000:03FC 94 4C 00 F6
-- snip snip --
Rod Pemberton
> On Jan 2, 9:49 pm, TK <torbjo...@nospicedham.gmail.com> wrote:
> > Will see how well my PEEK job goes first!
> >
>
> So the result of my PEEK job is here. It took some time since I
> had to manually type
> all of this from photographs I took (the XT is in another room
> and I don't have a laptop here). ;-)
>
> Now, I just need to load this into 0000:0000 to 0000:03ff before I
> call INT 18.
>
> -- snip snip --
> 0000:0000 23 FF 00 F0
> 0000:0004 23 FF 00 F0
Thanks.
If you "undump" your hex IVT out as a .bin named vectable.dat, you can use
FLOPPER to boot 5.25" images from your HD:
http://www.oldskool.org/pc/flopper
Sorry, I forgot that it has a utility to save your IVT... You'll have to
test if it works, or if you can get it onto the correct disk.
Rod Pemberton
PS Anyone able to dump the default BIOS IVT for an IBM AT w/ hardisk? i.e.,
before DOS...
Frank Kotler
...
> Hmm, thanks for the tip. Now if could only hook a 5.25" disk drive
> onto a modern "PC" so I
> could copy the files over.
It might be worth your while to look for "interlnk.exe" and
"intersvr.exe". I recalled that they were introduced with dos 5.0, but
what I can find now indicates 6.22. In any case, they allow you to
transfer files between computers over a "null modem cable" between
serial ports (or perhaps a Laplink" cable between parallel ports). As I
recall, there was a command that would allow you to copy the initial
files...
intersvr /RCOPY
??? In any case, I remember being able to transfer files, entirely
bypassing the 5.25" floppy. You'd need the null modem cable ($10.00 or
so)... and a second pc... or *maybe* it would work with some kind of
"fake dos" on your Mac(?). As I recall, a serial port is an expansion
card on the 8088 - you've probably got one(?). I don't think "/RCOPY"
will work with a parallel port(?). DEBUG is a powerful little tool, but
if you're serious about "doing" anything on the 8088, you'll want a way
to get software onto it!
Best,
Frank
Bob Masta
>PS Anyone able to dump the default BIOS IVT for an IBM AT w/ hardisk? i.e.,
>before DOS...
I'm not sure if this is what you want, but I know that the
early DOS versions (at least through 2.x) booted a "normal"
IVT, whereby you could easily follow the vectors to find the
ROM BIOS routines. Later versions went through a convoluted
DOS "handler" that made it very difficult to find anything.
"Back in the day", when I was trying to understand the hard
disk BIOS operation (so I could make a custom HD handler
that could be interrupted by my data acquisition software
for streaming to disk), I would boot from DOS 2.x to get the
vector to the HD BIOS, then dump the calls I needed so I
could disassemble them. Worked great!
Hope this helps.
Bob Masta
DAQARTA v6.00
Data AcQuisition And Real-Time Analysis
www.daqarta.com
Scope, Spectrum, Spectrogram, Sound Level Meter
Frequency Counter, FREE Signal Generator
Pitch Track, Pitch-to-MIDI
Science with your sound card!
TK
> On Mon, 3 Jan 2011 05:29:29 -0500, "Rod Pemberton"
>
>
Sorry guys, I am a bit stuck with something very assembly related.
I have some code like this now:
jmp XXX ; jump past the following declare-byte section
db 23, ff, 00, f0
db 23, ff, 00, f0
db 5f, f8, 00, f0
db 23, ff, 00, f0
; .. etc etc ...
mov ax, 0000 ; ivt segment is at 0000
mov ds, ax ; I now make the data segment to be 0000 so I can
write to it
Ok, I have some code further on from here, but I don't think I should
post it as it
is just plainly wrong.
I simply need to move data from the bytes declared into 0000:0000 to
0000:03FFF.
I was planning to set CX to 1024, since I know I have exactly 1kB to
copy, and then use
LOOP (which decrements CX by 1 each iteration).
Can anyone give me a push in the right direction? Thanks!
TK
PS I thought of entering the entire IVT table using 'e', in DEBUG, but
I don't think
that's a good idea since I risk that DEBUG stops working even before
my instructions
start executing.
s_dub...@nospicedham.yahoo.com
> On Jan 3, 3:20 pm, N0S...@daqarta.com (Bob Masta) wrote:
>
> > On Mon, 3 Jan 2011 05:29:29 -0500, "Rod Pemberton"
>
> Sorry guys, I am a bit stuck with something very assembly related.
>
> I have some code like this now:
>
> jmp XXX ; jump past the following declare-byte section
> db 23, ff, 00, f0
> db 23, ff, 00, f0
> db 5f, f8, 00, f0
> db 23, ff, 00, f0
> ; .. etc etc ...
>
> mov ax, 0000 ; ivt segment is at 0000
> mov ds, ax ; I now make the data segment to be 0000 so I can
> write to it
>
> Ok, I have some code further on from here, but I don't think I should
> post it as it
> is just plainly wrong.
>
> I simply need to move data from the bytes declared into 0000:0000 to
> 0000:03FFF.
MOVSB copies the byte at [DS:SI] to [ES:DI]. It then increments or
decrements (depending on the direction flag: increments if the flag is
clear, decrements if it is set) SI and DI.
cld
mov di, 600h
mov si, 0
mov cx, 400h
push ds
pop es
movsb
[nasm syntax] maybe you want a different destination. Don't move to
anywhere in 0000:0000h .. 0000:0510h ; 0400 .. 0503h bios data area.
move from even to even address or you'll get screwed up.. to 4000h not
3FFFh
Steve
TK
Thanks, I was at it again the last couple hrs, and trying to go
through all my declared
bytes (from the code segment), and then pushing them onto the stack.
Once I had
them all on the stack, I would change the DS to 0000, and then write
it to 0000:0000 to 0000:03ff. I hadn't
gotten it to work yet, and now I see that your approach is a lot
better so I will ditch my current work. :)
If I understand you correctly, I want to move to 0000:0001 up to
0000:0400 ? And not 0000:0000 to 0000:03FF. Not sure if I understand
why...
In the meantime, I will now sleep before trying again!
Thanks Steve
Frank Kotler
> On Jan 3, 9:51 am, TK <torbjo...@nospicedham.gmail.com> wrote:
>> On Jan 3, 3:20 pm, N0S...@daqarta.com (Bob Masta) wrote:
>>
>>> On Mon, 3 Jan 2011 05:29:29 -0500, "Rod Pemberton"
>> Sorry guys, I am a bit stuck with something very assembly related.
>>
>> I have some code like this now:
>>
>> jmp XXX ; jump past the following declare-byte section
>> db 23, ff, 00, f0
>> db 23, ff, 00, f0
>> db 5f, f8, 00, f0
>> db 23, ff, 00, f0
>> ; .. etc etc ...
>>
>> mov ax, 0000 ; ivt segment is at 0000
>> mov ds, ax ; I now make the data segment to be 0000 so I can
>> write to it
I'm thinking you may want to leave ds alone (so we can find the "src"),
and set es to zero...
>> Ok, I have some code further on from here, but I don't think I should
>> post it as it
>> is just plainly wrong.
Well, that's the part we need to see! :)
>> I simply need to move data from the bytes declared into 0000:0000 to
>> 0000:03FFF.
One too many 'F's?
> MOVSB copies the byte at [DS:SI] to [ES:DI]. It then increments or
> decrements (depending on the direction flag: increments if the flag is
> clear, decrements if it is set) SI and DI.
>
> cld
> mov di, 600h
> mov si, 0
> mov cx, 400h
> push ds
> pop es
> movsb
>
> [nasm syntax] maybe you want a different destination. Don't move to
> anywhere in 0000:0000h .. 0000:0510h ; 0400 .. 0503h bios data area.
> move from even to even address or you'll get screwed up.. to 4000h not
> 3FFFh
Again, one too many 'F's?
If I understand what TK needs to do, he *wants* to overwrite the
existing IVT (with dos/debug running) with the "original" IVT, now part
of his debug code... right?
- a 100
jmp XXX ; jump past the following declare-byte section
db 23, ff, 00, f0
db 23, ff, 00, f0
db 5f, f8, 00, f0
db 23, ff, 00, f0
; .. etc etc ...
At XXX...
cld ; direction flag is probably already "up"... Make sure!
cli ; we probably don't want interrupts firing while we do this!
xor ax, ax ; make destination 0000:0000
mov es, ax
mov di, ax
mov si, 103 ; or 105, if it's a near jmp - start of "db" section
mov cx, 400 ; debug expects hex
rep ; I suspect debug wants this on a separate line?
movsb
sti
int 18
; "enter" to quit 'a'sm mode
; - n "myfile.com"
; mov cx, length_of_code ; use 'r' here instead, I guess?
; - w 100...???
; - q
Is that right? I'm not sure I'm thinking clearly...
>> I was planning to set CX to 1024,
Right, but debug expects hex, so 400.
>> since I know I have exactly 1kB to
>> copy, and then use
>> LOOP (which decrements CX by 1 each iteration).
That should work, too. I like the "rep movsb" better, since we don't
need to figure out the target for "loop"...
>> Can anyone give me a push in the right direction? Thanks!
Opposite direction from "pop" - that's easy! :)
>> TK
>>
>> PS I thought of entering the entire IVT table using 'e', in DEBUG, but
>> I don't think
>> that's a good idea since I risk that DEBUG stops working even before
>> my instructions
>> start executing.
Probably correct! Note the "cli" (turn off interrupts) and "sti" (turn
interrupts back on) in my proposed code. Good luck!
Best,
Frank
s_dub...@nospicedham.yahoo.com
well, actually push ds; pop es; may not give what you want because, it
seems you are using debug, so where ever you are putting this code
makes a difference, because of the segment you are working in. (what
ever debug sets as the segment for you, and also debug defaults IP to
0100h.)
So you have to save DS, enter the correct destination segment for TO:
in ES, and load DS with 0000h for the source segment.
CLI
REP movsb ;; thanks Frank, I had a brain fart ;)
STI
> > movsb
>
> > [nasm syntax] maybe you want a different destination. Don't move to
> > anywhere in 0000:0000h .. 0000:0510h ; 0400 .. 0503h bios data area.
> > move from even to even address or you'll get screwed up.. to 4000h not
> > 3FFFh
>
> > Steve
>
> Thanks, I was at it again the last couple hrs, and trying to go
> through all my declared
> bytes (from the code segment), and then pushing them onto the stack.
> Once I had
> them all on the stack, I would change the DS to 0000, and then write
> it to 0000:0000 to 0000:03ff. I hadn't
> gotten it to work yet, and now I see that your approach is a lot
> better so I will ditch my current work. :)
>
> If I understand you correctly, I want to move to 0000:0001 up to
> 0000:0400 ? And not 0000:0000 to 0000:03FF. Not sure if I understand
> why...
Oh, I read your :03FFFh as a destination, sorry. I usually give a
range as 0000..03FFh. that's inclusive. To show from/to I usually use
an arrow to avoid misunderstanding..
0000:0000h..03FFh -> 8000:0000h ;; is my recommendation.
Steve
>
> In the meantime, I will now sleep before trying again!
>
> Thanks Steve- Hide quoted text -
Ross Ridge
>Hmm, thanks for the tip. Now if could only hook a 5.25" disk drive
>onto a modern "PC" so I could copy the files over.
You can take the 5.25" drive out of your IBM PC XT and connect to any
PC with an internal floppy connector. While not all PCs haves this
connector on their motherboards these days, many still do. If have PC
with a 3.5" drive installed, then that will do the trick. You'll need
to use the cable from your PC XT, the connector on the 5.25" drive
is different from the one on the 3.5" drive. (The connector on the
motherboard is the same.)
The easiest way to get into BASIC from MS-DOS is to use BASICA:
http://en.wikipedia.org/wiki/IBM_BASICA
Check to see if that command is on your XT already.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
wolfgang kern
"TK" wrote:
...
>> I have some code like this now:
>> jmp XXX ; jump past the following declare-byte section
>> db 23, ff, 00, f0
>> db 23, ff, 00, f0
>> db 5f, f8, 00, f0
>> db 23, ff, 00, f0
>> ; .. etc etc ...
In general it's really a bad idea to mix code and data on x86.
Nevertheless it would work if you start your datafield with a
label ...,or if you know the address of the first db then your
data reside in the CodeSegment:
MOVSb ;normally transfer a byte from DS:si to ES:di
and with a segment override (works on source only):
CS: MOVSb ;moves from CS:si to ES:di
same tools need this preceding CS: (also REP) on separate lines.
Even I'd had date quite different organised your way could work:
jmp XXX
ALIGN 4 ;not required but recommended for speed
IVT_data:
db ...
db ...
XXX:
CLD ;make direction up
CLI ;disable IRQs (exceptions can't be disabled)
MOV cx,0200h ;512 words to move
XOR di,di ;
MOV es,di ;es:di = 0000:0000
MOV si,IVT_data ;without brackets (MASM may need OFFSET here)
REP CS: MOVSW ;copy 512 dwords
STI ;enable IRQ and pray for valid IVT-entries :)
...
on 386 and up the loop can be reduced to 256 iterations by
using MOVSD instead.
__
wolfgang
TK
wrote:
I tried this now, and it did not work and I think it is related to
that I am
overwriting the entire IVT table. The entire machine completely
freezes.
For the sake of testing:
I changed the INT 18 to MOV AH,0 and INT 21 to make the program
actually exit in DOS. With 400h
bytes written into 0000:0000..03ffh, it does not even reach INT 21, so
I assume that it sufficiently
"disturbs" the interrupt routines so much that it cannot continue the
execution. I did a trace and it
stops after the 6th byte has been copied from DS to ES. There is a
slight green flicker of the screen.
Now on to my proposal :-)
I can imagine that the IVT contains some interrupts that are relevant
to keyboards, so an idea
of mine is to only overwrite the relevant keyboard vectors, which will
then hopefully allow me
to use INT 18. (Just a reminder from the original thread; INT 18
works fine, but keyboard does
not work, which led us to go down this path).
Am I correct in that there may be a 4 byte entry somewhere in the IVT
that I should overwrite instead
of overwriting all 400h bytes? It may be a much safer option.
Regards,
TK
Rod Pemberton
[SNIP]
> > Probably correct! Note the "cli" (turn off interrupts) and "sti" (turn
> > interrupts back on) in my proposed code. Good luck!
> >
>
> I tried this now, and it did not work and I think it is related to
> that I am
> overwriting the entire IVT table. The entire machine completely
> freezes.
>
You used CLI/STI around the code prior to INT 18h? And, it still hung? At
the moment, I'm suspecting your code...
But, assuming the code is correct, there may be a hardware NMI generating an
interrupt. NMI's require a small routine to disable them.
First, I'd verify that the table was written completely and to the correct
locations, i.e., not off by one memory location, not missing the first or
last byte, only moving ONE byte at a time - x86 is little endian - no STOSD,
no STOSW, no MOVSD, no MOVSW, etc. E.g., after you've overwritten the IVT,
display the bytes there between 0 and 3FFh, one byte at a time. Are they
correct? They should match what you posted previously.
> For the sake of testing:
> I changed the INT 18 to MOV AH,0 and INT 21 to make the program
> actually exit in DOS. With 400h
> bytes written into 0000:0000..03ffh, it does not even reach INT 21, so
>
First, how do you know "it does not even reach INT 21"? Did you write a
character to the screen prior to INT 21h?
Second, if you've changed the IVT and that's what you're attempting, you
SHOULD NOT exit to DOS... The vectors DOS needs to work correctly are no
longer present.
> I did a trace
>
A trace? With what? Debuggers use interrupts... usually INT 3h. Are you
using a debugger? Don't do that. No, I'm not joking.
Rod Pemberton
pe...@nospam.demon.co.uk
do_no...@nospicedham.notreplytome.cmm "Rod Pemberton" writes:
> "TK" <torb...@nospicedham.gmail.com> wrote in message
> news:de4d5a31-5dc9-46d4...@z19g2000yqb.googlegroups.com...
> [SNIP]
>
> > > Probably correct! Note the "cli" (turn off interrupts) and "sti" (turn
> > > interrupts back on) in my proposed code. Good luck!
> > >
> >
> > I tried this now, and it did not work and I think it is related to
> > that I am
> > overwriting the entire IVT table. The entire machine completely
> > freezes.
> >
>
> You used CLI/STI around the code prior to INT 18h? And, it still hung? At
> the moment, I'm suspecting your code...
>
> But, assuming the code is correct, there may be a hardware NMI generating an
> interrupt. NMI's require a small routine to disable them.
>
> First, I'd verify that the table was written completely and to the correct
> locations, i.e., not off by one memory location, not missing the first or
> last byte, only moving ONE byte at a time - x86 is little endian - no STOSD,
> no STOSW, no MOVSD, no MOVSW, etc. E.g., after you've overwritten the IVT,
> display the bytes there between 0 and 3FFh, one byte at a time. Are they
> correct? They should match what you posted previously.
The only drawback with that would be if any BIOS service entries
(especially INT 10) had been overwritten...
> > For the sake of testing:
> > I changed the INT 18 to MOV AH,0 and INT 21 to make the program
> > actually exit in DOS. With 400h
> > bytes written into 0000:0000..03ffh, it does not even reach INT 21, so
> >
>
> First, how do you know "it does not even reach INT 21"? Did you write a
> character to the screen prior to INT 21h?
>
> Second, if you've changed the IVT and that's what you're attempting, you
> SHOULD NOT exit to DOS... The vectors DOS needs to work correctly are no
> longer present.
>
> > I did a trace
> >
>
> A trace? With what? Debuggers use interrupts... usually INT 3h. Are you
> using a debugger? Don't do that. No, I'm not joking.
>
>
> Rod Pemberton
Single-stepping (INT 1) would cause the hang even quicker (assuming
that TK is copying using incrementing addresses). It strikes me that
replacing the entire IVT should be done as quickly as possible and
with no external interference, so a small .com file much as Frank
suggested (CLI/REP STOSB/STI) should do the trick, but should "exit"
with a INT 18h. As Rod said, you do NOT want to return to DOS.
Once you have that working, and if you really want to be cute, you
could rewrite that code as a TSR that was invoked hooking INT 5 --
then you could enter rom basic by pressing the PrtScrn key ;-)
Pete
--
"We have not inherited the earth from our ancestors,
we have borrowed it from our descendants."
Frank Kotler
[for reference]
>> - a 100
>> jmp XXX ; jump past the following declare-byte section
>> db 23, ff, 00, f0
>> db 23, ff, 00, f0
>> db 5f, f8, 00, f0
>> db 23, ff, 00, f0
>> ; .. etc etc ...
>>
>> At XXX...
>>
>> cld ; direction flag is probably already "up"... Make sure!
>> cli ; we probably don't want interrupts firing while we do this!
>> xor ax, ax ; make destination 0000:0000
>> mov es, ax
>> mov di, ax
>> mov si, 103 ; or 105, if it's a near jmp - start of "db" section
Duh! Definitely 105. A "short" jmp ain't gonna clear 1024 bytes of
data!!! You should be able to examine your code in DEBUG to confirm the
address you want here. Should be the address of that first "23".
>> mov cx, 400 ; debug expects hex
>> rep ; I suspect debug wants this on a separate line?
>> movsb
>> sti
>> int 18
>> ; "enter" to quit 'a'sm mode
>> ; - n "myfile.com"
>> ; mov cx, length_of_code ; use 'r' here instead, I guess?
>> ; - w 100...???
>> ; - q
...
> I tried this now, and it did not work
I'm shocked. Shocked, I tell ya! :)
Seriously, I'd have been pleasantly surprised (mildly, at least) if it
*did* work. We're starting with an assumption about why the keyboard
doesn't work after entering rom-basic via int 18 (hex), after a "normal"
boot (but does, if entered via "no bootable disk"). Rod mentioned
another couple of possibilities besides this one. After ruling out my
simple "blame debug" idea, this seems most likely... but it could be
something else. If this is the problem, and if neither of us made any
mistakes, it might have worked. Lot of "if"s...
> and I think it is related to
> that I am
> overwriting the entire IVT table. The entire machine completely
> freezes.
>
> For the sake of testing:
> I changed the INT 18 to MOV AH,0 and INT 21 to make the program
> actually exit in DOS.
Since we've clobbered the "int 21 slot" with zeros, this is no surprise.
After overwriting the entire IVT, that "int 18" is probably the only
thing that *will* work... if that... Maybe an int 10...
...
mov bx, 7
mov ax, 0E41
int 10
...
That might put an 'A' on the screen - a "we got this far" indication...
> With 400h
> bytes written into 0000:0000..03ffh, it does not even reach INT 21, so
> I assume that it sufficiently
> "disturbs" the interrupt routines so much that it cannot continue the
> execution. I did a trace and it
> stops after the 6th byte has been copied from DS to ES.
That would be smack in the middle of "int 1", the "single step"
interrupt, which DEBUG would be using. Lucky to have made it past byte
5, I guess. Rod was suggesting to do this from a bootsector on floppy, I
think. Might be a good idea, if you have a working 5.25" floppy... but
at that point dos wouldn't have altered the IVT anyway...
> There is a
> slight green flicker of the screen.
Funny, the only flicker I ever got from my 8088 was amber. :)
> Now on to my proposal :-)
> I can imagine that the IVT contains some interrupts that are relevant
> to keyboards,
True enough. The keyboard controller generates an interrupt when a key
is pressed, and another when the key is released. int 9 handles these
interrupts. int 16 (hex) also deals with the keyboard (may be used by
int 9 to stuff the key into the keyboard buffer - part of the Bios Data
Area). Restoring just those two interrupts might be something to try.
> so an idea
> of mine is to only overwrite the relevant keyboard vectors, which will
> then hopefully allow me
> to use INT 18. (Just a reminder from the original thread; INT 18
> works fine, but keyboard does
> not work, which led us to go down this path).
>
> Am I correct in that there may be a 4 byte entry somewhere in the IVT
> that I should overwrite instead
> of overwriting all 400h bytes? It may be a much safer option.
Good thought!
Just for reference, here's the original IVT as you originally posted it.
Odd that several of the low-numbered interrupts appear to point to the
same address. DEBUG will "hook" some of 'em when it starts (single-step
and breakpoint, at least?) - this may explain part of it(?).
At this point, I'm pretty much out of ideas, TK. Try your idea of just
replacing relevant keyboard vectors, if your determination holds up.
If/when you become able to transfer files to this machine, I might be
able to think of other ideas to try...
Best,
Frank
-- snip snip --
0000:0000 23 FF 00 F0 ; 0 division by zero
0000:0004 23 FF 00 F0 ; 1 single-step
0000:0008 5F F8 00 F0 ; 2 ???
0000:000C 23 FF 00 F0 ; 3 breakpoint
0000:0010 23 FF 00 F0 ; 4 overflow
0000:0014 54 FF 00 F0 ; 5 bounds check
0000:0018 23 FF 00 F0 ; 6 invalid opcode
0000:001C 23 FF 00 F0 ; 7 device not available
0000:0020 A5 FE 00 F0 ; 8 double fault
0000:0024 87 E9 00 F0 ; 9 keyboard (irq 1) handler!
0000:0028 23 FF 00 F0 ; A
0000:002C 23 FF 00 F0 ; B
0000:0030 23 FF 00 F0 ; C
0000:0034 23 FF 00 F0 ; D
0000:0038 57 EF 00 F0 ; E
0000:003C 23 FF 00 F0 ; F
0000:0040 65 F0 00 F0 ; 10 video bios functions
0000:0044 4D F8 00 F0 ; 11
0000:0048 41 F8 00 F0 ; 12
0000:004C 59 EC 00 F0 ; 13
0000:0050 39 E7 00 F0 ; 14
0000:0054 59 F8 00 F0 ; 15
0000:0058 2E E8 00 F0 ; 16 keyboard (BDA, not hardware?)
0000:005C D2 EF 00 F0 ; 17
0000:0060 00 00 00 F6 ; 18
0000:0064 F2 E6 00 F0 ; 19
0000:0068 6E FE 00 F0 ; 1A
0000:006C 34 4D 00 F6 ; 1B
0000:0070 44 57 00 F6 ; 1C
0000:0074 A4 F0 00 F0 ; 1D
0000:0078 C7 EF 00 F0 ; 1E
0000:007C 00 00 00 F0 ; 1F
0000:0080 00 00 00 00 ; 20 dos (terminate) interrupts start here
0000:0084 00 00 00 00 ; 21
0000:0088 00 00 00 00 ; 22
0000:008C 00 00 00 00 ; 23
0000:0090 00 00 00 00 ; 24
0000:0094 00 00 00 00 ; 25
0000:0098 00 00 00 00 ; 26
0000:009C 00 00 00 00 ; 27
0000:00A0 00 00 00 00 ; 28
0000:00A4 00 00 00 00 ; 29
0000:00A8 00 00 00 00 ; 2A
0000:00AC 00 00 00 00 ; 2B
0000:00B0 00 00 00 00 ; 2C
0000:00B4 00 00 00 00 ; 2D
0000:00B8 00 00 00 00 ; 2E
0000:00BC 00 00 00 00 ; 2F
0000:00C0 00 00 00 00 ; 30
0000:00C4 00 00 00 00 ; 31
0000:00C8 00 00 00 00 ; 32
0000:00CC 00 00 00 00 ; 33
0000:00D0 00 00 00 00 ; 34
0000:00D4 00 00 00 00 ; 35
0000:00D8 00 00 00 00 ; 36
0000:00DC 00 00 00 00 ; 37
0000:00E0 00 00 00 00 ; 38
0000:00E4 00 00 00 00 ; 39
0000:00E8 00 00 00 00 ; 3A
0000:00EC 00 00 00 00 ; 3B
0000:00F0 00 00 00 00 ; 3C
0000:00F4 00 00 00 00 ; 3D
0000:00F8 00 00 00 00 ; 3E
0000:00FC 00 00 00 00 ; 3F
0000:0100 00 00 00 00 ; 40
0000:0104 00 00 00 00 ; 41
0000:0108 00 00 00 00 ; 42
0000:010C 00 00 00 00 ; 43
0000:0110 00 00 00 00 ; 44
0000:0114 00 00 00 00 ; 45
0000:0118 00 00 00 00 ; 46
0000:011C 00 00 00 00 ; 47
0000:0120 00 00 00 00 ; 48
0000:0124 00 00 00 00 ; 49
0000:0128 00 00 00 00 ; 4A
0000:012C 00 00 00 00 ; 4B
0000:0130 00 00 00 00 ; 4C
0000:0134 00 00 00 00 ; 4D
0000:0138 00 00 00 00 ; 4E
0000:013C 00 00 00 00 ; 4F
0000:0140 00 00 00 00 ; 50
0000:0144 00 00 00 00 ; 51
0000:0148 00 00 00 00 ; 52
0000:014C 00 00 00 00 ; 53
0000:0150 00 00 00 00 ; 54
0000:0154 00 00 00 00 ; 55
0000:0158 00 00 00 00 ; 56
0000:015C 00 00 00 00 ; 57
0000:0160 00 00 00 00 ; 58
0000:0164 00 00 00 00 ; 59
0000:0168 00 00 00 00 ; 5A
0000:016C 00 00 00 00 ; 5B
0000:0170 00 00 00 00 ; 5C
0000:0174 00 00 00 00 ; 5D
0000:0178 00 00 00 00 ; 5E
0000:017C 00 00 00 00 ; 5F
0000:0180 00 00 00 00 ; 60
0000:0184 00 00 00 00 ; 61
0000:0188 00 00 00 00 ; 62
0000:018C 00 00 00 00 ; 63
0000:0190 00 00 00 00 ; 64
0000:0194 00 00 00 00 ; 65
0000:0198 00 00 00 00 ; 66
0000:019C 00 00 00 00 ; 67
0000:01A0 00 00 00 00 ; 68
0000:01A4 00 00 00 00 ; 69
0000:01A8 00 00 00 00 ; 6A
0000:01AC 00 00 00 00 ; 6B
0000:01B0 00 00 00 00 ; 6C
0000:01B4 00 00 00 00 ; 6D
0000:01B8 00 00 00 00 ; 6E
0000:01BC 00 00 00 00 ; 6F
0000:01C0 00 00 00 00 ; 70
0000:01C4 00 00 00 00 ; 71
0000:01C8 00 00 00 00 ; 72
0000:01CC 00 00 00 00 ; 73
0000:01D0 00 00 00 00 ; 74
0000:01D4 00 00 00 00 ; 75
0000:01D8 00 00 00 00 ; 76
0000:01DC 00 00 00 00 ; 77
0000:01E0 00 00 00 00 ; 78
0000:01E4 00 00 00 00 ; 79
0000:01E8 00 00 00 00 ; 7A
0000:01EC 00 00 00 00 ; 7B
0000:01F0 00 00 00 00 ; 7C
0000:01F4 00 00 00 00 ; 7D
0000:01F8 00 00 00 00 ; 7E
0000:01FC 00 00 00 00 ; 7F
0000:0200 00 00 00 00 ; 80
0000:0204 00 00 00 00 ; 81
0000:0208 00 00 00 00 ; 82
0000:020C 00 00 00 00 ; 83
0000:0210 00 00 00 00 ; 84
0000:0214 00 00 00 00 ; 85
0000:0218 94 4C 00 F6 ; 86
0000:021C 94 4C 00 F6 ; 87
0000:0220 94 4C 00 F6 ; 88
0000:0224 94 4C 00 F6 ; 89
0000:0228 94 4C 00 F6 ; 8A
0000:022C 94 4C 00 F6 ; 8B
0000:0230 94 4C 00 F6 ; 8C
0000:0234 94 4C 00 F6 ; 8D
0000:0238 94 4C 00 F6 ; 8E
0000:023C 94 4C 00 F6 ; 8F
0000:0240 94 4C 00 F6 ; 90
0000:0244 94 4C 00 F6 ; 91
0000:0248 94 4C 00 F6 ; 92
0000:024C 94 4C 00 F6 ; 93
0000:0250 94 4C 00 F6 ; 94
0000:0254 94 4C 00 F6 ; 95
0000:0258 94 4C 00 F6 ; 96
0000:025C 94 4C 00 F6 ; 97
0000:0260 94 4C 00 F6 ; 98
0000:0264 94 4C 00 F6 ; 99
0000:0268 94 4C 00 F6 ; 9A
0000:026C 94 4C 00 F6 ; 9B
0000:0270 94 4C 00 F6 ; 9C
0000:0274 94 4C 00 F6 ; 9D
0000:0278 94 4C 00 F6 ; 9E
0000:027C 94 4C 00 F6 ; 9F
0000:0280 94 4C 00 F6 ; A0
0000:0284 94 4C 00 F6 ; A1
0000:0288 94 4C 00 F6 ; A2
0000:028C 94 4C 00 F6 ; A3
0000:0290 94 4C 00 F6 ; A4
0000:0294 94 4C 00 F6 ; A5
0000:0298 94 4C 00 F6 ; A6
0000:029C 94 4C 00 F6 ; A7
0000:02A0 94 4C 00 F6 ; A8
0000:02A4 94 4C 00 F6 ; A9
0000:02A8 94 4C 00 F6 ; AA
0000:02AC 94 4C 00 F6 ; AB
0000:02B0 94 4C 00 F6 ; AC
0000:02B4 94 4C 00 F6 ; AD
0000:02B8 94 4C 00 F6 ; AE
0000:02BC 94 4C 00 F6 ; AF
0000:02C0 94 4C 00 F6 ; B0
0000:02C4 94 4C 00 F6 ; B1
0000:02C8 94 4C 00 F6 ; B2
0000:02CC 94 4C 00 F6 ; B3
0000:02D0 94 4C 00 F6 ; B4
0000:02D4 94 4C 00 F6 ; B5
0000:02D8 94 4C 00 F6 ; B6
0000:02DC 94 4C 00 F6 ; B7
0000:02E0 94 4C 00 F6 ; B8
0000:02E4 94 4C 00 F6 ; B9
0000:02E8 94 4C 00 F6 ; BA
0000:02EC 94 4C 00 F6 ; BB
0000:02F0 94 4C 00 F6 ; BC
0000:02F4 94 4C 00 F6 ; BD
0000:02F8 94 4C 00 F6 ; BE
0000:02FC 94 4C 00 F6 ; BF
0000:0300 94 4C 00 F6 ; C0
0000:0304 94 4C 00 F6 ; C1
0000:0308 94 4C 00 F6 ; C2
0000:030C 94 4C 00 F6 ; C3
0000:0310 94 4C 00 F6 ; C4
0000:0314 94 4C 00 F6 ; C5
0000:0318 94 4C 00 F6 ; C6
0000:031C 94 4C 00 F6 ; C7
0000:0320 94 4C 00 F6 ; C8
0000:0324 94 4C 00 F6 ; C9
0000:0328 94 4C 00 F6 ; CA
0000:032C 94 4C 00 F6 ; CB
0000:0330 94 4C 00 F6 ; CC
0000:0334 94 4C 00 F6 ; CD
0000:0338 94 4C 00 F6 ; CE
0000:033C 94 4C 00 F6 ; CF
0000:0340 94 4C 00 F6 ; D0
0000:0344 94 4C 00 F6 ; D1
0000:0348 94 4C 00 F6 ; D2
0000:034C 94 4C 00 F6 ; D3
0000:0350 94 4C 00 F6 ; D4
0000:0354 94 4C 00 F6 ; D5
0000:0358 94 4C 00 F6 ; D6
0000:035C 94 4C 00 F6 ; D7
0000:0360 94 4C 00 F6 ; D8
0000:0364 94 4C 00 F6 ; D9
0000:0368 94 4C 00 F6 ; DA
0000:036C 94 4C 00 F6 ; DB
0000:0370 94 4C 00 F6 ; DC
0000:0374 94 4C 00 F6 ; DD
0000:0378 94 4C 00 F6 ; DE
0000:037C 94 4C 00 F6 ; DF
0000:0380 94 4C 00 F6 ; E0
0000:0384 94 4C 00 F6 ; E1
0000:0388 94 4C 00 F6 ; E2
0000:038C 94 4C 00 F6 ; E3
0000:0390 94 4C 00 F6 ; E4
0000:0394 94 4C 00 F6 ; E5
0000:0398 94 4C 00 F6 ; E6
0000:039C 94 4C 00 F6 ; E7
0000:03A0 94 4C 00 F6 ; E8
0000:03A4 94 4C 00 F6 ; E9
0000:03A8 94 4C 00 F6 ; EA
0000:03AC 94 4C 00 F6 ; EB
0000:03B0 94 4C 00 F6 ; EC
0000:03B4 94 4C 00 F6 ; ED
0000:03B8 94 4C 00 F6 ; EE
0000:03BC 94 4C 00 F6 ; EF
0000:03C0 94 4C 00 F6 ; F0
0000:03C4 94 4C 00 F6 ; F1
0000:03C8 94 4C 00 F6 ; F2
0000:03CC 94 4C 00 F6 ; F3
0000:03D0 94 4C 00 F6 ; F4
0000:03D4 94 4C 00 F6 ; F5
0000:03D8 94 4C 00 F7 ; F6
0000:03DC 94 4C 00 F6 ; F7
0000:03E0 94 4C 00 F6 ; F9
0000:03E4 94 4C 00 F6 ; F9
0000:03E8 94 4C 00 F6 ; FA
0000:03EC 94 4C 00 F6 ; FB
0000:03F0 94 4C 00 F6 ; FC
0000:03F4 94 4C 00 F6 ; FD
0000:03F8 94 4C 00 F6 ; FE
0000:03FC 94 4C 00 F6 ; FF
-- snip snip --
TK
> In article <ig0iq5$kb...@speranza.aioe.org>
> do_not_h...@nospicedham.notreplytome.cmm "Rod Pemberton" writes:
>
>
>
>
>
>
>
>
>
> > "TK" <torbjo...@nospicedham.gmail.com> wrote in message
Thanks for the advice, guys. I agree with the sentiment that the first
thing I
should check is the table is written correctly so I had it written to
memory
location 16E1:0000..03ffh instead of 0000:0000..03ffh. That worked
fine.
I will first go through the actual IVT table again. I got it from ROM-
BASIC (by
booting without the harddrive), and doing a FOR loop with PEEK (I set
segment to 0000h first).
Regarding TSR trick, that would be cool :)
Btw regarding "I did a trace", yes that was with G and setting
breakpoints in DEBUG. Perhaps
not a great idea when one is overwriting the IVT table.
Regards,
TK
Rod Pemberton
[SNIP - two posts to clax only]
> Thanks for the advice, guys. I agree with the sentiment that the first
> thing I
> should check is the table is written correctly so I had it written to
> memory
> location 16E1:0000..03ffh instead of 0000:0000..03ffh. That worked
> fine.
[SNIP]
Ok, if you can or want, try the code below my .sig. Don't fault me for
doing all the stuff I said not to do. I "cut-n-pasted" from other code of
mine. It's a DOS .COM. It has the IVT values you posted. It's in NASM
assembly. If DEBUG is MASM format, you may need a DWORD PTR on
the memory references in brackets.
If you cannot use NASM, you could probably enter the code in DEBUG
and write to a file, but the vector table is tedious. Hopefully, you
already have
those values saved to a .bin. If so, to create one file you could use:
COPY/B asm.bin + ivt.bin ivt.com
You might get away with shortening the data. There are lots of zeroes.
IIRC, the upper IVT's aren't used by the BIOS. They also repeat values,
except one near the end which has an F7h instead of F6h... Typo? So, you
probably only need the first sixteen lines or so... That'll change bx's
value.
Rod Pemberton
PS Did anyone know that NASM erroneously compiles FS and GS overrides with
NASM's CPU 8086 directive?
BITS 16
CPU 8086
ORG 0x0100
SECTION .text
; NASM -f bin -o ivt_load.com ivt_load.asm
start:
cli
push cs
pop ds
xor ax,ax
mov es,ax
mov bx,4*256
sub bx,2
mov si,biosvect
mvit:
mov ax,[si+bx]
mov [es:bx],ax
sub bx,2
jnz mvit
mov ax,[si+bx]
mov [es:bx],ax
sti
int 18h
biosvect:
db 023h,0FFh,000h,0F0h,023h,0FFh,000h,0F0h
db 05Fh,0F8h,000h,0F0h,023h,0FFh,000h,0F0h
db 023h,0FFh,000h,0F0h,054h,0FFh,000h,0F0h
db 023h,0FFh,000h,0F0h,023h,0FFh,000h,0F0h
db 0A5h,0FEh,000h,0F0h,087h,0E9h,000h,0F0h
db 023h,0FFh,000h,0F0h,023h,0FFh,000h,0F0h
db 023h,0FFh,000h,0F0h,023h,0FFh,000h,0F0h
db 057h,0EFh,000h,0F0h,023h,0FFh,000h,0F0h
db 065h,0F0h,000h,0F0h,04Dh,0F8h,000h,0F0h
db 041h,0F8h,000h,0F0h,059h,0ECh,000h,0F0h
db 039h,0E7h,000h,0F0h,059h,0F8h,000h,0F0h
db 02Eh,0E8h,000h,0F0h,0D2h,0EFh,000h,0F0h
db 000h,000h,000h,0F6h,0F2h,0E6h,000h,0F0h
db 06Eh,0FEh,000h,0F0h,034h,04Dh,000h,0F6h
db 044h,057h,000h,0F6h,0A4h,0F0h,000h,0F0h
db 0C7h,0EFh,000h,0F0h,000h,000h,000h,0F0h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 000h,000h,000h,000h,000h,000h,000h,000h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F7h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
db 094h,04Ch,000h,0F6h,094h,04Ch,000h,0F6h
TK
<do_not_h...@nospicedham.notreplytome.cmm> wrote:
> "TK" <torbjo...@nospicedham.gmail.com> wrote in message
>
> news:c1adbb86-4b76-4b97...@i18g2000yqn.googlegroups.com...
> [SNIP - two posts to clax only]
>
> CPU 8086
> ORG 0x0100
> SECTION .text
>
> ; NASM -f bin -o ivt_load.com ivt_load.asm
>
> start:
> cli
> push cs
> pop ds
>
> xor ax,ax
> mov es,ax
>
> mov bx,4*256
> sub bx,2
> mov si,biosvect
> mvit:
> mov ax,[si+bx]
> mov [es:bx],ax
> sub bx,2
> jnz mvit
> mov ax,[si+bx]
> mov [es:bx],ax
>
> sti
> int 18h
>
Thanks for the example. However I think the previous code worked fine
as far as copying
memory from one location to another, since I had already tested that
by copying all the 1024
bytes of my IVT table to 16E1:0000 (a random location I chose, so I
could easily verify with
DEBUG whether the bytes were actually copied to that location).
I wanted to try your code in any case though, but I got stuck with [si
+bx] and [es:bx]
which did not work in DEBUG. I am not entirely sure how to specify
the segment,
which is why I previously (and probably errneously) changed the DS to
be 0000 instead
of using ES. I am using the MOVSB instruction because it already
copies from [DS:SI] to [ES:DI],
and then all I need to do is set SI, ES and DI as per Frank's
suggestion.
[Note: I did take your advice on skipping the IVT table from where the
zeroes begin, so I'm only copying
the beginning of the IVT.]
Now on to the good news!
I now got it to work, "sort of". By sort of, I mean, it works great
once in a while. I run
the TOBASIC.COM file I created and about 70% of the time it freezes
the computer, yet 30% of the
time it enters IBM ROM BASIC 1.1, this time *with* keyboard access! So
in my view, it works well enough for now!
I'm not too annoyed with the fact that it only works 30% of the time I
try it, although perhaps
you guys have some ideas as to why?
an...@nospicedham.att.net
>Hello gents,
>
>I have an IBM XT computer with an Intel 8088 CPU, the computer has
>576kB of memory and thus cannot really compete with my Mac Mini.
>Regardless, I've played around with it a bit during Xmas vacation as
>I've had some time to spare. If I remove the harddrive, it boots
>directly into IBM Basic.
>
>The computer normally runs MS-DOS 4 as it is installed on the 10MB
>harddrive. I wrote a quick program using DEBUG, in order to drop into
>BASIC mode again. The interrupt in question should be 18h.
>
>I run the simple instruction:
>INT 18 -- This triggers BASIC mode immediately
>
>So, it triggers BASIC mode, and all looks "fine". However, the
>keyboard is not functional. I can't type anything. Is DOS still in
>control of the keyboard, perhaps, or may something else be wrong?
The problem is the "INT 18h" vector is for ROM BASIC. Some early pre
MS-DOS 3.3 did load Basic but after 3.3, all Basics started using the
Disk I/O drivers instead of the ROM INT vectors which is required buy
INT 18.
Rod Pemberton
> I now got it to work, "sort of". By sort of, I mean, it works great
> once in a while. I run the TOBASIC.COM file I created and about
> 70% of the time it freezes the computer, yet 30% of the
> time it enters IBM ROM BASIC 1.1, this time *with* keyboard
> access! So in my view, it works well enough for now!
>
That's great!
> I'm not too annoyed with the fact that it only works 30% of the
> time I try it, although perhaps you guys have some ideas as to why?
>
Just these: NMI disable/enable, EOI clear, or PIC reprogram ...
1) NMI
This is probably the easiest to test. Drop them in. They work or they
don't. Place the NMI disable after CLI and NMI enable prior to STI.
NMI can be disabled or enabled by setting bit 7 of port 0x70. That's the
0x80 of 0x8D. If you disable/enable NMI's, you need to set a register also.
That's 0x0D of 0x8D for the safe register. 0x0D is the RTC status register.
; disable NMI
mov al,8Dh
out 70h,al
in al,71h
; enable NMI
mov al,0Dh
out 70h,al
in al,71h
Those should work, but you can also look at the A.O.D. FAQ. Unfortunately,
the simple routines it had, aren't simple anymore...
http://aodfaq.wikispaces.com/boot#How do I disable NMI on a PC?
That entire line *with* spaces is the link...
(James? Could you remove the spaces? Please!)
There are a number of intracies in using the RTC and NMI, such as needing to
read or write to a port after setting the CMOS location to read or write
from.
E.g., this describes Intel's method for using the RTC and NMI with their
motherboards' southbridges which has more intracacies:
http://download.intel.com/design/intarch/papers/321088.pdf
2) EOI
This is probably the next easiest.
It's possible an uncleared EOI is blocking interrupts.
To do this correctly, you have to read the PIC ISR register to determine if
an interrupt needs to be cleared.
(I converted from C. I hope these are correct. I kept switching the port
and data. Someone might check the routines above also.)
mov al,0Bh
out 20h,al
in al, 20h
The bits in AL represent IRQ's 0 to 7. If set, it needs an EOI.
mov al,0Bh
out 0A0h,al
in al, 0A0h
The bits in AL represent IRQ's 8 to 15. If set, it needs an EOI.
Once you know if interrupts need clearing, you can send a either a generic
or specific EOI to clear the IRQ(s) in question. Or, or it may be easier to
just "shotgun" them, i.e., try both a generic low and high EOI clear, maybe
separately, then together...
generic EOI for low IRQ's (0 to 7)
mov al,20h
out 20h,al
generic EOI for high IRQ's (8 to 15)
mov al,20h
out 0A0h,al
out 20h,al
specific EOI for low IRQ's (0 to 7)
mov al,60h+IRQ
out 20h,al
e.g., 60h+IRQ for IRQ3 is 60h+3 = 63h...
specific EOI for high IRQ's (8 to 15)
mov al,60h+IRQ
out 0A0h,al
mov al,62h
out 20h,al
3) PIC's
The sequence is a bit longer to reprogram the PIC's.
It's possible DOS reprogrammed the PIC's so they don't match the BIOS' setup
of them. But, I sort of doubt it... We can tell you how to program them,
or I can post links to the sequence (e.g., for a.o.d.). You have to program
4 or 5 registers. But, if this is the issue, I'm not sure at the moment how
to determine their default state in order to reset them. I'm guessing you'd
need to write a bootsector to read the PIC's default setup, i.e., before DOS
gets to it. Then, you could drop those values into the reprogramming
routine.
HTH,
Rod Pemberton
Bob Masta
<do_no...@nospicedham.notreplytome.cmm> wrote:
>"TK" <torb...@nospicedham.gmail.com> wrote in message
>news:58ab0933-3eb0-47aa...@z19g2000yqb.googlegroups.com...
>> I now got it to work, "sort of". By sort of, I mean, it works great
>> once in a while. I run the TOBASIC.COM file I created and about
>> 70% of the time it freezes the computer, yet 30% of the
>> time it enters IBM ROM BASIC 1.1, this time *with* keyboard
>> access! So in my view, it works well enough for now!
>>
>
>That's great!
>
>> I'm not too annoyed with the fact that it only works 30% of the
>> time I try it, although perhaps you guys have some ideas as to why?
>>
>
>Just these: NMI disable/enable, EOI clear, or PIC reprogram ...
>
>1) NMI
>This is probably the easiest to test. Drop them in. They work or they
>don't. Place the NMI disable after CLI and NMI enable prior to STI.
>
>NMI can be disabled or enabled by setting bit 7 of port 0x70. That's the
>0x80 of 0x8D. If you disable/enable NMI's, you need to set a register also.
>That's 0x0D of 0x8D for the safe register. 0x0D is the RTC status register.
The OP stated that he has an XT machine. NMI was on port
A0h on those systems, which didn't have an RTC chip. The
RTC (and port 70h for NMI) came along with the AT and PS/2.
Note that the XT NMI enable/disable at A0h works *opposite*
to the AT at 70h. It still uses bit 7 of the port, but in
the opposite sense. To disable XT, clear bit 7 at A0h:
MOV AL,0
OUT 0A0h,AL
To re-enable later, set bit 7:
MOV AL,80h
OUT 0A0h,AL
(Unlike the RTC-based NMI mask on AT and later, the XT port
at A0h does not need to set any Status register.)
Best regards,
Rod Pemberton
news:4d25c60...@news.eternal-september.org...
> >1) NMI
> >This is probably the easiest to test. Drop them in. They work or they
> >don't. Place the NMI disable after CLI and NMI enable prior to STI.
> >
> >NMI can be disabled or enabled by setting bit 7 of port 0x70. That's the
> >0x80 of 0x8D. If you disable/enable NMI's, you need to set a register
also.
> >That's 0x0D of 0x8D for the safe register. 0x0D is the RTC status
register.
>
> The OP stated that he has an XT machine. NMI was on port
> A0h on those systems, which didn't have an RTC chip. The
> RTC (and port 70h for NMI) came along with the AT and PS/2.
>
> Note that the XT NMI enable/disable at A0h works *opposite*
> to the AT at 70h. It still uses bit 7 of the port, but in
> the opposite sense. To disable XT, clear bit 7 at A0h:
> MOV AL,0
> OUT 0A0h,AL
> To re-enable later, set bit 7:
> MOV AL,80h
> OUT 0A0h,AL
>
> (Unlike the RTC-based NMI mask on AT and later, the XT port
> at A0h does not need to set any Status register.)
>
Sorry. Is the rest OK for XT? IIRC, it only has one interrupt controller
... ?
RP
Nathan
<do_not_h...@nospicedham.notreplytome.cmm> wrote:
>
> Those should work, but you can also look at the A.O.D. FAQ. Unfortunately,
>
> That entire line *with* spaces is the link...
> (James? Could you remove the spaces? Please!)
>
Spaces are urlencoded as "%20" when used as a link. Apparently, your
newsreader did not preserve the "%20"s during the copy-n-paste.
http://aodfaq.wikispaces.com/boot#How%20do%20I%20disable%20NMI%20on%20a%20PC?
Nathan.
Bob Masta
<do_no...@nospicedham.notreplytome.cmm> wrote:
>
>Sorry. Is the rest OK for XT? IIRC, it only has one interrupt controller
Oops, I missed that! Yep, XT has only IRQs 0-7, so only the
low EOI is needed, as you showed.
I don't know if DOS changed the PIC, but I don't think so.
However, I vaguely recall that BASIC ran the system timer 4
times as fast, then corrected the time-of-day to compensate.
I don't know if that was ROM BASIC or only GW BASIC. Not
sure if that would account for the OPs problem, though.
Rugxulo
This thread is a little unwieldy to me, so sorry if my responses
are all lumped into one message (and cross-posted, ugh). Hopefully
something mentioned here helps (indirectly).
On Jan 2, 6:36 am, TK <torb...@nospicedham.gmail.com> wrote:
>
> Hmm, thanks for the tip. Now if could only hook a 5.25" disk drive
> onto a modern "PC" so I could copy the files over.
IBM XT 8088, 576 kb RAM, MS-DOS 4 on 10 MB hard drive, trying to run
ROM BASIC.
As mentioned, you should try running BASICA inside DOS and see if that
works. (It's before my time so who knows, but apparently that was
before GW-BASIC, which eliminated the need for ROM support. QBASIC
first came in MS-DOS 5, but I think later PC-DOS versions (7?) dropped
it for REXX. Modern Windows does not have it anymore, oddly, but their
FTP probably still has it, though I dunno what the legal terms are, so
it 's probably not worth guessing.) [1]
You mentioned that it ran when you removed the HD, so you could always
(easier) use a boot manager (e.g. BOOTMGR, 8086-friendly) to
deactivate the partition at will instead. [2]
Some of us (e.g. me) have some spare 5.25" drives lying around unused,
but (pardon the silly assumption) your name implies you probably live
far, far, FAR away from me. Still, worst case scenario, assuming
nobody locally has one, then one of us could mail you one (and hope it
doesn't break in transit). I (think? I) still have a working 5.25"
drive installed, but I haven't used it in a while. But sending you a
floppy is probably more risky than the actual hardware!!!
Speaking of that, you have other free OSes available (FreeDOS, Minix
2.02, ELKS), but I'm not sure what you're trying to accomplish (just
play around for fun? explicitly write some BASIC code??).
I was even going to suggest BASM286, since I couldn't think of another
(free) BASIC, but apparently it does live up to its name (and not
optionally) using 286+ code, which isn't helpful here. Try looking at
Ron's Chipmunk BASIC site, it has hundreds of links to various
interpreters. The original Chipmunk BASIC was written in Pascal (and
included as example in P2C), public domain. IIRC, that translator is
fairly agnostic, doesn't assume 32-bit word size, so you may be able
to compile for your 8088. (It's probably not TP55 friendly with a few
tweaks, but at least TP55 is [barely] freeware and can handle 16-bit
cpus. TC 2.0 or TC++ 1.01 probably compiles the C output, I hope.)
Honestly not sure if it's any better than BWBASIC, though. [3][4][5]
[6]
DEBUG is still included in modern 32-bit Windows (even Vista, 7 too
probably). It's the MS-DOS 5 version verbatim. A quick search doesn't
show any exhaustive references, but IIRC (and just tested on XP, it
works), you enter the segment prefix as a separate instruction and
it'll work. FD Debug is better, IMHO, but yours is probably good
enough (barring an easy way to upgrade). [7][8]
A 100
ES:
MOVSB
Q
You want 8088/8086 help? They're probably too busy, but at least two
guys online seem to still tinker with those things (Mike @ Rubber
Mallet, Jim @ Old Skool), (in)famous for Wolf3D 8086 (and leetIRC) and
8088 Corruption (and Monotone), respectively, among other things. Also
anybody else (sadly, not me) who still uses an Atari Portfolio,
PoqetPC, or PocketDOS emulation probably has a clue. Oops, almost
forgot, Mike Brutman (mTCP) might be interested too, who knows. [9][10]
[11]
BTTR also has DIVT to display the IVT. IIRC, Arjay (other dude who
frequents the forum)'s IVTUTIL has some similar capabilities, but
apparently the download is broken. (I don't seem to have a copy
locally here, but maybe on my other computer. Or you could just email
him.) [12][13]
But I wouldn't really use DEBUG for real work, it's too clunky. "Old"
NASM 0.98.39 had a 16-bit build (later unsupported for 2.xx series),
so you could try that. [14]
File Maven (now freeware) says it supports PC transfer via serial or
parallel ports. It supports MS-DOS 3.0, so hopefully that means 8088
also. [15]
Okay, that appears the be all I had to say. Sorry if it was too long
or whatever!
http://en.wikipedia.org/wiki/IBM_BASICA
http://www.bttr-software.de/products/bootmgr/
http://www.nicholson.com/rhn/basic/
http://edn.embarcadero.com/article/20803
http://djgpp.cybermirror.org/current/v2gnu/p2c120s.zip
http://sourceforge.net/projects/bwbasic/
http://en.wikipedia.org/wiki/Debug_(command)
http://www.japheth.de/debxxf.html
http://www.rubbermallet.org/
http://www.oldskool.org/
http://www.brutman.com/
http://www.bttr-software.de/products/divt/
http://www.wimborne.org/richard/projects/ivtutil/
http://sourceforge.net/projects/nasm/files/DOS%2016-bit%20binaries%20(OBSOLETE)/0.98.39/nsm09839.zip/download
http://www.briggsoft.com/fmdos.htm
James Harris
> On Jan 6, 5:25 am, "Rod Pemberton"
> <do_not_h...@nospicedham.notreplytome.cmm> wrote:
>
> > Those should work, but you can also look at the A.O.D. FAQ. Unfortunately,
> > the simple routines it had, aren't simple anymore...
>
>
> > That entire line *with* spaces is the link...
> > (James? Could you remove the spaces? Please!)
>
> Spaces are urlencoded as "%20" when used as a link. Apparently, your
> newsreader did not preserve the "%20"s during the copy-n-paste.
>
I don't know which newsreader Rod is using but for browsers it seems
that IE, after being told Copy Shortcut, leaves spaces as spaces but
then doesn't follow the link it has created if that link is pasted
somewhere. Firefox is more consistent in that Copy Link Location
generates the %20s as in
http://aodfaq.wikispaces.com/boot#How%20do%20I%20disable%20NMI%20on%20a%20PC?
and Firefox will follow this. There is no change in either behaviour
if the URL is copied from the Location bar.
Rod, I can't take out the spaces without affecting the question as the
spaces are part of the question text. Maybe the best thing if you want
to post a link in future is to link not to the question but to the
page containing the question. In the above instance it would mean
posting the link
http://aodfaq.wikispaces.com/boot
and leaving the reader to look for the question text. All the
questions appear on the right hand side at the top of the page so they
are easy enough for someone reading to find.
There was one page name that had a space in it: "where next" which
I've seen appear as where+next in that a plus sign replaced the space.
To avoid confusion I've changed that so that there are no spaces in
any page names. I don't recall seeing any links out there to the old
name and if there any such old links it shouldn't be too confusing for
someone following one to find the right page. The new link for that
page is
http://aodfaq.wikispaces.com/next
James
Rod Pemberton
news:f3806df8-6112-435d...@fx12g2000vbb.googlegroups.com...
>
> Spaces are urlencoded as "%20" when used as a link. Apparently, your
> newsreader did not preserve the "%20"s during the copy-n-paste.
>
The browser didn't or doesn't. The newsreader only recognizes the
non-spaced portion as a link when pasted.
> I don't know which newsreader Rod is using
Newsreader is MS OE 6.
> but for browsers
I've been using Opera 10.63.
> it seems
> that IE, after being told Copy Shortcut, leaves spaces as spaces but
> then doesn't follow the link it has created if that link is pasted
> somewhere. Firefox is more consistent in that Copy Link Location
> generates the %20s as in [link]
> and Firefox will follow this. There is no change in either behaviour
> if the URL is copied from the Location bar.
>
MS OE 6 only recognizes the non-space portion as a link. It doesn't convert
the spaces. IE6 shows spaces in address bar, but converts when copied. FF
3.5.16 converts in browser address bar. FF 3.6.13 probably does the same.
Opera 10.63 is not converting anywhere. Maybe something is turned off... ?
Opera 11.00 doesn't work well with this OS and extender.
> Rod, I can't take out the spaces without affecting the question
> as the spaces are part of the question text.
>
"Widget" for Table of Contents... It's auto-generated I take it.
Sorry, I thought it was an easy issue since I saw Wikipedia using
underscores. Or, maybe they convert the underscored links...
Rod Pemberton
TK
to connect the XT to the rest of the world. That is, being able to
transfer files across - be it via the serial port or via floppy
disks. Right now the XT is just stranded, and the only thing I have
is DEBUG.COM.
The XT is at my family's old home and I happen to live on a different
continent, so I only had a chance to play with the XT during Xmas
vacation. It brought back many good memories, and I think the
challenge of invoking ROM BASIC mode was a fun one. I certainly
learned a lot, and I highly appreciated the help from the very smart
(and friendly) fellows on comp.lang.asm.x86!
Next vacation I'll try to find a way to copy files back and forth, and
install a decent assembler.
Thanks guys
PS Rod: I tried NMI and I also tried a generic EOI clear on lower
interrupts (0-7), but it did not work. I had to leave shortly after.
For now, it's OK that it works only 25% of the time. Doing a CTRL-ALT-
DEL and then executing the program again is quick enough. I'll have
to investigate further at a later stage.
Rod Pemberton
> Next vacation I'll try to find a way to copy files back and forth, and
> install a decent assembler.
>
It's probably OT for the two comp.* groups. But, ...
I'm not too sure what worked on XT class computers, but on AT class you
could transfer data via a few basic methods: floppy, RS-232C serial port,
parallel port, modem (using RS-232C), or ethernet card. If you've got an
RS-232C serial port, then you can construct a RS-232C serial null-modem
crossover cable. There should be a bunch of descriptions for this on the
'net. If you have to convert logic levels, it'll require some simple
electronics: an IC or a relay, transistor, zener diode etc. Alternately,
you can send data from modem to modem (telephone) using a standard 4-pin
RJ11/RJ14 phone cord. Years ago, you could use programs like Pro-COMM,
Kermit or C-Kermit, SZ/RZ, X/Y/Z-modem, KA9Q to transfer data via the serial
port or modem... C-Kermit, SZ/RZ and KA9Q should still be around. Parallel
port required software that wasn't as commonly available as for the serial
port and a parallel port cable required more wires. Lots of stuff was
written for the serial ports since modems connected to it. Using ethernet,
AIUI, requires DOS ethernet drivers written for that specific card (i.e.,
obsolete today...) and a packet interface driver. I found the RS-232C
method to be the easiest and think it probably still is, but you'll need to
locate a modem for it, i.e., works with 8-bit/16-bit XT ISA bus (obsolete
interface).
> PS Rod: I tried NMI and I also tried a generic EOI clear on lower
> interrupts (0-7), but it did not work. I had to leave shortly after.
> For now, it's OK that it works only 25% of the time. Doing a CTRL-ALT-
> DEL and then executing the program again is quick enough. I'll have
> to investigate further at a later stage.
>
Darn... Sorry to hear that.
Rod Pemberton
Jim Leonard
> I agree with several of the recent replies, that I should find a way
> to connect the XT to the rest of the world. That is, being able to
> transfer files across - be it via the serial port or via floppy
> disks. Right now the XT is just stranded, and the only thing I have
> is DEBUG.COM.
Laplink, FastLynx, and even MS-DOS 5's interlnk/intersvr have
"bootstrap" modes where they tell you to type a MODE command on the
target machine which redirects serial to console input, then they use
that to transfer over a small program that has enough smarts to
transfer over the complete program.
One of my back-burner projects is an ADTPro (http://en.wikipedia.org/
wiki/ADTPro) -style transfer program for XTs for which you want to get
data off/onto the hard disk but have no floppy drive hardware.
Nothing concrete yet.
Bob Masta
<torb...@nospicedham.gmail.com> wrote:
>I agree with several of the recent replies, that I should find a way
>to connect the XT to the rest of the world. That is, being able to
>transfer files across - be it via the serial port or via floppy
>disks. Right now the XT is just stranded, and the only thing I have
>is DEBUG.COM.
PC Magazine used to offer nifty utilities in every issue.
One called ZCOPY was used with a "null modem" cable to
transfer files using the standard serial port. It was
written in 1989 by Bob Flanders and the EXE is about 4K in
size. I used to use it a lot... worked great!
A quick Google search for ZCOPY turns up DVD protection
cracks... not what you want here! However,
<www.epie.org/k12/PCMAGUTL.HTM> talks about the correct
ZCOPY and mentions source code, and strategies to obtain it.
(I haven't pursued these myself.)
Terje Mathisen
> On Sun, 16 Jan 2011 02:16:05 -0800 (PST), TK
> <torb...@nospicedham.gmail.com> wrote:
>
>> I agree with several of the recent replies, that I should find a way
>> to connect the XT to the rest of the world. That is, being able to
>> transfer files across - be it via the serial port or via floppy
>> disks. Right now the XT is just stranded, and the only thing I have
>> is DEBUG.COM.
>
> PC Magazine used to offer nifty utilities in every issue.
> One called ZCOPY was used with a "null modem" cable to
> transfer files using the standard serial port. It was
> written in 1989 by Bob Flanders and the EXE is about 4K in
> size. I used to use it a lot... worked great!
I don't remember the name now, but I used to have a serial/parallel
transfer program that worked over both RS232 and Centronics parallel ports.
You could bootstrap this program onto a second computer using nothing
but a simple redirect of the CONsole port to COM1:
The startup code would use this connection to start DEBUG and type hex
bytes into it, then run the resulting program (from memory).
This small bootstrap program was then capable of copying over the real
executable, at which point you were good to go.
Could it have been called something like LapLink?
....
Yes, that's it, I might even still have a cable or two. :-)
BTW, I have written a program which can take any binary and convert it
into a (MIME-encoded) executable text file, email me directly if you
need this to bootstrap something onto your standalone computer!
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
Jim Leonard
> PC Magazine used to offer nifty utilities in every issue.
> One called ZCOPY was used with a "null modem" cable to
> transfer files using the standard serial port. It was
> written in 1989 by Bob Flanders and the EXE is about 4K in
> size. I used to use it a lot... worked great!
Agreed, but one of the situations I wanted to address with my project
was how to bootstrap the process when your favorite utilities are not
there. If you have MODE.COM, laplink/fastlynx/etc. have you covered,
but if you don't... that's what I was tackling. Utilizing DEBUG or
BASIC to enter in the bootstrap code, for example.
The first thing I'd probably tackle is how to get data off of an old
drive when you have nothing -- just a DOS prompt, keyboard, and a
display. My initial idea is to write a size-optimized uuencode .com
file that will pause every 25 lines so that you can take pictures of
the screen, then can re-assemble after running the screenshots through
some rudimentary OCR and then uudecode. This .com would be run
through one of those com-to-ascii converters so that a user could COPY
CON filename.com to enter the progam in. Anyway, lots of ideas and
not enough time, as usual. Maybe even emulating a cassette port using
a sound blaster...
To bring this back on topic for comp.lang.asm.x86, what is the most
recent state-of-the-art .com to all-printable-characters-.com utility
out there?
Terje Mathisen
> To bring this back on topic for comp.lang.asm.x86, what is the most
> recent state-of-the-art .com to all-printable-characters-.com utility
> out there?
It is probably still the one I wrote during Easter 1995:
Absolute minimum possible self-modification ( a single 2-byte backwards
branch).
Self-relocating (survives reformatting/reflowing of the ascii text)
Very short initial bootstrap (2 x 64-byte lines of text), leading into a
secondary bootstrap (of 5-7 lines?) which contains the tiny MIME Base-64
decoder and the logic to either execute in place or save to disk the
embedded binary.
Both bootstrap levels are limited to using the ~72 different 7-bit ascii
chars that the MIME standards say will survive all email gateways,
including a trip onto an IBM mainframe (EBCDIC), a change to a different
national language encoding, and then back to ASCII.
If pure MIME compatibility isn't critical, then it also has a base-91
encoder which stores 6.5 bits/char instead of the 6 bits/byte of Base-64.
Terje
PS. I wrote this (specifically the first stage boot code) while on a xc
skiing vacation, with no computer, just a printout of the hex encodings
of the various opcodes I could use. I later wrote a small program to
search for/verify that a specific combination of operations could
generate any given byte value from two input chars in the MIME set.
I ended up with RESULT = A - B - B, since I could not use any of the
normal shift instructions.
Rod Pemberton
news:fc05676f-67e6-4901...@l22g2000vbp.googlegroups.com...
>
> To bring this back on topic for comp.lang.asm.x86, what is the most
> recent state-of-the-art .com to all-printable-characters-.com utility
> out there?
>
Haven't you been reading the other recent posts on clax? No...
Only four days ago, Frank described Herbert's converter for Nicole:
http://groups.google.com/group/comp.lang.asm.x86/msg/1d85d778e2c2ee24
This is an example of HK's text .bat to binary converter:
http://groups.google.com/group/comp.lang.asm.x86/msg/49e106208c1a99be
HK posted the "source" to create files like that here:
http://groups.google.com/group/comp.os.msdos.programmer/msg/1435527f103630dd
HK's complete package to convert is called ube.zip. ube.zip also includes
his assembly source, which compiles with his assembler. It's called
ass486.zip. Both are here:
http://www.bitlib.de/pub/assembler/
ube.zip
ass486.zip
Rod Pemberton
Jim Leonard
tmsw.no"@giganews.com> wrote:
> PS. I wrote this (specifically the first stage boot code) while on a xc
> skiing vacation, with no computer, just a printout of the hex encodings
One wonders how much of the vacation's enjoyment came from skiing and
how much from coding!
But seriously, your bad-assery continues to amaze me. And thanks
again for the util.
Jim Leonard
<do_not_h...@nospicedham.notreplytome.cmm> wrote:
> Haven't you been reading the other recent posts on clax? No...
Actually, no! I just started reading usenet again after an 18-month
period about 3 days ago. So, thank you for the recaps, they are
exactly what I was looking for and will make for great reading!
Terje Mathisen
You're welcome.
I'm just happy that someone can still find it useful, I do consider it
as one of my all-time best hacks.
Terje