Page 1 of 2

BasinC oddnesses

Posted: Mon May 13, 2019 5:14 pm
by Fahnn
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.

Re: BasinC oddnesses

Posted: Mon May 13, 2019 6:24 pm
by Einar Saukas
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...

Re: BasinC oddnesses

Posted: Mon May 13, 2019 6:29 pm
by Fahnn
Einar Saukas wrote: Mon May 13, 2019 6: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).

Re: BasinC oddnesses

Posted: Mon May 13, 2019 6:42 pm
by d2010
Fahnn wrote: Mon May 13, 2019 5: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.
Spoiler

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;
Spoiler

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;

Re: BasinC oddnesses

Posted: Mon May 13, 2019 6:58 pm
by Fahnn
d2010 wrote: Mon May 13, 2019 6:42 pmThis 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.

Re: BasinC oddnesses

Posted: Mon May 13, 2019 7:01 pm
by ZXDunny
d2010 wrote: Mon May 13, 2019 6: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?

Re: BasinC oddnesses

Posted: Mon May 13, 2019 7:04 pm
by Joefish
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.

Re: BasinC oddnesses

Posted: Mon May 13, 2019 7:18 pm
by Fahnn
ZXDunny wrote: Mon May 13, 2019 7:01 pm
d2010 wrote: Mon May 13, 2019 6: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.

Re: BasinC oddnesses

Posted: Mon May 13, 2019 7:34 pm
by Joefish
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...

Re: BasinC oddnesses

Posted: Mon May 13, 2019 7:41 pm
by ZXDunny
Fahnn wrote: Mon May 13, 2019 7:18 pm
ZXDunny wrote: Mon May 13, 2019 7:01 pm 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.

Re: BasinC oddnesses

Posted: Mon May 13, 2019 7:49 pm
by Fahnn
Joefish wrote: Mon May 13, 2019 7: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.
Yeah. I guess I didn't really think about this properly. I'm not normally this dense but sometimes I get a bit frustrated.

I'd still be interested to know why some of my lines go missing though. I still can't figure out what's causing that. Possibly it's just me.

Re: BasinC oddnesses

Posted: Mon May 13, 2019 8:00 pm
by Turtle_Quality
BasinC is an emulator with a brilliant front end, that apparently has line number issues some times.

It's not made to improve Spectrum basic, but to make it easier create Spectrum Basic. If you made your porn simulator with a tweaked rom, you'd likely be the only one playing it, and the world would not be quite so culturally enriched.

There are altered ROMs out there, I found a list here http://zxspectrum.it.omegahg.com/_48.htm

In the docs for the most well known, Gosh Wonderful Rom the division issue was discussed and the author decided it was not a bug and should not be fixed. It looks like the Plus4 Rom does fix it but also makes a host of other improvements that you might not want or would likely interfere with BasinC.

For what it's worth, I remember banging my head on the desk as a 16 year old because the simplest basic line wasn't working correctly... until I realised it was the Spectrum that was getting the answer wrong.

Re: BasinC oddnesses

Posted: Mon May 13, 2019 8:02 pm
by Turtle_Quality
Ok seems while researching my answer the conversation had left me behind :)

Re: BasinC oddnesses

Posted: Mon May 13, 2019 8:15 pm
by ZXDunny
Fahnn wrote: Mon May 13, 2019 7:49 pm
Joefish wrote: Mon May 13, 2019 7: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.
Yeah. I guess I didn't really think about this properly. I'm not normally this dense but sometimes I get a bit frustrated.

I'd still be interested to know why some of my lines go missing though. I still can't figure out what's causing that. Possibly it's just me.
I doubt it. There are some pretty nasty bugs in BASin, and it's not been left in a very good state, at least originally.

I have no problem with BASin supporting modified ROMs, but it will require a rebuild of BASin as it hooks x86 code directly into the ROM to do what it does. If anyone wants to do that, I have no issue with it - as long as it still supports the original ROM.

Re: BasinC oddnesses

Posted: Mon May 13, 2019 8:31 pm
by Fahnn
ZXDunny wrote: Mon May 13, 2019 8:15 pm
Fahnn wrote: Mon May 13, 2019 7:49 pm Yeah. I guess I didn't really think about this properly. I'm not normally this dense but sometimes I get a bit frustrated.

I'd still be interested to know why some of my lines go missing though. I still can't figure out what's causing that. Possibly it's just me.
I doubt it. There are some pretty nasty bugs in BASin, and it's not been left in a very good state, at least originally.

I have no problem with BASin supporting modified ROMs, but it will require a rebuild of BASin as it hooks x86 code directly into the ROM to do what it does. If anyone wants to do that, I have no issue with it - as long as it still supports the original ROM.
I really appreciate your answers here and please don't make any changes on my account. My frustrations were borne of ignorance and I know that anything I'm finding problematic can easily be worked around. I'm still kind of new to this, and it's amazing to find that there are easier alternatives to programming on an emulator, to be honest. Basically (pun intended), ignore me.

