Computer guesses your number

[F. W.]

10 Rem *** Computer guesses your number ***
20 Print "Welcome to the guessing game!"
25 untergrenze = 1 : obergrenze = 0 : versuch = 0 : anzahl = 0
30 Input "To what maximal number will you guess";obergrenze
40 Do
42 versuch = untergrenze + Int((obergrenze - untergrenze) / 2)
43 anzahl = anzahl + 1
46 Print "Zwischen ";untergrenze;" und ";obergrenze
50 Print "I guess ";versuch
60 Input "g(reater, s(maller, i(t is it!";antwort$
63 Select Case antwort$
64 Case "g": untergrenze = versuch : Print "Okay, greater..."
65 Case "s": obergrenze = versuch : Print "Okay, smaller..."
66 End Select
70 If antwort$ = "i" Then 90
80 Loop Until antwort$ = "i"
90 Print "I needed ";anzahl;" tries. I remain a math-champion!"

FW

[Physfitfreak]

What language is this program in?

[Auric__]

It looks like a mashup of GWBASIC and QBasic. Some form of Microsoft BASIC
anyway.
- GWBASIC: No "DO" or "SELECT CASE". Change the DO-LOOP to WHILE-WEND, and
SELECT CASE to IF-ELSE, and it should work, but I'm not going to bother.
- QBasic: No line numbers inside SELECT CASE, but if you run it through
REMLINE.BAS it works. (Also in FreeBASIC.)

It works in QB64 and Bywater BASIC if you use capital letters in the inputs.
(Why capitals, I don't know.)

If you delete line 10 it works in Chipmunk Basic.

It *doesn't* work in BBS BASIC, PowerBASIC, PureBasic, or True Basic.

Also, line 70 is probably unnecessary. Just sayin'.

--
Don't take advice from fools.

[Physfitfreak]

It doesn't compile in latest version of FreeBASIC; it would need
declaration of the variables, to begin with.

Who would just post a BASIC program presumably for others to try,
without specifying what flavor of BASIC it got compiled on? I think the
poster wasn't serious about what he wanted to do.

[Auric__]

using '-lang qb' or '-lang fblite'.)

