IBM AT - BASIC code to set up CMOS/RTC

[modem7]

Every so often we see a person-in-need posting that they have an IBM AT that has lost it's settings (seeing a '161 - System Options not set' error), jumping into BASIC, and the person-in-need is seeking how to remedy the situation.

The remedy involves the person-in-need obtaining a suitable boot disk that has something on it that can appropriately set the CMOS/RTC chip, e.g. IBM Diagnostics Disk for AT, boot disk with GSETUP.

Only recently did I gain the knowledge on how the IBM Diagnostics Disk and the various generic setup utilities (such as GSETUP) program the CMOS/RTC chip, and accordingly I've started to offer the provision of BASIC code to persons-in-need so that they have the option of performing 'system setup' via BASIC.

But, I don't want to be the only one who can offer BASIC code, and so I've developed something to give you other 'helpers' out there the ability to offer BASIC code to persons-in-need. It's a Windows app that can be thought of as a variant of GSETUP, one that runs under Windows 2000/XP (and probably Vista) and generates BASIC code.

You can download it from: http://members.dodo.com.au/~slappanel555/software/GSETUP_BASIC.zip

As you can see in the above screen shot, the person-in-need will have to inform you of the hardware configuration of their IBM AT.
BIOS version, base memory and expansion memory can be difficult for some persons-in-need to determine, but luckily, those three items can be determined by you getting the person-in-need to run some BASIC code:

Determining BIOS version

10 def seg = &hf000
20 for i = 0 to 7
30 print chr$(peek(&hfff5 + i));
40 next
run

Determining Amount of Base Memory

The POST in the AT records the amount of base memory (in KB) that it finds.

def seg = &h40
print peek(20)*256 + peek(19)

NOTE: When run on an IBM PC (5150), I see it only reporting the motherboard component of base memory.

Determining Amount of Expansion Memory

Expansion, not Expanded.
The POST in the AT records the amount of expansion memory (in KB) that it finds.

out 112,48
low = inp(113)
out 112,49
high = inp(113)
print high*256 + low

 

[strollin]

Very slick! Thanks modem7. One small suggested improvement would be to be able to have the generated Basic code outputted to a file. It's very easy to cut and paste but it still would be nice to be able to generate the code directly to a file called gsetup.bas or something similar.

The detail you put into the Help buttons is great, such as the listing of hard drive types. Seems very thorough to me.

 

[mikey99]

Nice job

Can the generated basic code be run from 'cassette basic' ? That would be great as it would totally eliminate needing a bootable 5.25. This will certainly make answering all these requests for AT diag diskettes easier

 

[modem7]

Can the generated basic code be run from 'cassette basic' ? That would be great as it would totally eliminate needing a bootable 5.25. This will certainly make answering all these requests for AT diag diskettes easier

I use the term 'resident' BASIC.

Yes, that is the intention. The person-in-need has an IBM AT that can only get to 'resident' BASIC. We generate the code, pass to the person-in-need, and the person-in-need types it into the BASIC (minus the REM lines) then reboots the computer.
At that point the person-in-need will have an IBM AT that is booting and not displaying any error messages, but the date/time will be incorrect. They fix that by using DOS' DATE and TIME commands.

BASIC code is an option, and I think it should be offered as such, one of a few options. For example. A person-in-need might have an IBM Diagnostic Disk and is unaware of its purpose. Present the options and let the person-in-need decide.

Note that the generated BASIC code has no line numbers - not needed.

One small suggested improvement would be to be able to have the generated Basic code outputted to a file. It's very easy to cut and paste but it still would be nice to be able to generate the code directly to a file called gsetup.bas or something similar.

I did think about that, but decided against it on the reasoning that 'helpers' will be running my program on the same computer that they use to access the forums. Therefore, the standard operation is a cut from my program then paste into a post to be sent to the person-in-need.

 

[modem7]

Version 1.1

Version 1.1

The detail you put into the Help buttons is great, such as the listing of hard drive types.

I goofed.
In the Help screen for Hard Drives, I had too many drive types listed.
Next time, I'll make sure I don't let the caffeine level in my blood drop too low.
Get your free upgrade to version 1.1 at the link shown in my first post.

 

[Terry Yager]

Next time, I'll make sure I don't let the caffeine level in my blood drop too low.

