• Please review our updated Terms and Rules here

How do you enter basic if there is DOS installed in XT

per said:
You can be safe that ALL of the IBM machines made up to 1991 has ROM BASIC. IBM had to include it because of a license agreement they made with Microsoft when IBM created the PC in 1981 (I guess it was a 10-year contract).
Click to expand...

In fact, the agreement had no specific length. It merely said that IBM had to include the ROM BASIC for as long as BASICA was being actively developed, which ended in 1991 when QBASIC was introduced. In addition, no other manufacturer could include any x86 version of Microsoft BASIC in the ROM of their machines.
 
Chuck(G) said:
Or, suppose that you didn't have DEBUG (or any other program around), you could do it this way:

echo stuff>gobas.com

Where stuff is created by pressing the Alt-key and keying three digits at a time, then releasing the Alt key, the following numbers on the numeric keypad:

049
192
142
216
142
192
205
024
205
032

An extra 0D 0A will be appended by echo, but it doesn't matter as it's not executed.

Just skinnin' the cat a different way... :)
Click to expand...

Wow, that worked like a charm!!
You guys really know your IBMs....
Now I guess I have to learn some ROM BASIC commands. Is it possible to save to the HDD with this method? I'm assuming not.
 
MikeS said:
Any special reason why you don't want to use GWBASIC?
Click to expand...

I'm not sure if GWBASIC actually takes use of the BASIC routines in ROM if present. If it does, using GWBASIC will be an advantage. However, if GWBASIC only uses it's own routines stored in RAM, using BASICA will actually be faster than using GWBASIC.

Explanation:
The 4164 DRAM uses multiplexed address inputs, so to access one byte, the first half of the address must first be applied, then the other half of the addres must be applied before the data can pass. This will take two clock cycles, and a one-clock wait-state must be generated because the CPU expect data to arrive within only one cycle.

The 2764/27256 EPROM doesn't use a multiplexed address bus, so the data will appear imediately; hence no wait-states will be needed. This causes a dramaticly speed increase in execution when compared to a equalent program stored in multiplexed-address-based RAM.
 
On the third hand if you seek maximum execution speed, you probably will try another approach than using either Basic interpreter. :) However the IBM PC was known for having a fast Basic but I think that is due to a 4.77 MHz 8088 after all is a bit more powerful than both a 3.58 MHz Z80 and a 1-2 MHz 6502.

By the way, yesterday I tried the INT 18 call on my Vicky 8088 but as expected, nothing happened since it is not an IBM computer and doesn't have any built-in Basic. I would have to suffer with GWBasic or a completely different programming language.
 
per said:
I'm not sure if GWBASIC actually takes use of the BASIC routines in ROM if present. If it does, using GWBASIC will be an advantage. However, if GWBASIC only uses it's own routines stored in RAM, using BASICA will actually be faster than using GWBASIC.

Explanation:
The 4164 DRAM uses multiplexed address inputs, so to access one byte, the first half of the address must first be applied, then the other half of the addres must be applied before the data can pass. This will take two clock cycles, and a one-clock wait-state must be generated because the CPU expect data to arrive within only one cycle.

The 2764/27256 EPROM doesn't use a multiplexed address bus, so the data will appear imediately; hence no wait-states will be needed. This causes a dramaticly speed increase in execution when compared to a equalent program stored in multiplexed-address-based RAM.
Click to expand...
Well, as Anders says if speed's an issue then either BASIC isn't exactly ideal, and of course the actual program will be in RAM in any case.
But it's an interesting point. EPROMS of the day were also notoriously slow (which is why later BIOSes allowed copying them to shadow RAM and running from there), but IBM's BASIC was in ROM, not EPROM; still, it'd be interesting to see just how much speed difference there would be, although any difference might also be due to differences in the interpreters themselves.
 
IBMMuseum said:
A check for ROM BASIC could be incorporated in code rather easily too:

http://www.ibmmuseum.com/interrupts/INT15h/INT15h22.html

Run the interrupt to catch the later PS/2s (I need to populate supported models), if not, check for the version text string...

Failing that, the system doesn't have ROM BASIC...
Click to expand...

The interrupt 15h is Casette I/O on PC's, and it doesn't do anything on XT's with the early BIOS. In other words, the BIOS ID should also be checked if the Int 15h call fails.

About speed, there is a reason why I have gone from BASIC to Asm. However, even BASIC is a really slow language, you would still want all the speed you could get, even it isn't more than being able to execute a few more instructions per second.
 
per said:
About speed, there is a reason why I have gone from BASIC to Asm. However, even BASIC is a really slow language, you would still want all the speed you could get, even it isn't more than being able to execute a few more instructions per second.
Click to expand...
... if you can live without the GW-BASIC specific capabilities...
 
per said:
The interrupt 15h is Casette I/O on PC's, and it doesn't do anything on XT's with the early BIOS. In other words, the BIOS ID should also be checked if the Int 15h call fails.
Click to expand...

As ROM BASIC never changed substantially from the first version to the last, I'd probably just look for the header in memory and forget about using INT 15H services. INT 15 is one of those interrupts that often got "hooked" by TSRs.

About speed, there is a reason why I have gone from BASIC to Asm. However, even BASIC is a really slow language, you would still want all the speed you could get, even it isn't more than being able to execute a few more instructions per second.
Click to expand...

Everything to its own purpose. I keep a copy of GWBASIC handy on all my systems. The interactive mode allows me to make quick calculations or check out the sanity of an algorithm I'm playing with.

