BasinC oddnesses

The place for codemasters or beginners to talk about programming any language for the Spectrum.
User avatar
Fahnn
Dizzy
Posts: 84
Joined: Sun Jan 27, 2019 7:56 pm
Location: Redcar, UK
Contact:

BasinC oddnesses

Post by Fahnn » Mon May 13, 2019 4:14 pm

To start: I think BasinC is great, it makes BASIC programming so much quicker and easier. However, I seem to be getting a couple of recurring problems.

1. Lines or parts of lines seem to be deleted on saving and reloading. I think it's something to do with where the cursor is on saving; if it's outside of a line, all is fine, but if it's within a line, parts sometimes go missing.

2. When using variables that are always integers and subtracting from them by one, I often seem to get weirdness like "2.086162E-7" when the variable should be zero (i.e. the program does 1-1 and outputs a very small integer rather than zero). I think this might have been a bug in the original Spectrum ROM as I seem to remember it coming up thirty-odd years ago too. But surely there must be a way round it now?

Frustratingly, I can't reproduce these errors reliably but I've had both on multiple occasions the last couple of days. And I should say that it's quite possible that there is some user error involved. The non-zero thing is really annoying me though, I don't want to have to INT variables after every operation, which is the only way around it that I can see.

Any suggestions? I'm using BasinC 1.7.
0 x
www.fahnn.co.uk / Trine Michelson's Hot Parts: www.fahnn.co.uk/trine.txt / Big Deal (demo): http://www.fahnn.co.uk/big_deal.tap

User avatar
Einar Saukas
Manic Miner
Posts: 692
Joined: Wed Nov 15, 2017 2:48 pm

Re: BasinC oddnesses

Post by Einar Saukas » Mon May 13, 2019 5:24 pm

Try on any Spectrum model:

Code: Select all

PRINT 1/2-.5
BasinC wouldn't be much useful for Spectrum development if it gave different results than a real Spectrum...
0 x

User avatar
Fahnn
Dizzy
Posts: 84
Joined: Sun Jan 27, 2019 7:56 pm
Location: Redcar, UK
Contact:

Re: BasinC oddnesses

Post by Fahnn » Mon May 13, 2019 5:29 pm

Einar Saukas wrote:
Mon May 13, 2019 5:24 pm
Try on any Spectrum model:

Code: Select all

PRINT 1/2-.5
BasinC wouldn't be much useful for Spectrum development if it gave different results than a real Spectrum...
Yes, but what should I do to get around it? It's been over 35 years, surely someone has something by now?

As for the other problem, is that just me or has anyone else experienced it? It's not a major problem but it is annoying. It's why I switched over to Spectaculator when I was writing the porn game, but I don't really want to do that this time (because writing in BasinC is so much easier).
0 x
www.fahnn.co.uk / Trine Michelson's Hot Parts: www.fahnn.co.uk/trine.txt / Big Deal (demo): http://www.fahnn.co.uk/big_deal.tap

d2010
Berk
Posts: 37
Joined: Tue Mar 26, 2019 9:19 am

Re: BasinC oddnesses

Post by d2010 » Mon May 13, 2019 5:42 pm

Fahnn wrote:
Mon May 13, 2019 4:14 pm
To start: I think BasinC is great, it makes BASIC programming so much quicker and easier.

2. When using variables that are always integers and subtracting from them by one, I often seem to get weirdness like "2.086162E-7" when the variable should be zero (i.e. the program does 1-1 and outputs a very small integer rather than zero). I think this might have been a bug in the original Spectrum ROM as I seem to remember it coming up thirty-odd years ago too. But surely there must be a way round it now?
Any suggestions? I'm using BasinC 1.7.
This bug exists in Delphi~Compilator not in Basinc1.7.Inside Delphi 2-5 have same problem with zero/fuzzy.I recommand you send email to Author-of-Basin.exe implement in his source the function "SAMEVALUE".
On the file Basin1.7.ini. :roll: he insert the line
"Epsilon_fuzzy=0.000000005".When the real is OutOfRange that Epsilon_fuzzy,
--> Always the real-variabile will be 0.0 not xxxE-7.

[Version]
BasinCVersion=BasinC v1.7

[LastSession]
LastFileOpened=ula.sna
:shock:
[Programming]
Epsilon_fuzzy=0.000000005

I found the solution inside Delphi2009 or Delphi7.
SpoilerShow

function SameValue(const A, B: Extended; Epsilon: Extended): Boolean;
begin
if Epsilon = 0 then Epsilon := Max(Min(Abs(A), Abs(B)) * ExtendedResolution, ExtendedResolution);
if A > B then
Result := (A - B) <= Epsilon
else
Result := (B - A) <= Epsilon;
end;
SpoilerShow

