Talk:BASIC
D-English/ Poor Translation Services[edit source]
I dont't know who translated this, but I suppose it was one of the many poor automatic translating servives available in the internet. I think I corrected 80% of the most awkward "Denglish" sentences. But in some cases I cannot even guess the German meaning, so that I am not quite sure, whether the translation is corrupt.
- "BASIC 3.5 build off the Commodore BASIC version 2.0 and is in the homecomputers C16/116 and Plus/4 integrated:" <-- EDIT: DONE, think I could handle/correct it.
- "Build off the Commodore BASIC version 3.5, which is integrated into the C128/D/DCR zum:"
I am German, so I recognize German syntax lousily translated into English without re-arranging word-order. But I can't make anything of it. I have no clue in what way "to build off" is to make any sense in that context.
EDIT: Okay, now I have checked the German article. The first example was just a bad translation. The 2nd example doesn't even make sense in the original, so I changed some expressions in the German C64-WIKI too. But I think it would be necessary to check whether my (hopefully) gramatically better translation is semantically adequate. I am confident it can't be worse than before, but I do not know much about C128 or C16+4.
I have a feeling that the article is still barely acceptable. We should work on it, since it is (imho) an essential article which many users will check. And the first impression is very important if we want this platform to be visited by many users regularly.
Keep in mind: The translating services availabe as software at the moment are bad altogether! Using those services is a bad idea, because the correction of such "translations" can cause more trouble than any translation without those tools. 1:1 translations almost never work. I advise you all to use LEO and be aware of English syntax and grammar. --TheRyk 02:09, 30 July 2008 (CEST)
- Sorry, but i didn't used a translation machine. I translate directly and use leo.org many years. And as a german native speaker, write I often the english sentences with to much german grammar. But i want to power up the C64-Wiki.com and I hope, that english native speaker find this c64-wiki. --Jodigi 01:40, 31 July 2008 (CEST)
- Don't apologise for being German, so am I as you know, and it's not our fault ;) , no offence intended by me, anyway. But an easy way to avoid the mistakes you mentioned (German grammar) and to improve your English is to stick strictly to the standard English word order: Subject --> Predicate --> Object, whenever you are not sure. For example, the 2nd sentence of your reply would have to be corrected into:
- "I often write the English sentences with too much German grammar."
- A very raw syntactical analysis would look like this:
{I <--Subject} {often <--Adverbial} {write <--Predicate} {the English sentences with too much German Grammar. <--Object}- The position of the adverbial is a matter too complicated to explain here, it can vary. But I hope, you understood my point.
- As a rule, this word order is also needed within dependent clauses (German: "Nebensätze) which always feels a little strange for German speakers at first. --TheRyk 14:52, 3 August 2008 (CEST) (last update)
- Don't apologise for being German, so am I as you know, and it's not our fault ;) , no offence intended by me, anyway. But an easy way to avoid the mistakes you mentioned (German grammar) and to improve your English is to stick strictly to the standard English word order: Subject --> Predicate --> Object, whenever you are not sure. For example, the 2nd sentence of your reply would have to be corrected into:
Formatted input/structures?[edit source]
I recall a friend becoming very excited when he discovered that our PET 4032's had a way to define a structure so that a whole set of variables could be read or written in a single command. He used this in a text adventure to handle room data, greatly simplifying that code.
Looking over the commands here, I cannot find this. I thought of RECORD, but this appears to simply position the pointer. Is this perhaps the command in question? Or is there another that does this that I'm overlooking?
99.232.61.177 16:29, 25 April 2018 (CEST)
Code size[edit source]
Does anyone have a reference to the size of the original version of BASIC, or any of its versions? I'm trying to make a chart of the variations of the original MS code, so PET, Apple, etc. I know AppleSoft was 10,800 bytes. Maury Markowitz (talk) 19:58, 11 February 2020 (CET)
Ahh, I found the list of ROM addresses. That gives me 8k for BASIC. How big were the rest of the ROMs that made up "the system" on the original PET? Maury Markowitz (talk) 20:14, 11 February 2020 (CET)
- Even the original PET has 2x 8 KByte ROMs. They are referred as BASIC and KERNAL but BASIC (with floating point, flexible strings and multidimensional arrays) needs more than 8 KByte, actually around 10 KByte. From the 16 KByte ROM space of a PET, CBM 3000, CBM 4000, VIC 20, C64 (a typical BASIC V2 class systems) they have all more or less the same partitioning with 10/6 KByte for BASIC/KERNAL. As far as I know only integer BASIC (without floating point routines) is able to fit into 8 KByte ROM. For exact data I would suggest to look into the ROMs (look in to available ROM listings or directly into the ROMs provided with emulators like VICE). There are several history related articles around, like http://weblog.hansotten.com/microsoft-basic-computer-archeology/ which might offer some hints on the size the interpreter has - or at least provides a starting point for further investigations. --JohannKlasek (talk) 21:43, 11 February 2020 (CET)
- Useful Johann, thanks. Is there a table of this somewhere that lists the bits and pieces of the other 8k of ROM? I'm particularly curious about the math, as the Atari also separated that out of their 8k BASIC so it would be possible to do a head-to-head comparison. Maury Markowitz (talk) 15:03, 12 February 2020 (CET)
- I'm not sure if I understand what you are heading for. You mean Atari calculates their BASIC interpreter size without the floating point routines? If we take the C64 ROMs (http://unusedino.de/ec64/technical/aay/c64/basromma.htm) most floating point stuff begins around $B800 (in the area from $A000 to $BFFF). Therefore main BASIC part consumes around 6 KByte, the float routines ($800 in BASIC ROM and $400 in KERNAL ROM) take 3 KByte and the KERNAL itself comes up with 7 KByte. Just to be correct: My above statement should rather to be changed to a 9/7 partitioning. But there is no exact line to be drawn. BASIC and KERNAL part are intermixed on several locations. --JohannKlasek (talk) 15:52, 12 February 2020 (CET)
- Useful Johann, thanks. Is there a table of this somewhere that lists the bits and pieces of the other 8k of ROM? I'm particularly curious about the math, as the Atari also separated that out of their 8k BASIC so it would be possible to do a head-to-head comparison. Maury Markowitz (talk) 15:03, 12 February 2020 (CET)
Atari had designed its machines to use 8k cartridges, which was too small for BASIC. So they put the FP routines into a separate 2k ROM on the motherboard. So BASIC was really about 10k (a little less IIRC, ~7800 + ~1780). This compares well with AppleSoft at 10800 bytes. I'm trying to get the corresponding size of the PET version. Looking at the original MS source code, any version using the 40-bit FP format, which the PET does, should be around 9k, not including any platform-specific additions (like LOAD or such) So from your reply, it appears the answer is "about 9k". That does seem a little small given that there were a few additions like pi and the cassette (although I assume the actual code there is in the KERNAL?) I understand that they did change some of the FP though... the multiply routine IIRC? Maury Markowitz (talk) 17:51, 12 February 2020 (CET)
Questionable claim that BASIC is still used because of its userfriendliness[edit source]
For three reasons I think this claim is just wrong.
1. BASIC in any form has not been used in any significant amount for several decades 2. BASIC was never friendly towards its users 3. Modern BASICs are not at all similar to the BASIC used on the C64.
I'm going to remove the claim on these grounds.