Re: BasinC oddnesses

Posted: Mon May 13, 2019 8:53 pm
by ZXDunny
Oh, I don't ignore people - I do listen, but I have strict criteria as to what BASin is, and what it can do. I will be going back to it at some point and fixing the bugs - once I've gotten bored of SpecBAS, that is. I've a ZXSpin re-write on the cards too, and that will likely be getting all of BASin's functionality embedded in there too.

So much to do, so little time. But SpecBAS comes first.

Re: BasinC oddnesses

Posted: Tue May 14, 2019 9:18 am
by hikoki
Fahnn wrote: Mon May 13, 2019 5:14 pm 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.
A couple of things that seem to alleviate this issue: Press control+z and your lines will reappear. Press Enter often, above all before navigatigating through lines with cursors when you are still editing the current line.

Re: BasinC oddnesses

Posted: Tue May 14, 2019 9:31 am
by ZXDunny
Ah, I know what's going on there. BASin works on the code held in Spectrum RAM - it doesn't store it as text anywhere while editing. If you don't press ENTER to submit the line, then it doesn't exist. There may be other bugs. As I said previously, I'll look into it when I get time.

Re: BasinC oddnesses

Posted: Tue May 14, 2019 12:58 pm
by Joefish
That explains why the saving is done as a snapshot (although it's not always a reliable one!)
I always take care to save a text copy of the listing in case I can't recover the snapshot.
It's a great tool, and it's handy for writing editors for Speccy graphics and data in BASIC for games (particularly if you transfer them to ZXSpin and whack the speed up). Then you can load the machine code in to display and test your graphics alongside the BASIC editor you've written.

Re: BasinC oddnesses

Posted: Tue May 14, 2019 6:17 pm
by Fahnn
Thanks to everyone for the replies, there's a lot here that I'd not considered and will bear it all in mind. Obviously I'm going to persevere with it, I do genuinely think it's great. It might seem trivial, but not having to remember where all the keywords and symbols are is such a time-saver in itself!

Re: BasinC oddnesses

Posted: Sat Aug 17, 2019 7:14 pm
by Fahnn
OK, here's an odd one. I've been messing with something for the last couple of days and saving it as a .bas file. Everything was fine, the file was saved and re-opened probably ten times or more with no problems, until today. Attempting to open it does nothing, there is apparently no program.

It's not actually a problem as I have a .txt listing of what I'd written so far (interestingly, I got this from uploading the .bas file and then trying to download it; instead of a download, I got a text listing of variables from its last run and then the entire program, which was helpful).

I'm a little bit wary of using BasinC again if this kind of thing is going to happen. Prior to this I'd only had lines going missing (or randomly re-numbered) and I could deal with that, but potentially losing entire programs is another issue (even though it's possible to get them back, it's a pain to have to do that). It's a shame because I think it's generally a really great environment for writing BASIC.

Tell me what I'm doing wrong. I must be doing something wrong.

Re: BasinC oddnesses

Posted: Sat Aug 17, 2019 7:44 pm
by hikoki
Did you rename the file with a really long name?
Something like that happened to me after renaming, Basinc erased the content not only in ram but also on the saved file.

Re: BasinC oddnesses

Posted: Sat Aug 17, 2019 7:59 pm
by Fahnn
hikoki wrote: Sat Aug 17, 2019 7:44 pm Did you rename the file with a really long name?
Something like that happened to me after renaming, Basinc erased the content not only in ram but also on the saved file.
Nope, it was called "d".bas. Maybe too short names also mess it up!

Re: BasinC oddnesses

Posted: Sun Aug 18, 2019 8:08 am
by ASH-II
As the author of BASin has said it might have a few bugs and it will be fixed but not yet (and he is hinting it will be merged into a shiny new Spin :) )

so if you are having an issue with saving then save as a .bas and before you exit basin just copy the text into notepad and save that.
if the .bas fails (1 in 10 chance) then paste the text from the saved notepad. nothing has been lost.

As you yourself say the advantages to using BASin far outway a little save/load glitch.

Re: BasinC oddnesses

Posted: Sun Aug 18, 2019 2:36 pm
by llewelyn
Mine won't work at all and I don't know why. I downloaded it, installed it into my Programs folder and it comes up when clicked but all the directories show up as names, such as 'welcome' but have a question mark where the icons are and clicking on them gets an empty screen! Its been unzipped properly and checking file size shows that there's something there alright. So frustrated, I just leave it in place, hoping someday perhaps I'd find a solution.

Oddly enough the first time I used it a couple of years ago, it all worked properly! Computer weirdness beyond my ken.