Yes, it is better (except for not supporting RESTORE, READ, DATA). At least the target machine is a ZX Spectrum, and BetaBasic is not a Sinclair Basic too, I guess.
BetaBasic is a superset of Sinclair BASIC, and is available as an extension. To suggest that Sinclair BASIC isn't powerful is to fail to understand exactly how powerful it really is. There are things you can do with it that knock the much trumpeted BBC Basic into a cocked hat.
I never said, Sinclair Basic is not powerful, its just that I missing some advanced commands which are present in ZX Basic or SAM Basic: Binary operations, Procedures, etc.
And I created some games in Sinclair Basic (compiled) like "Indian Patience", "Ultra Reflect",... So I understand how powerful it is. But I have nothing against a bit more power.
Writing in C??? I would never do such kind of thing. Even Retro-X is coded completly in Basic (except for DLL's to handle the scanner input, some API and not much other stuff), and it is still faster than some other converters/viewers done completly in C++. I fact I planed the XIDE to be much like Pure Basic which has binary operations similar to C. There is no reason why Basic cannot have such functions.
About procedures: I'm thinking about Procedures like in SAM Basic (Or Beta Basic): DEF PROC Name(value1, value 2,...). Assigning variables to line numbers is to be compared with labels, and it is not very compatible with compilers.
What's wrong with DEF FN Name(value1, value 2,...)? If it's the equivalent of a VOID then GOSUB will do, otherwise use a FUNCTION.
FN allows only one (complex) calculation, so it does not support special conditions (IF-statements). Sure, GOSUB is a good replacement. I still use it.
DEF PROC on the other side allows to use multiple lines of code and any other BASIC function.
Why not adapt the advantages of modern BASIC languages for the Spectrum, if this can speedup coding of new software?
Not true. It *is* possible to do IFs in a FN using AND, OR and NOT, and it is also possible to do loops. It's just rather tricky.
That's a bit of a bogus argument. By that logic, all Turing-complete programming languages are "perfectly adequate", and we might as well all be programming in Brainfuck instead. The only way to rate one language as more 'powerful' than another is to consider the ease of accomplishing a certain task, so it's entirely reasonable to say that a proper DEF PROC mechanism makes the language more powerful.
That's a bit of a bogus argument. By that logic, all Turing-complete programming languages are "perfectly adequate", and we might as well all be programming in Brainfuck instead.
Writing in C??? I would never do such kind of thing.
Why not? What's wrong with coding in C? In the hands of a good programmer it's as good a language as any! Me? I'm not that good so I prefer to code in C++ myself. ;)
Why not? What's wrong with coding in C? In the hands of a good programmer it's as good a language as any! Me? I'm not that good so I prefer to code in C++ myself. ;)
Maybe because I can`t code in C... I never learned it and I have no real reason to do it if ASM and Basic combination works perfectly (This is the reason why I like Inline Assembler in Boriels Compiler). Sure, you can do anything in Sinclair Basic too (like anything else you imagine), but Copying memory in Basic can take very long time, and LDIR is faster and produces smaller code. Why not to use it? I learned to take advantage of using Basic to code very fast, and ASM to increase speed in critical parts. I do not to code a front end for a game in ASM or C, because Basic works perfectly here.
Writing in C??? I would never do such kind of thing. Even Retro-X is coded completly in Basic (except for DLL's to handle the scanner input, some API and not much other stuff), and it is still faster than some other converters/viewers done completly in C++.
Then the converters you've used are woefully badly written. C (any flavour) will beat your BASIC hands down in terms of speed. Hell, even the Delphi flavour of Pascal that BASin is coded in is orders of magnitude faster than the BASIC you use - while you are resorting to assembler to get speed in critical locations, BASin's converter/paintbox is pure Pascal, which is definitely not faster than a good C compiler.
Then the converters you've used are woefully badly written. C (any flavour) will beat your BASIC hands down in terms of speed. Hell, even the Delphi flavour of Pascal that BASin is coded in is orders of magnitude faster than the BASIC you use - while you are resorting to assembler to get speed in critical locations, BASin's converter/paintbox is pure Pascal, which is definitely not faster than a good C compiler.
D.
I'm not talking about BASin which is great, but I saw a lot of viewers and converters (written in C++ or Assembler) to view Atari XL/XE or ST images, their benchmarks display 2-10 (depending on program) times longer loading/displaying time than mine. But there are programs faster tan mine, I do not deny tis fact. They are written with a lot of C++ Inline Assembly use.
And yes, there are speed problems with the my painter after I changed the code to be Vista-compatible.
Comments
That would be because it's not a Sinclair BASIC compiler:
http://www.worldofspectrum.org/forums/showpost.php?p=261655&postcount=6
D.
Yes, it is better (except for not supporting RESTORE, READ, DATA). At least the target machine is a ZX Spectrum, and BetaBasic is not a Sinclair Basic too, I guess.
I never said, Sinclair Basic is not powerful, its just that I missing some advanced commands which are present in ZX Basic or SAM Basic: Binary operations, Procedures, etc.
And I created some games in Sinclair Basic (compiled) like "Indian Patience", "Ultra Reflect",... So I understand how powerful it is. But I have nothing against a bit more power.
About procedures: I'm thinking about Procedures like in SAM Basic (Or Beta Basic): DEF PROC Name(value1, value 2,...). Assigning variables to line numbers is to be compared with labels, and it is not very compatible with compilers.
FN allows only one (complex) calculation, so it does not support special conditions (IF-statements). Sure, GOSUB is a good replacement. I still use it.
DEF PROC on the other side allows to use multiple lines of code and any other BASIC function.
Why not adapt the advantages of modern BASIC languages for the Spectrum, if this can speedup coding of new software?
That's a bit of a bogus argument. By that logic, all Turing-complete programming languages are "perfectly adequate", and we might as well all be programming in Brainfuck instead. The only way to rate one language as more 'powerful' than another is to consider the ease of accomplishing a certain task, so it's entirely reasonable to say that a proper DEF PROC mechanism makes the language more powerful.
Not really because Brainfuck doesn't have def fn you'd be much better off using Unlambda for unfunctional functional turing completeness ;)
I don't think aowen was suggesting people use Sinclair Basic that way just that it's possible. I did all sorts of silly things on my Speccy.
Interesting, finally a language, "simple" enough for (even) me to understand!
Why not? What's wrong with coding in C? In the hands of a good programmer it's as good a language as any! Me? I'm not that good so I prefer to code in C++ myself. ;)
Bytes:Chuntey - Spectrum tech blog.
Maybe because I can`t code in C... I never learned it and I have no real reason to do it if ASM and Basic combination works perfectly (This is the reason why I like Inline Assembler in Boriels Compiler). Sure, you can do anything in Sinclair Basic too (like anything else you imagine), but Copying memory in Basic can take very long time, and LDIR is faster and produces smaller code. Why not to use it? I learned to take advantage of using Basic to code very fast, and ASM to increase speed in critical parts. I do not to code a front end for a game in ASM or C, because Basic works perfectly here.
Then the converters you've used are woefully badly written. C (any flavour) will beat your BASIC hands down in terms of speed. Hell, even the Delphi flavour of Pascal that BASin is coded in is orders of magnitude faster than the BASIC you use - while you are resorting to assembler to get speed in critical locations, BASin's converter/paintbox is pure Pascal, which is definitely not faster than a good C compiler.
D.
I'm not talking about BASin which is great, but I saw a lot of viewers and converters (written in C++ or Assembler) to view Atari XL/XE or ST images, their benchmarks display 2-10 (depending on program) times longer loading/displaying time than mine. But there are programs faster tan mine, I do not deny tis fact. They are written with a lot of C++ Inline Assembly use.
And yes, there are speed problems with the my painter after I changed the code to be Vista-compatible.
I got directed there from a couple of guys on a sinclair newsgroup, I really never expected the documentation to be quite so extensive.