function SameValue(const A, B: Double; Epsilon: Double): Boolean;
begin
if Epsilon = 0 then
Epsilon := Max(Min(Abs(A), Abs(B)) * DoubleResolution, DoubleResolution);
if A > B then
Result := (A - B) <= Epsilon
else
Result := (B - A) <= Epsilon;
end;
0 x

User avatar
Fahnn
Dizzy
Posts: 84
Joined: Sun Jan 27, 2019 7:56 pm
Location: Redcar, UK
Contact:

Re: BasinC oddnesses

Post by Fahnn » Mon May 13, 2019 5:58 pm

d2010 wrote:
Mon May 13, 2019 5:42 pm
This bug exists in Delphi~Compilator not in Basinc1.7...
I didn't really understand any of that. I'll just INT everything I think, it's only a few more bytes.
0 x
www.fahnn.co.uk / Trine Michelson's Hot Parts: www.fahnn.co.uk/trine.txt / Big Deal (demo): http://www.fahnn.co.uk/big_deal.tap

User avatar
ZXDunny
Microbot
Posts: 133
Joined: Tue Nov 14, 2017 3:45 pm

Re: BasinC oddnesses

Post by ZXDunny » Mon May 13, 2019 6:01 pm

d2010 wrote:
Mon May 13, 2019 5:42 pm
[snip rubbish]
And exactly what would be the point of fixing a broken floating point implementation that yields results different to a real Spectrum?
0 x

Joefish
Manic Miner
Posts: 428
Joined: Tue Nov 14, 2017 10:26 am

Re: BasinC oddnesses

Post by Joefish » Mon May 13, 2019 6:04 pm

There's some legitimate syntax that BASIN / BasinC refuses to accept too. Try typing:

LET x$=INKEY$#4

PRINT AND INPUT it allows to work with streams, but not INKEY$.
It's annoying since streams are a handy way of interfacing BASIC to machine-code helper routines.
0 x

User avatar
Fahnn
Dizzy
Posts: 84
Joined: Sun Jan 27, 2019 7:56 pm
Location: Redcar, UK
Contact:

Re: BasinC oddnesses

Post by Fahnn » Mon May 13, 2019 6:18 pm

ZXDunny wrote:
Mon May 13, 2019 6:01 pm
d2010 wrote:
Mon May 13, 2019 5:42 pm
[snip rubbish]
And exactly what would be the point of fixing a broken floating point implementation that yields results different to a real Spectrum?
Because it might be an improvement?

I completely understand the need for verisimilitude but certain things - dare I say it - weren't quite right on the original. You could easily have a marginally bug-fixed version of BASIC along with the original implementation.
0 x
www.fahnn.co.uk / Trine Michelson's Hot Parts: www.fahnn.co.uk/trine.txt / Big Deal (demo): http://www.fahnn.co.uk/big_deal.tap

Joefish
Manic Miner
Posts: 428
Joined: Tue Nov 14, 2017 10:26 am

Re: BasinC oddnesses

Post by Joefish » Mon May 13, 2019 6:34 pm

It's a tool for programming BASIC to run on a real Spectrum or under emulation. I'd expect it to do exactly what a Spectrum does.
If you want correct answers - not to mention a faster response - I'd suggest using another BASIC. I hear BBC BASIC is pretty fast... :lol:

I suppose you could try out your BASIC on an emulator with an enhanced version of the spectrum ROM, but that's not the point of BasinC. There are other better BASICs out there. Though some more options over the emulated machine in BasinC would certainly be welcome...
0 x

User avatar
ZXDunny
Microbot
Posts: 133
Joined: Tue Nov 14, 2017 3:45 pm

Re: BasinC oddnesses

Post by ZXDunny » Mon May 13, 2019 6:41 pm

Fahnn wrote:
Mon May 13, 2019 6:18 pm
ZXDunny wrote:
Mon May 13, 2019 6:01 pm
d2010 wrote:
Mon May 13, 2019 5:42 pm
[snip rubbish]
And exactly what would be the point of fixing a broken floating point implementation that yields results different to a real Spectrum?
Because it might be an improvement?

I completely understand the need for verisimilitude but certain things - dare I say it - weren't quite right on the original. You could easily have a marginally bug-fixed version of BASIC along with the original implementation.
I don't think there's any value in having a version of BASin that is incompatible not only with the original Speccy, but nor any other emulator out there. Anything written in it couldn't be run anywhere else.

By all means bugs in the emulation and the BASIC syntax checker could be fixed, but I don't want a version that intentionally breaks compatibility.
0 x

Post Reply