Jump to content

thorfdbg's Photo


Member Since 21 Jan 2008
OFFLINE Last Active Apr 17 2019 12:58 AM

#4256112 BASIC compilers

Posted by thorfdbg on Thu Apr 11, 2019 2:00 PM


I'm more interested in a true compiler.

MMG is a true compiler. But that does not mean that its compiled code is much faster than that of ABC. It will just consist of a series of JSR instructions... similar subroutines are also in the ABC runtime, just dispatched by its p-Code, so it does not make much of a difference.

Do not expect an optimizing compiler as you would find them nowadays. They are all - including the TBXL compiler - pretty straightforward.

ABC has actually been more used for "copy protection" purposes as it is quite hard to follow the program logic through the pCode. A couple of Microprose titles have been written with it. Solo Flight and F15 Strike Eagle are to major parts in ABC-compiled BASIC.

#4255975 BASIC compilers

Posted by thorfdbg on Thu Apr 11, 2019 10:11 AM

Yes, of course. The ABC compiler is a standalone compiler for Atari Basic, to name just one. (Though, to be fair, it is not really a compiler. It compiles to p-code which is then interpreted by its runtime).

#4255365 DOS, Disks, Density and Sector counts... education question.

Posted by thorfdbg on Wed Apr 10, 2019 12:22 PM

Yes, the 1050 writes at double density, only that with a smaller sector size. Why Atari did that, I don't know for sure.

Even though the question is old, here is the answer - it is quite trivial: The 1050 does not have enough internal RAM to buffer a 256 byte sector before sending it to the host. In fact, the 1050 has 256 bytes(!) of RAM, half of which is used as stack and for zero page registers, and the other half is used as sector buffer. Operating without any RAM is quite hard (though some third party products were able to write 256 byte sectors without using any external RAM whatsoever - a real art!)

#4245622 Why are there 5 colors in ANTIC mode 4 and 5?

Posted by thorfdbg on Tue Mar 26, 2019 4:03 PM

I'm not really happy with Rybags's explanation.


But it is technically accurate. With 3 lines available to communicate color and state from antic to gtia, and 3 encodings taken, only 5 are left.


Any additional colors would have required an additional ANx line, which would have required a change in the chip pinout.

#4229926 Atari BASIC vs. Altirra 1.55 vs. TBXL 1.5 vs. FastBASIC 3.5

Posted by thorfdbg on Fri Mar 1, 2019 7:56 AM

Multiplication/division works pretty similarly with BCD and floating point math.
Microsoft's floating point math uses lot's of adds/subtracts and bit shifts.

Errr... several things go upside down here. First of all, an alternative to BCD is not floating point, but binary. An alternative to floating point is fixed point, or integer. The ABC compiler uses integers only, and if you want fixpoint, you have to scale yourself.

Floating point requires, of course, as of its building stones, an integer multiplication and division, namely to manipulate the mantissas of the numbers.



Then, if we compare binary and BCD integers, there is quite a relevant difference as far as multiplication or division is concerned. A binary multiplication algorithm takes out a bit of a time, and if set, adds a copy of the multiplicator to the factor, and then proceeds shifting the two. So it generates one digit per addition, and there is at most a single addition performed per loop, plus two shifts per loop.


For BCD, the story is different. The loop is not over bits, but over nibbles, and once you have taken out a single nibble, it requires up to nine additions of the multiplicator to the mantissa (at least with the MathPack implementation, which is rather primitive). So it is in general more complex than its corresponding binary counterpart, and noticably slower.


They probably picked BCD back then because it is easier to convert it to and from ASCII, but that is about as far as the advantage goes. The average rounding error for a BCD implementation to the basis of 100 (and this is what the math pack does) is considerably higher than that of a binary implementation - simply because it is easier to "lose digits" in rounding as the exponent can only be given relative to a very coarse basis (approximately 6 bits instead of 1 bit).

#4228149 Atari BASIC vs. Altirra 1.55 vs. TBXL 1.5 vs. FastBASIC 3.5

Posted by thorfdbg on Tue Feb 26, 2019 12:39 PM

Well, I haven't looked at the internals of Atari BASIC, but in my experience from optimizing the interpreter on the MC-10 (a Microsoft BASIC), the interpreter has to scan for keyword tokens, then parse the parameters to the related functions, convert numeric constants, etc... all while the program is running.   