Three yellow, two green...

--T

 

[modem7]

Three yellow, two green...

No, no, no. You're trying to confuse me. It's 5 yellow pills, 2 green pills.
I've just had both my psychiatrists confirm it for me.

 

[dongfeng]

That's brilliant. Thanks for taking the time to make this!

 

[snq]

I have no use for this atm, but just wanted to say great effort! I know I could've used something like this when I had the basic problem with my PS/2 a while ago.

If you want to expand the tool and include other models than the 5170, I'll be happy to help with whatever I can do. I assume you have been disassembling/debugging setup tools in order to get the correct addresses and values?

 

[modem7]

I assume you have been disassembling/debugging setup tools in order to get the correct addresses and values?

No.

1. Book: IBM Technical Reference AT (the BIOS listing and RTC/CMOS sections)
2. Book: System BIOS for IBM PC/XT/AT Computers and Compatibles - by Phoenix

All that one needs should be in IBM's Technical Reference. I have only the first edition Technical Reference for the AT, and so I needed to look in the other book to discover how later BIOS versions handled drive types over 15.
And without an IBM AT to test the code on, I would not have picked up some errors in my code.

If you want to expand the tool and include other models than the 5170, I'll be happy to help with whatever I can do.

As it is, my program is suitable for any computer which can use the IBM AT Diagnostics disk, or a generic setup utility such as GSETUP. Certain early clones of the IBM AT will be in that camp, and I'm sure that the IBM XT 286 (5162) will be there as well. I wonder if the PS/2 model 30 286 (AT class - first PS/2 with 16 bit ISA) is there too.

As you've alluded to, I'm sure other PS/2 models (Microchannel based) will require extra initialisation. If you (and/or others) are prepared to do the research/testing and come up with some code, we can certainly add it to my program (along with a combo to select computer type). Or perhaps a dedicated PS/2 version would be better.

 

[IBMMuseum]

No.
...I wonder if the PS/2 model 30 286 (AT class - first PS/2 with 16 bit ISA) is there too.

As you've alluded to, I'm sure other PS/2 models (Microchannel based) will require extra initialisation. If you (and/or others) are prepared to do the research/testing and come up with some code, we can certainly add it to my program (along with a combo to select computer type). Or perhaps a dedicated PS/2 version would be better.

The PS/2s, especially microchannel models, have most of their setup (adapters and planar features) in another area specific to the design. There isn´t a universal ¨Reference Diskette¨ (ISA models have a ¨Starter Diskette¨) for all models, and the wide variety of Adapter Desription Files (ADFs) between units could quickly fill up a diskette (the last of the PS/2 series could have ¨IML¨, Initial Machine Load, on a specific partition of a hard drive). It is a fascinating study for the architecture, but a little bit of a learning curve compared to earlier models.

The oldest models are a little over 20 years old. Last of the PS/2 line production was about 15 years ago. I´m willing to jump in, but they still may not be considered vintage here.

Look at the character-based configuration (microchannel PS/2s had VGA video at a minimum, and a stock mouse) to get where I want to develop an interest...

 

[modem7]

Microchannel

Microchannel

A 'full' Microchannel version of my program would be a lot of work.

As I see it, the 'helper' would need to get the person-in-need to run some BASIC code that reported which slot numbers are populated and for each of those slots, what the Microchannel number is of the card.
That information would be entered by the 'helper' into the program, and the 'helper' would select the PS/2 model (e.g. "PS/2 Model 50Z"). The program would then ask to be pointed to the location where it can read the corresponding ADF files. The program would then calculate a harmonious configuration (i.e. no IRQ/DMA/IO/RAM conflicts) then generate the BASIC code that would program such a configuration into the motherboard and cards.

I think it sounds easier than what it will turn out be. I have none of the PS/2 technical reference manuals, and so I don't even know if the Microchannel documentation and/or source code is available. And it may turn out that the generated BASIC code for the person-in-need to type in is pages long. But I'm being pessimistic.

I think the real question is, is there much benefit given that a person-in-need can easily create a 3.5" Reference Disk on a modern computer? In the case where the 3.5" is of 720K size, the technique of covering the size hole on a 1.44M diskette seems to work for the purpose of generating a Reference Diskette (even if they have to try a few times). There is benefit for a person-in-need whose PS/2 diskette drive has gone belly-up.

 