>> It works in QB64 and Bywater BASIC if you use capital letters in the
>> inputs. (Why capitals, I don't know.)
>>
>> If you delete line 10 it works in Chipmunk Basic.
>>
>> It *doesn't* work in BBS BASIC,

Whoops. BBC BASIC.

>> PowerBASIC, PureBasic, or True Basic.
>>
>> Also, line 70 is probably unnecessary. Just sayin'.
>
> It doesn't compile in latest version of FreeBASIC; it would need
> declaration of the variables, to begin with.

Sorry, oversight on my part, corrected above. (I don't use FB's dialect; my
script to call fbc includes the appropriate -lang needed for the source.)

> Who would just post a BASIC program presumably for others to try,
> without specifying what flavor of BASIC it got compiled on? I think the
> poster wasn't serious about what he wanted to do.

Serious or otherwise, at least he tried. This group is effectively dead,
along with most of Usenet, so [shrug]. Anyway, it's not like anyone else is
posting code here. So here, code for a random BASIC dialect. Have fun.

/*
Actual BASIC code for an actual BASIC compiler (including this comment).
Good luck figuring out which one.
*/

SUB INTRAND(min as INT,max as INT),INT
RETURN RAND(min,max)
ENDSUB

OPENCONSOLE
DO
LOCATE INTRAND(1,25),INTRAND(1,80)
PRINT "#"
UNTIL INKEY$ <> ""
CLOSECONSOLE
END

--
I still don't understand how he could possibly have survived.
He was on fire when I left him.

[Physfitfreak]

You are way more proficient in BASIC than I am.

I knew BASIC and C (and FORTRAN) decades back. I've forgotten all that
and need serious refreshing so I could write some simple programs for
fun. I first chose BASIC thinking it would compile faster, but after I
installed FreeBASIC and ran a few very simple codes I noticed that
compiling was way too slow for me. So as of now, I'm aiming at
refreshing of C++, not BASIC.

I understand that today's BASIC compilers first convert the codes to
C++, then compile the newly created code using Windows supplied C++
compiler. This takes too long, and I suspect this has something to do
with the decline of BASIC language today.

I remember how fast (or slow) compiling of BASIC code was decades back
on DOS. They were much faster than today's compilers which first convert
the code to C++.

Is there a way to compile BASIC code today, on Windows or Linux, without
changing the code first to C++? I'd appreciate if I could get your input.

[Gordon Henderson]

Lovely....

Still a BASIC fan after all these years, just recently wrote a new
TinyBasic for the 6502 CPU too... Because why not. It runs well with 4K
of ROM and 4K of RAM....

Translation to my TinyBasic:

>LIST
10 REM I Guess a number...
20 PR "Welcome to the guessing game."
25 PR "What's the upper limit ";
30 C = 0 : L = 1 : INPUT H
35 PR "Great. Think of a number from 1 to ", H, " and lets go..."
40 C = C + 1 : G = (H + L) / 2
50 PR "I guess: ", G
60 PR "Am I Higher, Lower or = ? ";
70 Y = GET
80 IF (Y = 72) OR (Y = 104) GOTO 100 : REM Higher
90 IF (Y = 76) OR (Y = 108) GOTO 200 : REM Lower
94 IF Y = 61 GOTO 300
99 PR "Huh?" : GOTO 50
100 PR "Higher, so ..."
110 H = G
120 GOTO 40
200 PR "Lower, so ..."
210 L = G
220 GOTO 40
300 PR "Equals!"
310 PR "I got it right in ", C, " guesses."
320 END


>RUN
Welcome to the guessing game.
What's the upper limit ?100
Great. Think of a number from 1 to 100 and lets go...
I guess: 50
Am I Higher, Lower or = ? Huh?
I guess: 50
Am I Higher, Lower or = ? Higher, so ...
I guess: 25
Am I Higher, Lower or = ? Lower, so ...
I guess: 37
Am I Higher, Lower or = ? Lower, so ...
I guess: 43
Am I Higher, Lower or = ? Higher, so ...
I guess: 40
Am I Higher, Lower or = ? Lower, so ...
I guess: 41
Am I Higher, Lower or = ? Lower, so ...
I guess: 42
Am I Higher, Lower or = ? Equals!
I got it right in 7 guesses.


How those old memories come flooding back... ;-)

Cheers,

-Gordon

[Physfitfreak]

Are you running it on a device from 70s that used that processor in it,
or you built a board with the chip on it?

[Gordon Henderson]

In article <umqj5o$if4s$2...@solani.org>,

>Are you running it on a device from 70s that used that processor in it,
>or you built a board with the chip on it?

I built a board with a 6507 on it although I've run it on other 6502
systems I've built and own.

https://unicorn.drogon.net/IMG_20231220_193620_DRO.jpg

Cheers,

-Gordon

[Auric__]

Physfitfreak wrote:

[snip]

> You are way more proficient in BASIC than I am.

40 years will do that. It's what I use for most of my professional work.

> I knew BASIC and C (and FORTRAN) decades back. I've forgotten all that
> and need serious refreshing so I could write some simple programs for
> fun. I first chose BASIC thinking it would compile faster, but after I
> installed FreeBASIC and ran a few very simple codes I noticed that
> compiling was way too slow for me. So as of now, I'm aiming at
> refreshing of C++, not BASIC.

Modern C++ is very, very different than C "decades back". Might as well start
from the beginning.

> I understand that today's BASIC compilers first convert the codes to
> C++, then compile the newly created code using Windows supplied C++
> compiler. This takes too long, and I suspect this has something to do
> with the decline of BASIC language today.

No, most do *not* compile to C++. Some interpret, some compile to some form
of bytecode, and some compile to machine code (a.k.a. "normal" compiler).
Offhand I can only think of 2 that compile to anything in the C family that
are in active development: BCX (to C/C++) and B4X (to Java). FutureBASIC used
to have a project called FBtoC that allowed Mac apps to be compiled with GCC,
but that appears to be dead. Other BASIC-to-C-ish translators exist, but most
suck, and the ones that don't are generally dead.

