|
|
|
This thread is locked; no one can reply to it.
|
1
2
|
| GW-BASIC clone with extensions |
|
Evert
Member #794
November 2000
 |
Quote: Here is a list of features that I would have liked to see in the original GW-Basic: - A full range of Hi res screen modes(Super VGA at least) - Access to the sound card, not just the PC speaker You do realise that when GW-BASIC came out most people would have liked to own a computer with the hardware to do that, right? It would have been years ahead of its time (or it might have been an Amiga, I think those things had high-resolution high-colour and decent sound long before PCs did). |
|
Camm Camm
Member #6,876
February 2006
|
Yeah, I see your point. What I didn't like is that qbasic came out and never had screen modes past 320x200 with 256 colors (the dreaded screen 13). At the time we would have really liked a screen mode with 640x480 with 256 colors, with bitmap and sound card support. So for Steves project I guess some extra screen modes and sound card support go without saying. I just really liked those early days, before hardware specifications went throught the roof, where the indie programmer, even in basic had a chance to make something playable not laughable {^_^} |
|
Evert
Member #794
November 2000
|
Quote: What I didn't like is that qbasic came out and never had screen modes past 320x200 with 256 colors (the dreaded screen 13). At the time we would have really liked a screen mode with 640x480 with 256 colors, with bitmap and sound card support. QBasic came out in 1991. While SVGA was around at the time, it was definately not a standard feature in consumer PCs. Same for sound cards. |
|
Steve++
Member #1,816
January 2002
|
Everything up to VGA, which is 320x200x256 and 640x480x16, is industry standard. Beyond that, manufacturers made their own standards which the industry collectively labelled Super VGA (or just SVGA). Although the screen modes were pretty much the same (eg. each SVGA adapter could do 640x480x256), the hardware interface to program these adapters wasn't standard at all. This is because video memory is mapped into the first 1MB of memory (the only region of memory directly accessible from 16-bit DOS applications), but there wasn't enough space to map the whole video buffer to real-mode RAM. Manufacturers decided to devise their own workarounds without first standardising, presumably to get an advantage over competitors. Eventually enough companies came together to support the VESA standards (1, 2 & 3, and some sub-versions I think). The VESA standards allowed DOS programs to gain access to these video cards through a common software interface. I think this all came after QBasic anyway. QBasic in its days supported all the modes guaranteed to be available on a VGA system. |
|
Audric
Member #907
January 2001
|
I'd advise against the line numbers, they are an artifact from another time... Unless you want to write a complete text editor, you can safely assume every programmer will use one of those good free text editor, and customize syntax highlighting to your Basic variant, so the second usage is moot. For the first usage of line numbers (target for GOTO), custom labels are way more human-readable... And from the parsing point of view, there is no difference between storing the goto targets as numbers or string - you'll check they are unique the same. (line "100" or label "start_of_loop") Check and see, but I'm pretty sure you'll soon accept line numbers as compatibility only, since: can be parsed and stored in-memory exactly like: 10: Either way. It's YOUR Basic, so don't feel forced to make it support exactly the same syntax as another's |
|
Michael Jensen
Member #2,870
October 2002
 |
Quote: I'd advise against the line numbers, they are an artifact from another time... You can't have GW-BASIC without line numbers -- commands typed in without line numbers execute immediatley -- which is the correct behavior because otherwise GW-BASIC would have no idea where to store your code. Hence, QBASIC > GW-BASIC. -- However, if you wanted to support scripts without line numbers, you could simply add them in on load (You could have a command to set the default transposition) -- with that approach you could also do a lot of other powerful things like load two programs into memory at once, transposing the line numbers of one program to proceed at the end of the first program... Of course for goto to work on a file with line numbers to be added in after the fact, you might want to allow multiple labels per line 10 labelish: goto labelish anyway, my head is in the process of exploding -- later.
|
|
|
1
2
|
