drac030

Now load Turbo BASIC XL and see if you still like the DOS.

I don't know if you noticed, but in SpartaDOS X the H: ( or DH: ) is equal to D8: The emulator's "H:" device has nothing to do with the DOS you use, by the way, it mimics the DOS functionality on the host filesystem, but the native DOS for the emulated Atari doesn't know about it. This is the source of problems, you effectively have two DOS-es at the same time and want them work just as it was one.

True. With a fast hard drive, 320k ought to be enough for everyone, since there's no use for this memory except demos.

This is not a real problem, for such programs is only a tiny fraction of all software titles. And if you really can't live life without Alley Cat, then you can always use a stack Atari or an emulator to play it.

I am afraid F7 is dead. I have heard nothing from the hardware designer for too long. Probably the F7 will get replaced by Warp4, less featured, but also cheaper and less expensive in production. Once it get fixed, that is, because the publicly available project has been proven to be faulty. Obviously. This is a question you have to ask game developers I don't write games nor I play them, so I have no clue. Yes.

From Electron's words I can infer, that making the full replacement would be much more complicated and it would require a more expensive FPGA to be used, with only a fraction of new features the VBXE will offer. The key feature of the VBXE is not just RGB output, but completely new video capabilities, such as color maps, 64k colour palette, unlimited hi-res color sprites etc. The old GTIA at the same time provides the old video output and also still carries some tasks which are not implemented in the VBXE (and they're not implemented, because the old GTIA does them well, such as P/MG collision detection - of course only for the old-style P/MG). I don't know, you have to ask Electron about this.

No. Yes. It is 320k RAMBO, accessible the standard way (like in any other expanded Atari). I don't know. Probably this depends on how you install the VBXE, but I am not sure. You meant "overseas", didn't you?

Ok, Mathy, since it was probably my post you saw, I need to write some explanation. Electron has practically finished the VBXE 1.1, and he collected orders for the devices. I remembered, that you was very excited about the VBXE, so I wrote that I am sure that you would want one as well, just you probably don't know that it is the time to make an order. And I offered to write an announce on the AtariAge, just asked Electron to state the price for overseas (with shipping abroad). Electron replied that he is already overloaded with what he has to produce so far, so next orders will have to wait until he outsources the device to someone else for serial production. That's all for now. VBXE 1.1 contains the complete GTIA emulation plus an extension to 320k RAM. Electron is now busy rewriting the core, i.e. adding all the new features to the complete GTIA emulation, which were previously demonstrated in the prototype. The initial series will only do the GTIA - more sophisticated softcores will be distributed later.

You forgot "opt ?+" at the beginning of your source.

The "XE OS" (i.e. the XL OS v.1.03 and further revisions) contain no essential differences to the XL OS (v.1.02, found in 800XL/65XE). There OS code is the same, AFAIK there is one minor difference in some serial routine, where two instructions have been reversed in order. This makes no difference to programs anyways. The real cause why some programs crash on the XE OS is that they contain parts of code f.e. EOR-ed with ROM. If the part of the ROM, that is used for that, contains the ROM checksum, revision date and revision number (and these are the ONLY real differences between these OS-es, visible to programs), then it will of course only decode correctly on one OS revision. In other words, this is not the OS which is guilty, nor the Atari, but, as usual, unwise programmers.

The owner has given the D.8002 HS drive to me for inspection. Almost everything inside is Soviet.

Oh, this is quite high for this DOS. When properly configured, it can go below $0F00 PS. I can add something to your list: DOS 1.0 $2A80 Now, that's a "!!!"

I don't know what's the status, you'll have to ask the author of the hardware. The BASIC is hardware-independent, but it requires the OS. The OS doesn't specifically require F7, although it contains some F7-specific code that is done during initialization, when the F7 is detected. The OS should work with any 65C816 upgrade, I think, there are no special requirements except that the "high" memory, if it exists at all, should be seen as one continuous block of 64k segments. The last 64k segment of the address space is reserved for I/O registers, the OS assumes that there's never RAM there. That's all.

The "rev5" XL OS circulating here and there is, IIRC, the "rev. C", which is crippled. It has the PBI routines removed, and it has a "fast" (38,4 kbaud) SIO patch and some "text viewer", a thing which is really deadly necessary in ROM. Fortunalely Tramiels didn't put it into production because we wouldn't have autobooting PBI harddrives now.

The point is that 65C816, unlike 6502, does not have to access memory on every possible cycle. And taking an advantage of that makes the (slight, but noticeable) speed gain I mentioned. Of course, much more gain is made when the entire RAM is clocked by the fast clock. Well... I should have phrased that more clearly. The 6309 uses a prefetch when in native mode. Any clock cycles where the bus isn't accessed can be used for a prefetch so that a clock is saved when a load would have to occur so even standard 6809 code runs faster. If the 816 supports the same type of prefetch then you would have close to 1 read or write on each cycle. If the speedup is just from the new modes then it would be more like the 6809 than the 6309. I see now what you mean. But no, 65C816 does not use any prefetching scheme that wouldn't be already used in 6502. That means, that every clock cycle generates a memory access, whether it is required for anything or not. For example, TAX takes two cycles, but only one of them is required for fetching the instruction. The other cycle is internal operation, and so no read/write should occur, however, 6502 MUST generate a memory access at any cycle. So it does a spurious read. 65C816 does basically the same, except that it can signalize to the external logic, with two new signal lines, VPA and VMA, if the bus access is valid. If it is not, the external logic can ignore the read, or just for that cycle switch the CPU to a faster clock. Say, the main clock is 14,18 MHz, but normally it is divided by 8 to get 1,77 MHz clocking the CPU. When the CPU fetches the TXA opcode, it generates a valid memory access, which takes 1 CPU clock cycle (= 8 main clock cycles). The next memory access is however invalid, so external logic can enable the CPU to be clocked by the main clock (14 MHz). This way the TXA takes not 2 CPU clock cycles (= 16 main clock cycles), but only 1 and 1/8 CPU clock cycles (= 9 main clock cycles). Effectively, of course, this mechanism has the effect of optimizing bus accesses, similarly as in the other CPU you mention...