Atari Basic really works different, in particular different than Microsoft Basic which was the basis for many comtemporary implementations, as for example the C64 Basic. Atari Basic runs a "pre-compiler" that convers everything into tokes once you enter a line, and then only executes from the tokens. Microsoft Basic is, as said, a different horse.


You find a good discussion on Atari Basic here:




which is really worth reading, and I can highly recommend it, especially the "Pre-Compiler" section which explains how the tokenizer works.


Atari Basic could be a very fast Basic interpreter, though suffers from two flaws: One problem is that its stack only stores line numbers and statement offsets, including a linear line scan to restore an operation position. Second, the lousy math implementation which is unnecessary slow.


The first problem is fixed in TurboBasic (by using a "hash list" of line numbers) or Basic++ (by pushing in addition absolute addresses and a sequence number on the stack).


The second is not really fixable without incompatibilities - one should switch to a different (binary instead of BCD) math model, but this makes programs incompatible. TurboBasic works around this by unrolling many loops, Os++ uses some manual optimizations, but due to limited ROM space, cannot be quite as efficient.

#4226401 Atari BASIC vs. Altirra 1.55 vs. TBXL 1.5 vs. FastBASIC 3.5

Posted by thorfdbg on Sun Feb 24, 2019 9:03 AM

Haven't we had this type of benchmark before? Actually, it is not much of a benchmark because it does not test anything but a single instruction. This said, you can also try with Basic++ if you want.


I afraid that there is not enough ROM space for AtariBasic to be able to support integer variables. It is quite tight already, and Basic++ was a tight squeeze already.

#4175725 DOS with lowest LOMEM?

Posted by thorfdbg on Wed Dec 12, 2018 2:07 PM

I know this is an old topic, but I wanted to see if anyone could remember (or find) a Dos 2.XL system disc that might work on a real machine and/or other emulators? I wanted to try it out in Altirra for some testing, but I cannot find any ATR or XFD of it anywhere. Thank you.

As already posted above, it is here:




along with sources. Dos 2.++ is there. I certainly have Dos 2.XL sources flying around.The 2++ version lacks the "write dos to disk" part (what for) and the autobooting part (what for), but otherwise, it is more or less the same.


Sorry for putting this project on rest, I was really really busy with AmigaOs 3.1.4 the last year(s) so I had to pause this for a while. But Christmas vacation is coming.

#4170026 How many Basics do we have for the A8?

Posted by thorfdbg on Tue Dec 4, 2018 3:28 AM

Out of curiosity, how much of the syntax is compatible between all those BASIC versions? In particular things like graphics, sound, input but also string handling, conditional jumps and other control structures.


Turbobasic is backwards compatible to Atari Basic, i.e. every AtariBasic program is also a TurboBasic program, but not vice-versa. Even the tokenization is identical. The same goes for Basic++, i.e. every Atari Basic program is also a Basic++ program. The reverse holds *almost*, there is one additonal token in Basic++, and this the "Dir" command, which is identical to TurboBasic, and there are a couple of syntax extensions such as allowing arrays for point,note,locate,get,read and input that are not valid in Atari Basic, but also valid in TurboBasic.


So, in a sense, Basic++ is a "cut down" version of TurboBasic, mid-way between the two. But unlike Turbo Basic, it fits into the regular 8K cart space, i.e. you can make it a ROM.

#4124150 Patch the stock OS with faster FP routines

Posted by thorfdbg on Sun Sep 30, 2018 4:41 AM

The problem is that the math pack and the basic are not well separated. Actually, the math pack is part of Basic. It does not even have a jump table, and some functions are in the math pack, others are in Basic.


Also, remember that IEEE 754 floats (32bits) has lower precision and range than Atari BCD, that has an equivalent precision of about 30 bits of mantisa and 10 bits of exponent.

Errr.... Technically, yes, but this is because IEEE 754 uses only four bytes, The Atari BCD uses six bytes. With a six-byte binary representation, you could reach a higher precision than the math pack. This is because the BCD representation (to the base 100) has a much higher average round-off error than a binary representation (to the base of 2).

#4123036 Patch the stock OS with faster FP routines

Posted by thorfdbg on Fri Sep 28, 2018 2:02 PM

While looking at the various alternatives versions of BASIC that are available I became quite interested in the floating point routines that are housed in the OS ROM. From what I have read these are notoriously badly written and very slow..