(Also, Windows doesn't include any compilers by default.)

> I remember how fast (or slow) compiling of BASIC code was decades back
> on DOS. They were much faster than today's compilers which first convert
> the code to C++.
>
> Is there a way to compile BASIC code today, on Windows or Linux, without
> changing the code first to C++? I'd appreciate if I could get your input.

Compilation speed should not be something that determines your usage of a
language, unless we're talking "hours" (or longer); runtime speed is far more
important. Here's what I currently use for various projects:

- Visual Basic 2022: Free-ish. Compiles to .Net bytecode. Theoretically, apps
can run on Linux and Mac (using the Mono runtime), but realistically, it's
Windows-only. Not really the same as classic VB, but it gets the job done.
Note that the IDE can be slow to open, especially on older machines. (I
also still use VB6 for some things, and a lot of VBA under Excel, because
of course I do.)
- PowerBASIC: Commercial. Windows-only, 32-bit only. (A DOS version is
available but hasn't been updated in a couple decades.) Fast compile times,
fastest runtimes I've seen for BASIC on Windows. GUI and CLI compilers are
separate products, so [shrug]. My preferred BASIC for 32-bit development.
- FreeBASIC: Open Source. You know about this one, apparently.
- Chipmunk Basic: Free. Interpreter. Mainly for Mac but also has Windows,
Linux, and Raspberry Pi versions.
- Xojo: Commercial. Windows, Mac, and Linux; also compiles for Raspberry Pi,
iOS, Android, and web, if you get the Pro version. (Raspberry Pi-only
appears to be free; unsure.)
- B4J: Free. Windows. Part of B4X, this is the one for desktop systems. There
is also B4A for Android development, B4R for Arduino, and B4I, the
company's only commercial product, for iOS. (This started as Basic4PPC,
compiling for PocketPC, Microsoft's competitor to Palm Pilot, about a
thousand years ago.) Very similar to VB.Net.
- App Game Kit: Commercial. Windows only, I believe. Compiles to its own
bytecode, requires an interpreter (a "player"), which is available for
Windows, Mac, Linux, Android, and iOS. Graphical/3D modes only, no windowed
or CLI modes.

I've also tinkered with various other BASICs, including BBC BASIC (various),
PureBasic (commercial, free for Amiga), True BASIC (commercial), QB64 (open
source), XBASIC/XBLite (open source), Liberty Basic (commercial), and, well,
a bunch of others you've probably never heard of. I either didn't like their
dialects of BASIC, or else I didn't like something else about them, so I
didn't stick with any of them.

The one I specifically recommend *against* is Objective-Basic for the Mac,
from the same guy who created Kbasic, as the free version forces you to GPL3
your own source code to stay within its own licensing rules. (Also, it hasn't
been updated since 2012, so it's Intel-only, no Apple Silicon.)

--
...and in her self-loathing and despair she found wrath.

[Physfitfreak]

Cool. Looks neat!

[Physfitfreak]

How do you communicate with it?

[Physfitfreak]

On 12/31/2023 1:18 PM, Auric__ wrote:
> Compilation speed should not be something that determines your usage of a
> language, unless we're talking "hours" (or longer); runtime speed is far more
> important.

Actually in my particular case it is the compilation speed that bothers
me, not the execution speed. In the course of writing the codes I have
to compile many many times to remove bugs and correct my mistakes, etc,
while after all issues are gone, I would have to wait just once for each
run of the executable file. There would be no hurry there.

For a two line code in FreeBASIC, I have to wait 30 seconds for it to
compile and run... This is way too slow. Imagine when I want to write a
relatively involved program how many times and how long I have to wait
to do the troubleshooting.

[Gordon Henderson]

In article <un2h56$o1sd$3...@solani.org>,

The hard way: Bit-banged software serial. That goes into a cheap
TTL USB serial adapter to my PC.

There was just enough code-space let over in the 4K image to add the
serial code in. It works well at 9600 and I'm sure would go much faster,
but I've never bothered to try.

With the VIA added (IO chip, gives me 18 'pins'), making a festive tree:

https://unicorn.drogon.net/IMG_20231222_221107_DRO.jpg

https://unicorn.drogon.net/6507-tree.mp4

And this being BASIC, here's the "active" bit of that program:

200 L = RND % 18
210 IF RND % 2 = 0 GOSUB 2 : GOTO 200
220 GOSUB 5 : GOTO 200

Cheers,

Gordon

[Gordon Henderson]

In article <un2hrq$o1sd$4...@solani.org>,

One of the joys of BASIC is the instant "always-on" nature of it. Or was.
It is interactive, fast (relatively speaking) and right there. Or should
be (IMO). Then people started to get clever and compile it and add all
sorts of things to it like having to declare variables and so on.

I'm really surprised that FreeBASIC taks 30 seconds to compile a few lines
though.

Gordon

[Auric__]

That's... odd. What OS? What hardware?

I'm running Windows 10 Pro 22H2 on a 10-year-old Intel i5 @ 3.2 GHz, using
the current release of FreeBASIC (1.10.1, released Xmas Eve), and this test
program:

dim a as long
for a = 1 to 255
print bin$(a),""
next

...takes about 2-3 seconds to compile for both the 32-bit and 64-bit
versions. The same goes for the DOS version under DOSBox-X. (I don't have it
installed on other systems to check, but I imagine it would be about the
same.) So, something must be... uh... "different" about your setup.


As an aside, if I'm writing for a system like FreeBASIC that doesn't have a
built-in interpreter or some fast way to do test runs, I usually write in a
system that *does* -- often Qbasic or Chipmunk Basic -- and then when the
program works, I make whatever edits are needed to make it work in my chosen
system and *then* do the actual compile.

--
Almost everything here made it here because somebody managed to come
up with some new bad idea that we hadn't previously anticipated.

[Physfitfreak]

Yes, I thought so too that something was wrong with my set up but I
couldn't find what. My system is old also. I am using Win10 Enterprise
64 bit on S20 ThinkStation (Xeon x5675, 20 gb RAM). I installed
FreeBASIC 1.10.1-win64 and for GUI installed FBIde 0.4.6r4.

Wikipedia says FreeBASIC converts the code to C++ then compiles C++. I
was thinking this conversion of code is what makes it take that long.

I'll try Qbasic to see how it goes.

[Physfitfreak]

Very cool :)

[Auric__]

Physfitfreak wrote:

> On 1/3/2024 3:16 PM, Auric__ wrote:

[snip]

>> That's... odd. What OS? What hardware?
>>
>> I'm running Windows 10 Pro 22H2 on a 10-year-old Intel i5 @ 3.2 GHz,
>> using the current release of FreeBASIC (1.10.1, released Xmas Eve), and
>> this test program:
>>
>> dim a as long
>> for a = 1 to 255
>> print bin$(a),""
>> next
>>
>> ...takes about 2-3 seconds to compile for both the 32-bit and 64-bit
>> versions. The same goes for the DOS version under DOSBox-X. (I don't
>> have it installed on other systems to check, but I imagine it would be
>> about the same.) So, something must be... uh... "different" about your
>> setup.
>>
>>
>> As an aside, if I'm writing for a system like FreeBASIC that doesn't
>> have a built-in interpreter or some fast way to do test runs, I usually
>> write in a system that *does* -- often Qbasic or Chipmunk Basic -- and
>> then when the program works, I make whatever edits are needed to make
>> it work in my chosen system and *then* do the actual compile.
>
> Yes, I thought so too that something was wrong with my set up but I
> couldn't find what. My system is old also. I am using Win10 Enterprise
> 64 bit on S20 ThinkStation (Xeon x5675, 20 gb RAM). I installed
> FreeBASIC 1.10.1-win64 and for GUI installed FBIde 0.4.6r4.

Hm. I couldn't even begin to guess what the issue might be. I don't use any
of the FB IDEs; I typically either use Qbasic or an old version of
UltraEdit.

> Wikipedia says FreeBASIC converts the code to C++ then compiles C++. I
> was thinking this conversion of code is what makes it take that long.

Ah, I see. FreeBASIC has the *option* to compile to something C-ish, but the
*default* is to compile to assembly, either x86 or x86-64, depending on the
platform. (I was unaware of the ability to compile to C, so apologies for
any confusion caused.) See this page for info:

https://www.freebasic.net/wiki/CompilerOptgen

> I'll try Qbasic to see how it goes.

Just remember, Qbasic has limitations that don't exist in FB; notably, the
DIR$ function doesn't exist, requiring some... interesting workarounds. In
fact, here's what I use:

-----
FUNCTION DIR$ (what AS STRING)
' usage:
' pass in the filespec you want: DIR$("*.*")
' for subsequent files, pass an empty string: DIR$("")
' returns:
' one filename per call
' if file not found, or end of list, returns empty string: ""
' ALWAYS includes hidden, system, and read-only files
' NEVER includes directories
' (could be modified to change either of the above)

STATIC found() AS STRING
STATIC fcount AS INTEGER
STATIC fdnum AS INTEGER
STATIC thisfile AS INTEGER
DIM tmpfile AS STRING, tmpstr1 AS STRING, tmpint1 AS INTEGER

IF LEN(what) THEN ' new filespec; rebuild list
fcount = -1
thisfile = -1
IF LEN(tmpfile) THEN KILL tmpfile
tmpfile = ENVIRON$("TEMP")
IF LEN(tmpfile) THEN IF RIGHT$(tmpfile, 1) <> "\" THEN _
tmpfile = tmpfile + "\"
tmpfile = tmpfile + LTRIM$(STR$(CLNG(TIMER * 100))) + ".tmp"
IF LEN(ENVIRON$("COMSPEC")) THEN
SHELL ENVIRON$("COMSPEC") + " /c dir /a-d /b " + what + " > " + _
tmpfile
ELSE
SHELL "command.com /c dir /a-d /b " + what + " > " + tmpfile
END IF
fdnum = FREEFILE
OPEN tmpfile FOR INPUT AS fdnum
DO UNTIL EOF(fdnum)
fcount = fcount + 1
LINE INPUT #fdnum, tmpstr1
LOOP
CLOSE fdnum

IF fcount > -1 THEN
REDIM found(fcount) AS STRING

OPEN tmpfile FOR INPUT AS fdnum
FOR tmpint1 = 0 TO fcount
LINE INPUT #fdnum, found(tmpint1)
NEXT
CLOSE fdnum
END IF

KILL tmpfile
END IF

IF fcount > -1 THEN
thisfile = thisfile + 1
IF thisfile > fcount THEN
DIR$ = ""
ELSE
DIR$ = found(thisfile)
END IF
ELSE
DIR$ = ""
KILL tmpfile
END IF
END FUNCTION
-----

Public domain. Feel free to use or change as desired. Under non-Win/DOS
systems it would need to be changed to invoke 'ls' instead of 'dir' (or
whatever equivalent works) and change '\' to '/' (or whatever character the
system uses to indicate directories) but otherwise should work.