[IBMMuseum]

A 'full' Microchannel version of my program would be a lot of work.

As I see it, the 'helper' would need to get the person-in-need to run some BASIC code that reported which slot numbers are populated and for each of those slots, what the Microchannel number is of the card.
That information would be entered by the 'helper' into the program, and the 'helper' would select the PS/2 model (e.g. "PS/2 Model 50Z"). The program would then ask to be pointed to the location where it can read the corresponding ADF files. The program would then calculate a harmonious configuration (i.e. no IRQ/DMA/IO/RAM conflicts) then generate the BASIC code that would program such a configuration into the motherboard and cards.

I think it sounds easier than what it will turn out be. I have none of the PS/2 technical reference manuals, and so I don't even know if the Microchannel documentation and/or source code is available. And it may turn out that the generated BASIC code for the person-in-need to type in is pages long. But I'm being pessimistic.

I think the real question is, is there much benefit given that a person-in-need can easily create a 3.5" Reference Disk on a modern computer? In the case where the 3.5" is of 720K size, the technique of covering the size hole on a 1.44M diskette seems to work for the purpose of generating a Reference Diskette (even if they have to try a few times). There is benefit for a person-in-need whose PS/2 diskette drive has gone belly-up.

The 720Kb diskette drives were only on the 8086-based Model 25 and 30s. All other PS/2s have at least a 1.44Mb drive. And even those low-end 720Kb models can be upgraded to 1.44Mb drives with the right replacement.

Peter Wendt has oft-repeated BASIC code to get the ¨Adapter ID¨ information (http://www.mcamafia.de/mcapage0/hintpage.htm#hint02).

I did a few routines from BASIC and/or Assembler:

http://www.IBMMuseum.com/routines/CheckMCA.htm (to determine if the system is microchannel, and the number of microchannel ¨slot¨on the system)

http://www.IBMMuseum.com/routines/PlanarID.htm (to identify the microchannel system model)

http://www.ibmmuseum.com/routines/WhatSlot.htm (for finding if a particular microchannel adapter is installed, and on which ¨slot¨)

Generating what is considered ¨POS¨ data (which is how the adapter would be configured) from the wide variety of ADFs (and adapters) would be a very big task. I was thinking more of tokenizing the common ADFs, then using ROM-BASIC (which wouldn´t use space on the diskette) to ¨uncompress¨ them in a manner of speaking. Not really generating the would-be Reference Diskette from another system, but more of a universal Reference Diskette generated from the microchannel system itself (and using more of the VGA video and mouse features that the units have as default).

 

[Pekopome]

As you can see in the above screen shot, the person-in-need will have to inform you of the hardware configuration of their IBM AT.
BIOS version, base memory and expansion memory can be difficult for some persons-in-need to determine, but luckily, those three items can be determined by you getting the person-in-need to run some BASIC code:

Determining BIOS version

10 def seg = &hf000
20 for i = 0 to 7
30 print chr$(peek(&hfff5 + i));
40 next
run

Im having problems determining the BIOS version on my 5170, when I type in the code above... after i hit run it says:

Syntax error in 10
Ok
10 DEF SEQ = &HF000

What's wrong. Determining the other things works.. I dont know any thing about Basic coding, so please correct me....

Thanks again!

 

[IBMMuseum]

Im having problems determining the BIOS version on my 5170, when I type in the code above... after i hit run it says:

Syntax error in 10
Ok
10 DEF SEQ = &HF000

What's wrong. Determining the other things works.. I dont know any thing about Basic coding, so please correct me...

Using DOS, you can also run DEBUG:

C:\DEBUG

-D F000:FFF5 L 8

-Q

 

[Chuck(G)]

That's DEF SEG, as in "segment".

 

[Pekopome]

That's DEF SEG, as in "segment".

Haha ok, changing that q into a g, really makes the difference..

BTW, just ordered a sealed 5 1/4 floppy copy of DOS 6.0 on Ebay.. will that run on the 10/01/84 IBM 5170?

And is there a code for setting the time and date.. would be cool to see for how long the on board battery can keep the BIOS settings...

Again sorry for all these questions, Im still learning..