I was wondering if it is possible to build these routines and directly patch the stock OS ROM code with them?


Well, the problem is a bit more complicated than this. First, it is true that the implementation of the MathPack isn't fabulous, so it is slower than necessary. There are various attempts to fix that, including the functions above, but also those in Os++ (see there). However, the underlying problem is much more that the floating point representation upon which these functions build is not very wisely designed (to put it mildly).


If you have a BCD representation, there is only very little you can do to speed up multiplication and division, beyond loop unrolling and (as far as TurboBasic is concerned) pre-computing multiples of one of the factors. It essentially boils down to repeated addition or repeated subtraction. The sources you quote up there are no different, of course.


If you want to patch in something faster - the Os++ functions of the math pack are exactly the same size, so they fit into the original Rom space, and the call-in functions are also exactly identical. Thus, no extra ROM space is needed for them.


#4115351 What's the legal status of Atari hardware?

Posted by thorfdbg on Mon Sep 17, 2018 12:16 PM

Jay Miner etc (I know he is RIP) dont own patents? So they are outdated?


First of all, there is a difference between IPs (intellectual properties) which are protected by patents, and copyright. "IPs" protect ideas. Copyright protects source code. Patents run out after 25 years. Copyright runs out after a couple of years of its creator (unless you are the Disney cooperation).


Concerning ownership: A rather typical agreement is that an inventor hands over the IP to his employer. Same for copyright. Depending on the country, not everything can be handed over to the employer (in Germany, for example, the "Urheberrecht" cannot be signed over, but only gives the creator the right to be named as the creator of the product, not much more).


Hence, Jay most certainly does not own the patents. Atari did.


One way or another, the Atari *patents* have long been expelled. 25 years after they have been filed, they are open. As far as the copyright is concerned, this is another story.


#4110725 RGB availablity inside the original 8-bit motherboards?

Posted by thorfdbg on Tue Sep 11, 2018 12:04 AM

Correct. The Atari chipset does not operate in RGB colorspace. They use the TV-typical luminance + color phase encoding.

#4106698 DOS 3f

Posted by thorfdbg on Wed Sep 5, 2018 11:01 PM


Mike Albaugh (interview) gave me a disk of DOS 3, but it's not the DOS 3 that was released by Atari.  This might be a planned DOS 3, very different from the thing that Atari released


The released "DOS 3" was essentially a continuation of the original DOS line. Sort of DOS2+. This one is a clean-sheet design.


As you may recall, the big jump from DOS 1 to DOS 2 was the split between FMS (the File Management System) and DUP (Disk Utility Program), so that only FMS had to be resident in memory while user stuff was running. DOS 3 continues this split (which is pretty common in most Disk Operating Systems; You shouldn't need to whole menu systems and the code it invokes to be in RAM while using BASIC).

There seems to be some confusion here. The released DOS 3 *is* a clean-sheet design and completely different from Dos 2. It is an extent-based file system, and it is even more modular than Dos 2. We have FMS.SYS, for the handler alone, then KCP.SYS, which is the resident part of the "keyboard command processor". Actually, it is only the loader of it. Then we have "KCPOVER.SYS", which is the non-resident part of it - this is the closest equivalent to "DUP.SYS", and then we have several external "plug in" commands for format, diskcopy and so on, that are also on the master disk.


I do not know what this is in particular. Forth - or at least the variants of forth I have seen on the atari - used a "disk-based, dos-less" approach where the source code editor edited raw sector contents, without any administration through dos.sys. Probably because Forth required larger source codes - larger than memory - and more space for compling, and the "link-based" dos 2 system did not enable this in a useful way. The forth-versions I saw just go directly to the disk, enabling random access without seeking.


Dos 3 could also do the same, i.e its much simpler to seek to a particular byte offset in Dos 3 than it was in Dos 2, so maybe that is why it was used here, but without looking into the code, it is hard to say what we have here, exactly.

#4076817 Atari 800XL going into "self test" when pressing "Option" whi...

Posted by thorfdbg on Sun Jul 22, 2018 1:24 PM

There is something you might try using DOS 3 for:


This sounds like a joke... Formatting a disk just issuing a single SIO command, no matter which Dos is used. The actually formatting is performed by the CPU in the drive, and the floppy disk controller, and it cares little (as in "not at all") whether it was Dos 2 or Dos 3 that triggered the format.