(An alternate method I just thought of would involve calling 'attrib'
instead of 'dir'. Something for future experimentation, I suppose.)

--
- What would that imply?
- I dunno.

[Physfitfreak]

I'll try that after I manage to run qbasic. Looks like on win10 I should
download and install VMWare Workstation Player, and then use that to
download and install Qbasic. But everytime I download VMware Workstation
Player, right after download is done the file disappears and browser
closes and instead of a downloaded ready to use file I see a file named:

Unconfirmed 937735.crdownload

What is slightly larger than the file I downloaded and useless to me. I
don't know what the deal is with VMWare Workstation Player.

[Auric__]

Physfitfreak wrote:

> I'll try that after I manage to run qbasic.

Note that the code I posted is only for MSBASIC-alikes without an equivalent
to DIR$. Under FreeBASIC it probably won't work due to name collision with
the built-in function.

> Looks like on win10 I should
> download and install VMWare Workstation Player, and then use that to
> download and install Qbasic. But everytime I download VMware Workstation
> Player, right after download is done the file disappears and browser
> closes and instead of a downloaded ready to use file I see a file named:
>
> Unconfirmed 937735.crdownload
>
> What is slightly larger than the file I downloaded and useless to me. I
> don't know what the deal is with VMWare Workstation Player.

No, don't bother. I suggest using DOSBox or one of its derivatives instead. I
use DOSBox-X:

