|WikiProject Video games||(Rated Start-class, Low-importance)|
- 1 Influence on other BASICs
- 2 Inside Atari DOS
- 3 Versions
- 4 Wrong information
- 5 MS basic issue
- 6 "Intermediate Mode"?
- 7 How to find out what revision it is?
- 8 Character Set
- 9 Great article
- 10 Proposed split to Atari 8-bit operating system
- 11 Comparing floating point implementations
- 12 Embedding machine language
- 13 No need to repeat hardware info here
- 14 Article cannot be properly printed as PDF anymore
- 15 Unfortunately, quite some errors and misinformation
- 16 Attempt at getting this back under control
Influence on other BASICs
I've added the removed section and included a ref. for discussion. It would be most helpful to show sources and data to allow this section to stand without dispute. An example would be college curriculum or other training that makes use of the Atari BASIC source code. --Pelladon 21:54, 23 April 2006 (UTC)
You reworded parts of the introduction I wrote because of supposed speculation, which is understandable. However I have strong evidence for this thesis. If I publish, together with a friend of mine (who has also done a lot of research about these things), a short essay on his web page about what we found out, would that be sufficient to include it again? Or is such practice forwned upon? --Rtc 21:33, 23 April 2006 (UTC)
- If you have sources, I have no problems with that. I was only putting in info that was verifiable and sourced. I have a lot of info that I cannot include because I can't source it. That's how things work. --Pelladon 21:43, 23 April 2006 (UTC)
- Do keep in mind, Wikipedia does not condone original research - Wikipedia:No original research --Pelladon 22:22, 23 April 2006 (UTC)
Yes, I know. But the question was, if it is okay to simply publish it on a web page and then refer to that web page as a source? Perhaps you can do so for your information, too? --Rtc 10:48, 24 April 2006 (UTC)
- As long as it's not original research. Best to use a referenced source (original articles and documentation, for example). --Pelladon 19:14, 24 April 2006 (UTC)
It would most certainly be original research to publish it on the web page. Any information has been original research at one point in time. For example Wikipedia is citing academic journals all the time and there is clearly original research going on in there, isn't it? I mean you could refer to the web page then as a source. Why wouldn't that be okay? How exactly do I need to publish it in order for Wikipedia to accept it as not being original research? Or is original research conducted by wikipedians forbidden to be cited in wikipedia? Scientists have to be careful then not to register at Wikipedia if they want their theories being cited here ;) --Rtc 00:24, 25 April 2006 (UTC)
- Just read this, use it as a guideline, okay? - Wikipedia:No original research. Before you do anything, show the sources so everyone can take a look first. --Pelladon 03:21, 25 April 2006 (UTC)
That doesn't quite answer my question. WP:NOR#The role of expert editors and WP:NOR#What counts as a reputable publication? shows that I'd need to publish my original research thesis in a reputable publication, but it does not say whether a website would be considered a reputable publication. I see websites being used as sources all over the place and most of them are surely personal efforts on some topic to just state obvious views that would otherwise be considered original research. Most if not all of them have not been peer reviewed. Perhaps you know some 8 bit magazine still active today in which I could publish the stuff? Perhaps that might be more considered a reputable publication than some random web site? --Rtc 13:16, 25 April 2006 (UTC)
- Don't make such a big deal out this, just show the sources first and then take it from there. --Pelladon 15:04, 25 April 2006 (UTC)
Please get it: There are no sources I can show, because it is original research. The question is what I can do to make the theory (that is now original research), to be a theory that is not original research in the wikipedia sense. --Rtc 15:18, 25 April 2006 (UTC)
- Put it in the Atari BASIC discussion page, not on the main page itself. --Pelladon 15:21, 25 April 2006 (UTC)
But the nor policy says "If an expert editor has published the results of his or her research elsewhere, in a reputable publication, the editor can cite that source" but the discussion page is not 'elsewhere' --Rtc 15:27, 25 April 2006 (UTC)
- By putting it in the discussion page, this allows others to look at it and give suggestions. Part of the process. Please put the discussions on the appropriate page, not on my home page. Thanks. --Pelladon 15:34, 25 April 2006 (UTC)
Not only Wikipedia does not publish original research, it also does not conduct it, according to the WP:NOR policy you directed me to. But "putting it on the discussion page" to allow "others to look at it and give suggestions" would be conducting original research! I see you cannot really help me with the problem. --Rtc 15:41, 25 April 2006 (UTC)
- No, it's asking others how to proceed with this. BTW: You still haven't shown anything (source, info) to debate about. --Pelladon 15:57, 25 April 2006 (UTC)
There is no source. The original research information consists of an object code spectral analysis, which can show at least the Frank Ostrowski BASICs (even those for the Atari ST) to use exactly the parser architecture of ATARI BASIC. Since Turbo Basic still uses the file format of ATARI BASIC, the relationship is obvious. Those people with a deep knowledge of M68K GFA BASICs (Atari, Amiga) and its file formats also know that they are basically still intentical in architecture to ATARI BASIC. I am not saying that source code has been copied, but merely the architecture. --Rtc 16:16, 25 April 2006 (UTC)
- This is your last warning. Any discussions of Atari BASIC needs to go to the Atari BASIC discussion page, not my home page. --Pelladon 16:23, 25 April 2006 (UTC)
Inside Atari DOS
I added a reference to this (webbed) book, which has a brief account of the development of Atari Basic. It conflicts somewhat with the article - for one thing, it says that Atari Basic was spec'ed for 10K, not 8K. Mirror Vax 01:48, 27 May 2005 (UTC)
- It could have been Atari giving them (SMI) some leeway in size since Atari themselves were having problems fitting MS Basic into 8K. (Atari originally designed their system with 8K allocated to BASIC, before BASIC was developed). And they needed it fast. All moot of course. --Pelladon 17:05, 23 April 2006 (UTC)
Might help to have a section describing the three versions, Revision A, B and C. Never mind :D --Pelladon
BTW: There's a line stating that Atari BASIC was patterned after Data General's BASIC. Is there any valid source for this info? Since when did Shepardson Microsystems get it inspiration from Data General? BASIC dialects were in the hundreds or more. Thanks. --Pelladon 03:08, 9 July 2006 (UTC)
- No, there's a line saying that AB's strings were similar to those DGB, which is an obvious truism. They are also similar to C, for example. This whole article needs a massive re-write. Battling editors have managed to take what was essentially a pared-down version of my AB:GBU article and mangled it into an almost unreadable mess, while misleading the reader that the article is actually taken from other sources. Maury 20:01, 19 December 2006 (UTC)
- Oops, my bad, I see the reference you're talking about now. Oh well, all fixed now. Maury 21:50, 19 December 2006 (UTC)
There are some wrong informations in the article. I don't edit myself because my English is not very good:
In Atari BASIC, "P." does not expand to "PRINT" as the article claims. It expands to "POINT". Probably because "PRINT" has already "?" as abbreviation. "PR." is not much longer anyway.
The strings does not start at "location zero" as the article claims, but at location 1. So no compatibility problems are present because of that.
Two dimensional arrays do exist in Atari BASIC. Although not for strings.
Finally, "INPUT D:" will not input from disk, "INPUT #1" will, if I/O channel 1 is open for disk input.Cyco130 07:55, 30 January 2007 (UTC)
- Feel free to fix - I was going on many-years old memory there. Or would you like me to do these fixes? The string one is just wrong, the problem is at the "other end" when you're specifying lengths, like in MID$. Maury 13:14, 30 January 2007 (UTC)
- You cannot access a Atari BASIC string variable with a zero subscript, you get a Error- 5 (string length error).—Pelladon 08:45, 16 February 2007 (UTC)
MS basic issue
"Six months and many man-hours later, they were almost ready. But Atari had a deadline with the Consumer Electronics Show (CES) approaching and decided to ask for help."
Is this accurate? I'm curious, because I have a direct statement (in e-mail) from Bill that their stuff was 12 k and showed no signs of getting any smaller when OSS was called in. The statement is part of a larger history so I can't be sure he's talking about the same point in time that the article is, but I don't believe it is inaccurate. Another point to consider is that although the machines were announced at the CES, they didn't ship for another year (almost). If the MS version was that close, I simply can't see them going to OSS just for the CES, when they would already know they had lots of time. And finally, I seem to recall the MS version in the PET being about the same size too.
- sigh* If only they connected the whole 16 k to the "left" cart, all of this would be moot.
Maury 16:05, 14 February 2007 (UTC)
- It was from Bill Wilkinson, Atari cut out a lot from MS Basic to get it to fit in 8K. They were better off going with Atari BASIC from Shepardson. 8KB is very limiting for any BASIC. Can't do much with 8KB.—Pelladon 08:42, 16 February 2007 (UTC)
- No, I'm referring to the timing. Bill was the one that told me it was still 12k when OSS got the contract. And seeing that the MS basic they did release was later (12k?) I'm somewhat skeptical about the history. Maury 13:31, 16 February 2007 (UTC)
Just FYI, Commodore BASIC 2.0 (which is based on an almost unmodified Microsoft 6502 code base) is very close to 9K in size. Applesoft BASIC (which has a few extensions) is 10K. In both cases not counting the OS but the BASIC itself only. Applesoft BASIC was specifically made from the Microsoft code base because that was a quicker thing to do than to extend Steve Wozniak's Apple Integer BASIC with floating point. So I doubt the Microsoft code was that hard to get down somewhat smaller than 12K, but 8K seems to have been a problem. -- 220.127.116.11 (talk) 13:36, 1 May 2009 (UTC)
How to find out what revision it is?
This section has little to do with Atari BASIC. It's related to ANTIC and the Atari OS. The alternate character set is part of the XL/XE OS ROM, not Atari BASIC "C" ROM. — Pelladon (talk) 18:05, 29 July 2009 (UTC)
- I agree, but as far as I know there is no article on the Atari 8-bit OS. The section on the CIO thus is longer than it need be, for the same reason. I don't know if we can sensibly make a case for a split-out when there is considerable interaction between the two yet not really enough stuff to support a separate article. SimonTrew (talk) 23:02, 3 September 2009 (UTC)
Proposed split to Atari 8-bit operating system
I have added a section, unfortunately unreferenced as yet, about the Graphics system. At this stage, with a fairly lengthy section on the CIO as well, I think it is time to propose a split to Atari 8-bit operating system, taking in the majority of those sections, since really the Atari BASIC is nothing more than thin wrappers onto the OS facilities.
I realise that the graphics section also starts off with a discussion of the hardware, which I think inevitable if it is to make any sense in context, but this might also have some bearing on splitting content from this article into a hardware article (e.g. at Atari 8-bit family). I note there is already an article at ANTIC and I should probably merge some of this preamble into that, since it gives a more general overview of e.g. sprites (Player/Missile Graphics) though I should like to tie more details down (specific register memory mapping and so on), but I think there is useful content in there.
So, I am a little vague at the moment on proposing exactly what sections to split out, but would like to get opinions, and consensus, on whether in principle we should split out for the operating system proper. This may mean that afterwards, for example, Turbo BASIC XL and other BASIC varieties are proposals for a merge, but we can leave that until later.
- Agreed, much of what is in the article really has nothing to do with BASIC. As there seems to be no pushback on the split, I'd be happy to do it. Maury Markowitz (talk) 12:47, 22 March 2010 (UTC)
- I'm happy for the material that isn't specific to Atari BASIC (i.e. the bits that relate to OS facilities in general) to be moved to a new or existing article if more appropriate. The BASIC article should still, of course, note the relevant parts in passing, with inline or "mainarticle" links to the full version.
- As to whether (e.g.) Turbo BASIC XL should be merged into Atari BASIC... not sure. It depends on whether one considers it an expanded variant of Atari BASIC or a language in its own right, and also whether there is (potentially) enough to be said about it separate from Atari BASIC to sustain a non-stub article. Ubcule (talk) 23:48, 4 March 2011 (UTC)
- There appears to be consensus for this split, so please action it. I took a look, and it is not clear to a non-specialist what to split out, as there isn't a clearly defined 8-bit operating system section, so I have removed the general split request tag. This needs to be done by those who understand what they are doing. If the split is not going ahead, then I suggest raising the issue on appropriate WikiProjects. 12:38, 15 March 2011 (UTC)
Comparing floating point implementations
Where can I find an essay comparing floating point on the Atari 800 with floating point on the Apple II and on the Commodore 64?
The main article is very interesting but I am looking for the exact location of the sign bit on floating point numbers used for 6502-based computers of the 1980s. That means the Commodore 64, Atari 800, and the Apple II+. I am already aware of the fact that the Commodore 64 and Commodore 128 both used 5 byte floating point (with two more bytes used for the name of the floating point variable). Is there a place on Wikipedia that already compares these floating point implementations against each other? If Wikipedia doesn't have it, I am willing to go to a website somewhere else, or even to a non-internet BBS if I have to. Dexter Nextnumber (talk) 00:25, 15 February 2010 (UTC)
- If someone has information on floating point used in BASIC for a PC compatible of the 1980s, that would be interesting too, but ultimately not very useful to those of us bent on software maintenance (porting software from one 8 bit platform to another 8 bit platform).
- Does anyone know whether there is a publication or newsletter somewhere that warns us, or otherwise attempts to standardize, where the sign bit is, or the other fairly interesting bits (like flags for NAN, Zero, High, Low, and so on)? The main page of the article lacks a detailed discussion of Atari 800 floating point. I, for one, would find that information interesting. Dexter Nextnumber (talk) 00:32, 15 February 2010 (UTC)
- Well I imagine for PC compatibles one should start by reading up on the 8087. Before that, it was done in software. The Intel 8087 was before IEEE 754-1985 (it had, for example, projective infinities as well as affine ones, if I recall correctly) and of course Intel contributed hugely to IEEE 574. I remember reading some very in-depth article about this about fifteen years ago that said how hard they had to kinda push their own implementation, but at the same time not reveal the details of the implementation – i.e. keep it as a specification – both because that is what it is and because they wanted to keep their tricks up their sleeve.
- I remember the manual for the 80287 and it told you the min and max cycles of each instruction. Of course it was a stack-based implementation. It told you the average, too, but this seemed always to be the median of the min and the max, so I didn't trust it too much. The manual was about two inches thick of ?foolscap, whatever that American size is 8x11 inches.
- Atari 8-bits used 6-byte BCD, 1 byte (two digits) for the decimal exponent and 5 for the decimal mantissa. This was relatively slow, but I guess (it is a guess) was expedient because the 6502 had a BCD mode for addition and subtraction on the processor. I believe that Turbo BASIC XL used a base 2 representation (i.e. not BCD), but I am not sure: it certainly speeded up the numerics a lot, but that may have been through simple optimisations that prevented the needless and stupid storage and conversion of integers to and from floating point (for example, for line numbers in GOTOs, or array indices).
- Amazingly (at least to me), the article on the Z3 (computer) says that a binary FP implementation was built mechanically! Considering that I think base-10 to base-2 conversion and vice versa is rather tricky (not in theory but in practice) I find this astonishing.
- What is also quite amazing really is that most cheap digital calculators still use the old 4-bit processors. Digital alarm clocks, too, of course: When you think about it, beyond a very thin surface, every digital alarm clock you have ever used has the same functions and workings as when they first came out over thirty years ago. For example they still set the alarm to 12 midnight by default, and the time to 7am (I think) – those being of course the exact opposite of what the defaults should be!
- Best wishes
- I do believe the Commodore series of 8 bit computers used something known as a "signed byte" in lieu of a sign bit - inasmuch as there being no particular sign bit, you are supposed to treat $ff as a minus one, $fe as a minus two, and $fd as a minus three, and so on. The extra effort being worth the extra bit of precision. If I hadn't abandoned CBM BASIC 2.0 in 1984 (in favor of assembly language), I would have known the answer to this, and not have to have bothered anybody here. Dexter Nextnumber (talk) 03:29, 16 May 2010 (UTC)
Embedding machine language
This paragraph is written in an astoundingly unencylopedic fashion, and really needs a rewrite:
- On the 6502, relocation is not trivial. These days we expect programs to sit pretty much anywhere in memory; the loader and processor collaborate to make that happen. But microprocessors of that era did not do that. The 6502 was especially hindered by having very few indirection instructions, and those it had were asymmetric: the X and Y registers indirect in different directions. This leads either to rather clumsy code that is forever moving stuff between registers, or clever but obtuse code that keeps them where they need to be even if it would seem more obvious to stick something else there. The 6502 instruction set is small enough that, over a short time, programmers can model the entire processor in their heads, even down to knowing how many cycles each instruction takes, and then start making clever tricks.
- Furthermore, this entire section is loaded with continual attempts to relate the subject matter to modern software techniques, which just bloat the article, add nothing to understanding, and make the whole thing harder to read. Clayhalliwell (talk) 23:08, 25 March 2010 (UTC)
- Actually, expand that sentiment to all the sections that Mr. Trew is editing. He's making a real mess of the article, with cutesy unencylopedic language, irrelevent detail, and some statements that are just flat-out wrong. I suppose I'm going to have to clean all this up later. It's seriously bordering on vandalism. Clayhalliwell (talk) 23:39, 25 March 2010 (UTC
- I agree that relocation is not trivial. That is one of the points in favor of certain kinds of copy protection: making it difficult for unknown third parties to come along, years after the fact, and have the audacity to disassemble it, let alone try to move the programs to places they were never meant to execute. Maybe modern users want to get their hands on '"free" software, and are angry with the original author for having put it where he did. Maybe not. Dexter Nextnumber (talk) 03:31, 27 March 2010 (UTC)
- I note that User:Clayhalliwell has made precisely 0 edits to the article since posting the above comments. I do agree it needs a lot of work. Unfortunately nobody else seems much interested in the article, so I have to more or less take it in the direction I see fit. The biggest jobs to do are to split the operating system information out from the BASIC section, and then to get references from De Re Atari and from Wilkinson's BASIC manuals. Adding references would be a great help and no doubt would also tidy up some errors.
- That being said, I disagree with the article being bloated, beyond the inclusion of the OS and hardware sections, which I think belong somewhere because without them the whole structure of the BASIC language and implementation becomes meaningless. They would be better off in a separate article, but we have to walk before we can run. Si Trew (talk) 14:51, 26 June 2010 (UTC)
No need to repeat hardware info here
Details about Player/Missile graphics and how Antic works and all that is already in the main article about the Atari 8-bit computers, so why duplicate it here?
Article cannot be properly printed as PDF anymore
Dear all, thanks a lot for this great article.
I was trying to gather a few Atari-related articles when I noticed that this one cannot be properly printed in PDF format anymore.
Print Export > Download as PDF
produces the following error message
WARNING: Article could not be rendered - ouputting plain text.
Potential causes of the problem are:
(a) a bug in the pdf-writer software
(b) problematic Mediawiki markup
(c) table is too wide
As a result, the page is unformatted, and all the text is printed in a single giant paragraph, without CR.
Can anyone figure out what's wrong in the formatting of the current version of the page (Aug 2011)?
— Preceding unsigned comment added by Ldelsarte (talk • contribs) 10:03, 20 August 2011 (UTC)
Unfortunately, quite some errors and misinformation
First of all, the article mixes topics of Atari Basic, and Atari Os, and hardware information. Display generation, player missile graphics and CIO should really not go here. Unlike many other early home computer products, BASIC and OS were well-separated and BASIC builds on top of the Os.
Program editing is really part of the Os built-in editor, which was not exclusively used by BASIC, but by any product building on top of the Os - various Atari and third-party products used the same mechanism (Atari Assembler/Editor, Mac 65,...).
Character set is part of the Os design, not related to Basic
CIO does not go here. It's part of the OS. Despite, the entry point is wrong. CIO-entry is at E456, not E45C, the latter being a service routine for installing interrupt handlers.
Graphics is only remotely related to Atari BASIC, these are hardware features, and features of the Os screen handler (S:).
Player/Missile graphics (please do not use "Sprites", they were never called like this) is not part of BASIC and should not be discussed here. Basic did not support it.
Ditto interrupts and Os level support.
Embedded machine language: Wrong information again. Return codes are not returned in X and A registers, but in FR0 and FR0+1 ($d4,$d5 = 212,213). This is because the math pack integer to BCD conversion routine used to retrieve the result expects input right there.
BASIC commands: Unlike what the text claims, "GO TO" (note the blank!) is a keyword of Atari BASIC, and distinct from "GOTO", though the functionality is the same.
Relocation 6502 machine code is not an issue of Atari BASIC and should not be discussed here.
Attempt at getting this back under control
I deleted Atari hardware-specific topics that aren't tied to Atari BASIC.
Someone wrote this amazingly detailed personal essay about Atari BASIC at some point, but it wasn't encyclopedic in tone, and it also dwelled on exceptional cases and advanced topics that made the core information harder to follow. I tried to keep the spirit of the original while drastically reducing the bulk and the editorializing.
I rewrote most of the machine language subroutine section.
There's a lot more that can be done, but these changes reduced the size of the article by close to 30K.