thorfdbg Posted June 26, 2015 Share Posted June 26, 2015 I think "naive" was really the wrong description of the Atari8 floating point package. Naive is exactly the right word. The FP package shows a complete lack of knowledge on numerical mathematics. Nobody sane in his mind would use a BCD representation to the base of 100 (which is what it is). This format has a lot of problems, as for example with error accumulation, rounding and truncation errors and slow multiplication and division. If you want to check for a good FP format, look how IEEE float is made: Three extra (invisible) bits ensure that all operations round properly, without precision loss due to round-off. None of that is "higher magic", and most of this was actually known at its time. Yet, this knowledge was ignored .... resulting in a poor implementation of a poor format. As far as software engineering is concerned: A lack of a proper interface, no jump table... It was a quick hack made in last minute under high pressure. Oh come on... 1 Quote Link to comment Share on other sites More sharing options...
gozar Posted June 26, 2015 Share Posted June 26, 2015 I thought BCD was used because the 6502 had a BCD mode. The 6502 Wikipedia page mentions that Atari Basic was about the only place it was used. Quote Link to comment Share on other sites More sharing options...
Irgendwer Posted June 26, 2015 Share Posted June 26, 2015 Maybe you can write the code in more than 10 lines, so I can understand. I only need an example of two overlapped sprites that move horizontally and vertically. Ok, especially for you . You can move the 'ball' and it's shadow with the joystick around. Since Basic is slow, I needed two VBLANK syncs to avoid tearing. If you need faster motion (or have more pmg data to move), you could use two PMG-bases and flip between them. ("Broad's Revenge" takes one PMG base for each animation frame and only changes the base, too.) Don't hesitate to ask if something is unclear... PMGTEST.TUR.zip 1 Quote Link to comment Share on other sites More sharing options...
+Philsan Posted June 26, 2015 Share Posted June 26, 2015 Ok, especially for you . You can move the 'ball' and it's shadow with the joystick around. Since Basic is slow, I needed two VBLANK syncs to avoid tearing. If you need faster motion (or have more pmg data to move), you could use two PMG-bases and flip between them. ("Broad's Revenge" takes one PMG base for each animation frame and only changes the base, too.) Don't hesitate to ask if something is unclear... It works! I attach an autorun ATR: TBXL Players Irgendwer.atr Thank you very much! Quote Link to comment Share on other sites More sharing options...
luckybuck Posted June 26, 2015 Share Posted June 26, 2015 @thorfdbg: Please attach the IEEE float paper you mentioned Then, if you are that smart, why don't you deliver the Atari Basic Type D let's say with all fp routines? Tomorrow or next week? Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 26, 2015 Share Posted June 26, 2015 He doesn't really need to do that to have an opinion. 3 Quote Link to comment Share on other sites More sharing options...
luckybuck Posted June 26, 2015 Share Posted June 26, 2015 Sure, but it would be more reliable. If you mention IEEE float, then you should be able to proove that, regardless of an opinion. That is the way science works. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 26, 2015 Share Posted June 26, 2015 I haven't looked too closely, but I was under the impression there are existing 6502 FP implementations which are more efficient. Not sure what pressures they were written under, but I guess we're at liberty to compare them if they exist. Quote Link to comment Share on other sites More sharing options...
luckybuck Posted June 26, 2015 Share Posted June 26, 2015 and we have all the time in the world to realize a non plus ultra Basic, Action! and maybe MAC/65 on an open source base for all. :-) Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 26, 2015 Share Posted June 26, 2015 What's this thread about again? Quote Link to comment Share on other sites More sharing options...
luckybuck Posted June 26, 2015 Share Posted June 26, 2015 (edited) Turbo Basic XL hacks or improvements: - In the now available ACTION! source code, there is an editor,which is much better then the one in BASIC XL. For BASIC XL, we have the source code, too. - 80 are possible in BASIC XE, so it should be possible to implement in the XL version, too. - BASIC XE uses the EXTEND command, would be cool, if one day, we have the XE source code (I have a dream...) to extract these code and put it in the XL code or vice versa. We now have A8s with up to 4 MB RAM... - POKE precision,x ; where x is a number from 0 to 8 or more. Standard should be 2. - All(!) changes documented on a open source base All this was written before and fits to my mind the: Turbo Basic XL hacks or improvements especially, that a first contact to the author is underway.. Edited June 27, 2015 by luckybuck Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 27, 2015 Share Posted June 27, 2015 Just joshing. These are exciting times. Quote Link to comment Share on other sites More sharing options...
luckybuck Posted June 27, 2015 Share Posted June 27, 2015 Yes sure, you are right, I am just too serious... But I don't like, that our old heros are blamed and called naive, without having the full knowledge of the then zeitgeist. Main emphasize have to my opinion to be put in digitizing cassettes and diskettes and of course, the source codes. :-) Have a good weekend. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 27, 2015 Share Posted June 27, 2015 Fair point, but I have to balance acknowledgement of the pioneering coders with my frustration when modern attainments are explained away as the product of hindsight or relaxed timescales. 1 Quote Link to comment Share on other sites More sharing options...
luckybuck Posted June 27, 2015 Share Posted June 27, 2015 Quote Link to comment Share on other sites More sharing options...
phaeron Posted June 27, 2015 Share Posted June 27, 2015 I'm going to have to side with luckybuck here: IMO, the people that wrote Atari BASIC and the floating point ROM deserve some respect. They were aware of the tradeoffs of binary vs. BCD floating point and chose decimal for user understanding and faster addition and subtraction, per the preliminary manual up on AtariMania. While some of us don't agree with that decision, the math pack does work acceptably and we got a 10K BASIC interpreter with direct sound and graphics capabilities (as opposed to Commodore BASIC) and with reasonable speed (as opposed to TI BASIC). Yes, they were under time pressure, and yes, they could have done a better job. And yes, people have tried to do the latter. I say tried, because of test results like this: That's from a popular replacement for the math pack. It's much faster, more accurate, has some additional features... and, as shown by the test results, quite a few bugs not in the original math pack. It's easy to criticize what the Shepardson and Atari programmers did over 30 years ago, with the knowledge, tools, and experience that we have now. Before throwing stones, though, it's best to make sure your improved math pack replacement doesn't give -1E-<8 as the result of 1E-64*-1E-64. 6 Quote Link to comment Share on other sites More sharing options...
thorfdbg Posted June 27, 2015 Share Posted June 27, 2015 @thorfdbg: Please attach the IEEE float paper you mentioned Then, if you are that smart, why don't you deliver the Atari Basic Type D let's say with all fp routines? Tomorrow or next week? There is no "a paper", but I've a whole book on this stuff. FYI, I actually did write a better and more precise math pack, I already mentioned that. It's part of Os++, the Atari++ emulator, and you get it in source form if you like. It uses better rounding, and minimax polynomials for exp and log. Unfortunately, sin and cos are in BASIC, so I cannot replace it at this point. Concerning IEEE math, you might check who updated the math libraries for AmigaOs 3.9. So please, I believe I know what I'm saying. 1 Quote Link to comment Share on other sites More sharing options...
thorfdbg Posted June 27, 2015 Share Posted June 27, 2015 I'm going to have to side with luckybuck here: IMO, the people that wrote Atari BASIC and the floating point ROM deserve some respect. They were aware of the tradeoffs of binary vs. BCD floating point and chose decimal for user understanding and faster addition and subtraction, per the preliminary manual up on AtariMania. While some of us don't agree with that decision, the math pack does work acceptably and we got a 10K BASIC interpreter with direct sound and graphics capabilities (as opposed to Commodore BASIC) and with reasonable speed (as opposed to TI BASIC). Yes, they were under time pressure, and yes, they could have done a better job. And yes, people have tried to do the latter. I say tried, because of test results like this: mathtest1.pngmathtest2.png That's from a popular replacement for the math pack. It's much faster, more accurate, has some additional features... and, as shown by the test results, quite a few bugs not in the original math pack. It's easy to criticize what the Shepardson and Atari programmers did over 30 years ago, with the knowledge, tools, and experience that we have now. Before throwing stones, though, it's best to make sure your improved math pack replacement doesn't give -1E-<8 as the result of 1E-64*-1E-64. Respect yes, given the time they had to come up with an implementation. But the result shows, and they had no time to study the subject area. And no, BCD is not a sane decison if you require good mathematical algorithms. Quote Link to comment Share on other sites More sharing options...
luckybuck Posted June 27, 2015 Share Posted June 27, 2015 @thorfdbg IEEE and no paper? Are you kidding? It doesn't make sense to refer to AmigaOs, here we are at Atari. Further, the Amiga is part of the Motorola-68000-family... Here, we are dealing with 6502... I am a scientist, I do not like to believe things, when prove can be made. Believing is for religion. Here, just facts should matter. thorfdbg, it is you who mentioned IEEE, therefore it is up to you to prove, not to us to look in several other sources. Can you upload your work in form of an atr image or car/rom image, so we can compare your results with Hypra-Soft-Basic? And please don't misunderstand me, but really don't want to continue this, there is still much to do, before we reach the 100 % digitizing... Therefore, without the delivery of what you claim, I would like to make a break here. Quote Link to comment Share on other sites More sharing options...
thorfdbg Posted June 27, 2015 Share Posted June 27, 2015 @thorfdbg IEEE and no paper? Are you kidding? It doesn't make sense to refer to AmigaOs, here we are at Atari. Further, the Amiga is part of the Motorola-68000-family... Here, we are dealing with 6502... If you want to read something how floating point works, my immediate recommendation is "Donald Knuth: The Art of Programming, Vol. 2: Numerical and Seminumerical Algorithms". This is pretty generic, but you'll find the elementary algorithms there, including how to round properly and how to deal with hidden bits. There are a couple of proceedings I don't have right here (it's in the office) where studies have been made concerning the precision and the numerical base, i.e. base 2 vs. base 10 (and base 16, base 8 and some other). I won't be back in the office until Tuesday, but that's also pretty old stuff from the 1960's and certainly known. If you want to read how IEEE floating point is defined, then you'll find the definition in IEC 60559 (an international standard) which is paired with the IEEE recommendation. That document, however, only explains the "how" and not the "why". The algorithms do not depend on the 6502 or the 68K, so whether that's Amiga or Atari is quite irrelevant. Sure, the 6502 has less computing power than the 6502, but that is no excuse for making things wrong. And Multiplications in BCD is not exactly "done right". It's a bad choice, and a slow choice. Concerning my implementation, I've already pointed you at my work. If you're too lazy to google, here is the link: http://www.xl-project.com/Sources are included. This is not the end of the word, but at least it's an improvement over the old math pack. You cannot really change the representation from BCD to binary without breaking compatibility, which is why I did not change the format. Unfortunately, ROM space is pretty limited, so one cannot really do much here to improve the multiplication and unroll it, as it was done in TurboBasic. There is also a thread here in the forum (use the search function) on various math implementations which included a comparison of the Os++ math as well. You can search for that and compare yourself. No, this math stuff of mine is *not* the fastest simply because I had to deal with limited ROM space and limited RAM footprint, but yes, it is better in terms of precision and speed. Quote Link to comment Share on other sites More sharing options...
luckybuck Posted June 27, 2015 Share Posted June 27, 2015 Wow! That is good! http://www.iso.org/iso/catalogue_detail.htm?csnumber=57469 http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=57469 Just around $ 190.00 for buying, but that doesn't matter, our university here has that paper. Will take a look inside. Thank you. To me, speed is not the question, precision is more important for me. So, this doesn't matter. Don't misunderstand me, now, I am just collecting, the Super Basic project, I will start, when all the other tasks are done. That will take a while... I suggest, to collect all the sources from all Basic versions, make a matrix of advantages/disadvantages and go on on that further. Will search for the various math implementation here, thank you for your help. Quote Link to comment Share on other sites More sharing options...
ricortes Posted June 27, 2015 Share Posted June 27, 2015 Just a point of order. IIRC Bill Wilkinson's degree is in math from Berkeley, ditto for Steve Wozniak. The head of our IT department had a degree in physics. One of the professors of our computer science department in college was an assistant wrestling coach albeit with a degree from the Naval Academy. It really was much more Wild West back then before everything got institutionalized. There was still computer time sharing, batch processing, and not a lot of places that offered anything like a CS major. There were such fundamental questions such as accuracy vs. speed that were hotly debated. Ultimately it seems games trumped everything in terms of volume of users which meant speed trumps everything. If you needed extra accuracy to determine an atomic weight to 20 places then, you still do now, it is just the number of people determining the atomic weight of elements compared to people playing WoW is pretty small. 1 Quote Link to comment Share on other sites More sharing options...
thorfdbg Posted June 27, 2015 Share Posted June 27, 2015 (edited) Wow! That is good! http://www.iso.org/iso/catalogue_detail.htm?csnumber=57469 http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=57469 Just around $ 190.00 for buying, but that doesn't matter, our university here has that paper. Will take a look inside. Thank you. IEC 60559 is paired with IEEE 754, and the latter may be cheaper for you, especially if your institution is subscribed to the IEEEexplorer (I can get it there for free since our library subscribed). ISO/IEC prices are always quite high. Anyhow, both texts are probably not quite what you need. First of all, they are surely not compatible to tokenized Atari BASIC, and second, they don't explain the motivation for the choices IEEE made. Edited June 27, 2015 by thorfdbg Quote Link to comment Share on other sites More sharing options...
thorfdbg Posted June 27, 2015 Share Posted June 27, 2015 That's from a popular replacement for the math pack. It's much faster, more accurate, has some additional features... and, as shown by the test results, quite a few bugs not in the original math pack. It's easy to criticize what the Shepardson and Atari programmers did over 30 years ago, with the knowledge, tools, and experience that we have now. Before throwing stones, though, it's best to make sure your improved math pack replacement doesn't give -1E-<8 as the result of 1E-64*-1E-64. Thanks for the bug report. This bug is due to denormalized negative numbers which are new to the math pack. Apparently, the BCD to ASCII converter (and actually, the normalizer) still had a bug. I fixed this in the meantime. 1 Quote Link to comment Share on other sites More sharing options...
luckybuck Posted June 27, 2015 Share Posted June 27, 2015 Sure. Another question, you compiled a Win version, what about a Mac version, too? Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.