The point is that 65C816, unlike 6502, does not have to access memory on every possible cycle. And taking an advantage of that makes the (slight, but noticeable) speed gain I mentioned. Of course, much more gain is made when the entire RAM is clocked by the fast clock. Unfortunately, it won't. Actually, the idea is to byte-swap every FP number after I/O in LOAD and before I/O in SAVE (and in several other routines which allow explicit FP input and output). This will allow to keep the binary compatibility with Atari BASIC and Turbo BASIC. The interpreter of course has to contain own FP routines, but it contains them anyways, like Turbo BASIC does.

Provided that 65C816 instruction stream, unlike f.e. in m68k, is not word-aligned, expanding it to a 16-bit data bus and keeping backward compatibility would greatly complicate the chip, I think. Of course, it could then fetch two instructions at once in some cases, but at the other hand a sequence of LDA abs / STA abs (6 bytes: AA bb cc DD ee ff) would require 3 consecutive instruction fetches: 1) LDA + LSB of the argument (AA bb), 2) MSB of the LDA argument + STA opcode (cc DD), 3) STA argument (ee ff), provided, of course, that the last fetch before LDA wasn't misaligned ... At the other hand, using 65C816 even with old 8-bit code and 1,77 MHz bus does some speedup, if the internal CPU operations are clocked faster. This is one of the options in the F7 board I have, you can tell the circuitry to omit waitstates for internal CPU cycles, i.e. the ones when it doesn't do any memory access. At 10 MHz internal clock and 1,77 MHz bus clock this causes average 20% speed gain (sometimes less, sometimes more). Original question: my 16-bit BASIC is just at the stage it was six months ago, unfotunately. I have some ideas f.e. on how to speedup the FP calculations by using (despite the problem I mentioned above) the full 16-bit decimal maths, and also to add integer maths as well. The problem is that I currently don't have proper hmm conditions to just sit and code.

Turbo BASIC XL 1.5 uses own FP code, but it also must partly use the ROM package routines, for applying the Charles' Marslett "fastchip" routines to ROM makes the TBXL's LOG() and raise-to-power routines work improperly. Rewriting the FP routines into 65C816 code does speedup them, but not as greatly as you expect. The CPU can of course do 16-bit decimal calculations, the problem is that it does them in little endian order (low significant byte first), while the Atari's FP format is the reverse (low significant byte of the mantissa is last). To try out, how does the OS and BASIC feel like, when rewritten into 16-bit code, I recommend you to visit my site: http://drac030.krap.pl

There are some. For example: Atari BASIC: 1) you can type in the DIM instruction without arguments, like: 10 DIM: DIM: DIM 2) NOTE and STATUS accept numeric dimension as a parameter: STATUS #1,A(0) is accepted, but the value isn't assigned correctly to the array element. 3) IF CHR$(1)=CHR$(2) is always true 4) 1^44 is two There are also some bugs in the syntax control. Turbo BASIC XL: 1) %GET, %PUT and -MOVE aren't accepted when typed in lowercase 2) DEC() works wrong when the argument contains lowercase characters 3) Ctrl/R at the end of the text string works just like the semicolon. 4) the syntax control accepts text array as an argument to the GET keyword, which can only assign values to numeric variables

There is no such thing as an "ideal" Atari 8-bit system. Some people like games and want every one made in 80s to load and run. Some people don't really care. Anyway, my answer to the initial question is: mine

Not surprised. SpartaDOS X, while accessing non-native filesystems, can be rather slow because of the way the disk format is internally translated to the Sparta format and back. Normally it doesn't hurt because when the SpartaDOS X is your main DOS, most of your floppies are in Sparta format anyway... Yes. This is the place where the 3.2 (and further versions, like 3.3 or Real.DOS) are more efficient than X 4.x. When closing a file, it writes out the data sector, then updates the sector 1 (first seek to track 0), then writes out the file map sector, then updates the bitmap (the second seek to track 0). On real floppy, as a result, the head goes to and fro several times when the software closes a file being written to. The real reason for that behaviour is the internal implementation of the buffers, the DOS does not keep separate buffers for the data, maps, bitmap or bootsector, but the buffers are freely assigned to the sectors as they're necessary regardless of the type. As a result, though, when they're flushed out to the media, the order of writing them out is far from being optimal. This of course doesn't matter much on a harddisk ...

I recommend you to try the native SDX Synchromesh instead. Power-cycle the drive, boot the SpartaDOS X afresh and then type: INDUS.SYS from the command prompt. Then you should be able to format a floppy with HighSpeed skew in the SpartaDOS X Formatter. But - as for testing speed - the SDX SIO driver tends to disable VBL temporarily for high baudrates, like Indus turbo mode. So if you test the speed using a VBL-based timer, the results may be a bit too good

Indus SuperSynchromesh and Sparta X fast serial speed equals to value 6 of the Pokey clock divisor. This is 68,2 kbps AFAIK. The ordinary Synchromesh sets the clock divisor to 16, which is 38,4 kbps. US Doubler is 10, IIRC.

IIRC, the ordinary Synchromesh does 38,4 kbps. The SuperSynchromesh - 68,2 kbps, but it does not work well enough. The INDUS.SYS driver included in the SpartaDOS X appears to be a better version of the SuperSynchromesh, though: it is both fast and stable.

What if you try the same with the other disk - i.e. CP/M BIOS?