https://dosbox-x.com/

...but note that it doesn't come with QBasic. *That* you'll need to get from
elsewhere; I recommend WinWorldPC:

https://winworldpc.com/product/qbasic/1x

Extract the downloaded .7z to any folder on your system and run qbasic.exe in
your emulator of choice.

(Note also that this only applies to 64-bit versions of Windows (and non-
Windows systems); 32-bit Windows 10 should be able to run DOS programs
without issue.)

--
That boy ain't right.

[Physfitfreak]

I downloaded and installed DOSBox-X, then got QBasic 1.0 from
winworldpc.com in the form of one disk image file. Tried to undisk it
but I keep getting there's no room in Z: drive. Qbasic.exe is only about
250 KB, it's help file is about half the size, and the image file is
about 1.5 megs. So I don't know why it runs out of space in that virtual
DOS.

[Auric__]

Physfitfreak wrote:

> On 1/6/2024 1:30 PM, Auric__ wrote:

[snip]

>> No, don't bother. I suggest using DOSBox or one of its derivatives
>> instead. I use DOSBox-X:
>>
>> https://dosbox-x.com/
>>
>> ...but note that it doesn't come with QBasic. *That* you'll need to get
>> from elsewhere; I recommend WinWorldPC:
>>
>> https://winworldpc.com/product/qbasic/1x
>>
>> Extract the downloaded .7z to any folder on your system and run
>> qbasic.exe in your emulator of choice.
>>
>> (Note also that this only applies to 64-bit versions of Windows (and

>> non-Windows systems); 32-bit Windows 10 should be able to run DOS

>> programs without issue.)
>
> I downloaded and installed DOSBox-X, then got QBasic 1.0 from
> winworldpc.com in the form of one disk image file. Tried to undisk it
> but I keep getting there's no room in Z: drive. Qbasic.exe is only about
> 250 KB, it's help file is about half the size, and the image file is
> about 1.5 megs. So I don't know why it runs out of space in that virtual
> DOS.