I've used GWBASIC to generate tables for incorporation into C and assembly programs, rework the contents of text files and even generate HTML. It's a very forgiving, instant-gratification, run-just-about-anywhere tool.

All of our invoicing and customer database work was done in GWBASIC, originally written for an 8088 on DOS and brought right along to run with WinXP on a P4 system. Aside from the occasional tweak to cope with peripheral issues, it's run flawlessly since 1986.

I'd say that for a PC-based language, that's pretty impressive. My only regret is that there is no upgrade to allow it to work with long file names.
 
I would imagine it's more of an exercise with using what's native to the machine. I know if I have native features on a computer or operating system I'd rather learn them than mess with 3rd party stuff. Could just be me though.

I tried a few quick searches for an IBM Rom Basic manual but didn't find what I wanted to post. Maybe someone else will have better luck. Basic has a save command but I'm not sure if Rom basic would have that or know how to write to a dos drive letter assignment or even a device number (bios). I would imagine there is likely a way to save your work though, just can't quote anything and I haven't done it myself.
 
Chuck(G) said:
As ROM BASIC never changed substantially from the first version to the last
Click to expand...

There were three revisions. 16k-64k 5150s had BASIC C1.00, and everything else except the PCjr (which had BASIC C1.20) used version C1.10.

barythrin said:
I tried a few quick searches for an IBM Rom Basic manual but didn't find what I wanted to post. Maybe someone else will have better luck. Basic has a save command but I'm not sure if Rom basic would have that or know how to write to a dos drive letter assignment or even a device number (bios). I would imagine there is likely a way to save your work though, just can't quote anything and I haven't done it myself.
Click to expand...

The LOAD, SAVE, BLOAD, and BSAVE commands do exist in ROM BASIC, but of course they only work with the cassette. ROM BASIC is also missing the following commands:

CHAIN, CHDIR, CIRCLE, COM(n), COMMON, CVI, CVS, CVD, DATE$, DRAW, ENVIRON, ENVIRON$, ERDEV, ERDEV$, EXTERR(n), FIELD, FILES, GET, IOCTL, IOCTL$, KEY(n), KILL, LOC, LOCK, LOF, LSET, RSET, MKDIR, MKI$, MKS$, MKD$, NAME, ON COM(n), ON KEY(n), ON PEN, ON PLAY, ON STRIG(n), ON TIMER, OPEN, OPEN "COM...", PAINT, PALETTE, PALETTE USING, PEN STOP, PLAY(n), PMAP, PUT, RESET, RMDIR, SHELL, STRIG(n), SYSTEM, TIME$, TIMER, UNLOCK, VARPTR$, VIEW, WINDOW
 
So trying to think outside the box but could work be saved by poking the floppy drive directly from the rom basic? I imagine this has to have been worked around by folks familiar with this in it's heyday. I think you could also probably poke it out of the com port if that technique works. Given you'd need to read your data and poke it correctly which may be a larger problem than the desired output.
 
barythrin said:
So trying to think outside the box but could work be saved by poking the floppy drive directly from the rom basic? I imagine this has to have been worked around by folks familiar with this in it's heyday. I think you could also probably poke it out of the com port if that technique works. Given you'd need to read your data and poke it correctly which may be a larger problem than the desired output.
Click to expand...

Maybe if you got a memory mapped com port/hard drive. When thinking about it, doesn't the Silicon Valey ADP50L IDE-controller use memory-mapped I/O?

Anyways, wasn't there a diagnostics casette that loaded itself through casette BASIC and then transfered controll to a loaded machine-code program?

The drawback is that the new routine for saving/loading data has to be typed in every time BASIC was loaded.
 
per said:
The interrupt 15h is Casette I/O on PC's, and it doesn't do anything on XT's with the early BIOS. In other words, the BIOS ID should also be checked if the Int 15h call fails...
Click to expand...

Interrupt 15h routines were added and updated by IBM for the PS/2 series. One of the more heavily-used calls, "Get Configuration", has been there all along, updated as some new features came out. Agreed, the early IBM systems didn't implement many functions well (including flubbing the "Get Configuration" in one instance), requiring checks by other means, but it is much more than Cassette Services on later systems.

Chuck(G) said:
As ROM BASIC never changed substantially from the first version to the last, I'd probably just look for the header in memory and forget about using INT 15H services. INT 15 is one of those interrupts that often got "hooked" by TSRs...
Click to expand...

Yes, it is a minor point to screen for such things, but I'm geared towards IBM, so what can I say? Of course I am also able to observe systems and determine very quickly whether they have ROM BASIC too, without running any code to check. And I do my limited programming on internal systems, running code without any TSRs hooking in, not really for a production environment or for everything that could come into the mix.
 
IBMMuseum said:
Yes, it is a minor point to screen for such things, but I'm geared towards IBM, so what can I say? Of course I am also able to observe systems and determine very quickly whether they have ROM BASIC too, without running any code to check.
Click to expand...

I've got non-IBM gear with IBM BIOS-es installed, with and without BASIC. I used to have a 5160 with a DTK "clone" BIOS installed.

How do you sort that out without running any code?

I'm eager to learn...
 
Chuck(G) said:
I've got non-IBM gear with IBM BIOS-es installed, with and without BASIC. I used to have a 5160 with a DTK "clone" BIOS installed.

How do you sort that out without running any code?

I'm eager to learn...
Click to expand...

I guess what I'm trying to say, is that I work with my own systems, and knowing what is there...
 
You must log in or register to reply here.
Back
Top