Extract the disk image to a folder (I suggest a new one), mount that folder
as the C: drive, and then try again from there.

--
- So you seek revenge?
- I seek righteousness. But I'll take revenge.

[Physfitfreak]

Ok, now I have a working qbasic. But when I write a code with it, it
can't be copied and kept on computer! Does one have to use another
editor to develop a program and for testing insert it (if it can be
done!) inside qbasic screen? This is cumbersome.

[Physfitfreak]

When trying to save a file it gives, "Path / File access error". Also,
it cannot be copied from screen (ctrl-C) and saved elsewhere in another
editor, so one can then save the work.

What am I doing wrong?

[Auric__]

Physfitfreak wrote:

> On 1/26/2024 7:03 PM, Physfitfreak wrote:

[snip]

>> Ok, now I have a working qbasic. But when I write a code with it, it
>> can't be copied and kept on computer! Does one have to use another
>> editor to develop a program and for testing insert it (if it can be
>> done!) inside qbasic screen? This is cumbersome.

No clue. The IDE just works for me as expected, including writing files to
the computer's hard drive (not just the emulated drive).

> When trying to save a file it gives, "Path / File access error". Also,
> it cannot be copied from screen (ctrl-C) and saved elsewhere in another
> editor, so one can then save the work.
>
> What am I doing wrong?

Keyboard combos are specific to whatever DOS app is running at the moment,
and will only work inside the emulated DOS system. You can copy the entire
screen to the Windows clipboard by pressing Ctrl+F5, and then paste it
somewhere else (but note that EVERYTHING on screen gets copied).

Otherwise I have no idea what's wrong. Without sitting at your computer I
couldn't even begin to guess what's wrong. The way I told you to do it is
really, really different from my normal (unsafe) methods. Maybe my methods
aren't right for you. Shrug. Sorry.

--
Oooh, spooky! You get to be a corporate drone.