drac030

I don't have a 65816 to play around with. What's the cycle breakdown of the above for 65816-- does the 2nd read cycle for MSB in the LDA Var occur one cycle after the first read for LSB or more? Similarly for STA. There is only 8-bit data bus so much be splitting up into multiple reads/writes. So if I write a 16-bit value to 53270, two color registers would get set but what's the time in cycles between the first write and the second? A 16-bit LDA or STA takes exactly one cycle more than 8-bit one. So, for the above example (R - read, W - write cycle, I - internal op): LDA VAR - R:OP R:ARGL R:ARGH R:DATAL R:DATAH (5 read cycles) CLC - R:OP I:- (1 read cycle + 1 internal operation = 2 cycles total) ADC #$6502 - R:OP R:ARGL R:ARGH (3 read cycles) STA EXT - R:OP R:ARGL R:ARGW W:DATAL W:DATAH (3 read cycles + 2 write cycles = 5 cycles total) The MSB is written in the next cycle after the LSB.

It is not intended to speed things up. It just allows new programs to fully utilize the 65C816 potential (i.e. the "native", 16-bit mode). Which would surely speed things up? Like, long branching and 16-bit maths and accumulator and an enhanced instruction set etc... Okay, so there might not be much noticable difference, but wouldn't the move opcodes be faster than lots of LDA/STA? That sort of thing? Long branches and extended addressing modes are always available, regardless of the mode the CPU runs. The native mode "only" gives access to 16-bit registers, and, when we put it this way, yes, this "speeds things up", of course only for new programs which use the 16-bit loads/stores/calculations. An example, let's have a 16-bit value stored in the memory. We need add a 16-bit constant ($6502) to it and store somewhere else. The standard way: lda var clc adc #$02 sta ext lda var+1 adc #$65 sta ext+1 Assuming that var and ext are outside the zero page, this is 22 clocks. Now 65C816: lda var clc adc #$6502 sta ext Assuming the same as above, 15 clocks - 32% faster. But to run this coded you need the possibility to switch to the native mode, and for that you have to replace the OS.

That's some point. Just not $D5xx, nor $D1xx.

@bob: in existing implementations there is no such software switch, so such a register, as you are considering it, would provide something new. In Warp 4 the clocks are switched by address: if the address is $00xxxx, the clock is "slow", otherwise it is fast (unless the turbo is disabled by a hardware switch). In F7 the turbo mode is enabled permanently, you only decide in software, how the fast memory is to be mapped into address space (f.e. you can map Atari memory onto $0000-$FFFF, then it works less or more as Warp 4 - or you can map the card's memory onto $0000-$FFFF, then the entire address space is fast). Again, this can be overridden by a hardware switch. $D5xx is bad idea, this page is already overloaded, so there is a hign possibility for a conflict (with a Maxflash cart, for instance). I think the register should be located outside the first 64K and inside the bank $FFxxxx, as you planned. As I wrote, this area is anyways allocated for I/O by other implementations. This would need a 24-bit address decoder anyways, so making it more precise, i.e. to decode it at $FF8000 (or $FF8000-$FF80FF) should not be a big problem. Other things: even if the largest SRAM is 2 MB, I don't see a problem by using 8 of them to complete a 16 MB (minus 128K). Banking "large chunks" is hm "interesting" idea, but not everyone likes banking so much as to implement it even when it is not necessary (in other words: I don't understand the pleasure of having 8 banks by 2 MB instead of linear 16 MB). @peteym: the Atari OS does not support binary loading at all, and the addresses in the "boot file" header are 16-bit, so it does not. However, the SIO is extended so that it can transfer sectors directly from/to the area above the first 64K, so some support for a DOS, that could implement an extended binary loader is there.

The point is to not conflict with other designs and already existing software. For example, one of the HPU registers in F7 can be (and is) used to test, if this is F7 or not (i.e. Warp4). The 65816 OS needs to check what hardware it is running on, and e.g. reset the HPU when it is present. If you locate your control register where the F7 has HPU and Warp4 nothing, then there will be a compatibility problem. Also some programs (e.g. SysInfo) scan the 16 MB address space in order to detect, if there is RAM there. An address decoder that locates the control register in some unused adress (e.g. $FF8000) should be simple enough. But if you are going to take the whole 64 KB (or whole 16 MB) for just one control register, then well - there is some difference between "simple" and "primitive". @Larry: F7 is off, but there are some prospects on Warp4. This does not depend on me, unfortunately (because if it did, it would be long done).

So this http://drac030.krap.pl/xlos-04032007.arc is an non-existing code, apparently. The last 64K bank ($FFxxxx) is reserved for I/O, but few locations are already defined by other accelerators: $FF00XX - MMU $FF01XX - RTC $FF02XX - VIA $FF03XX - $FF04XX - reserved $FF05XX - $FF07XX - general purpose $FFD000 - $FFDFFF - hardware register shadow Also, $F00000-$F7FFFF is reserved for ROM. I typed it from the HyperSpeed XL/XE instruction: http://www.digital-force.net/projects/hype...rspeed_doc3.pdf The F7 accelerator complies to this, and so does the "non-existing" code.

@ijor, rybags: this is convincing. Sure nobody should use any POKEY register when calling SIO, because the ROM OS zeroes all of them upon completion (despite the fact that only two of them are used as baudrate generator). In meantime I also did some experiments with VCOUNT which proved that it should work - so I don't know, why I was so convinced that it would not. Maybe I tried it and did some simple mistake, then misinterpreted the results.

Ad 2: I think that at least DOS XL and OS/A+ contain (even SpartaDOS-compatible) routine that gets the next argument. I however don't know, if the way of detecting it is "proper", i.e. it wouldn't fail on some DOS. The method is: (1. detect SpartaDOS the usual way, if TRUE, goto 4.) 2. if DPEEK(10)=76 AND (DPEEK(10)+3)=76 THEN GOTO 4 3. a DOS without SD/DXL/OA+ command line. STOP 4. SD/DXL/OA+ command line interface. Ad 1: I don't know But it is up to the DOS, IMHO, what it wants to see as command line argument separator, and it is up to its user, what to use as the separator, if there is some valid alternative. Definitely, if the DOS offers a routine to parse the command line, the program should use it instead of doing everything "by hand". @Cybernoid: I think that you shouldn't add comma recognition as a separator, because in some other DOS this can be an invalid separator. What should be done, is that the loop, that copies the LBUF to "our own buffer" should be replaced with something more intelligent, that doesn't blindly copy the entire string, but calls the DOS "parse argument" subroutine until the command line is empty, and, in the process, store the parsed parts (= arguments) into own buffer, and store pointers to them into argv.

This is wrong: the comma can also separate arguments, and when it is used so, this code will fail. Why the CC65 doesn't let SpartaDOS to split the command line?

As I said, if it works, it is pure accident. PRINT something before on the screen (using the OS' PUT RECORD function, i.e. the proper print string), and you loose with this, because $24 will then point to the printed string, and not to the "command line" (which is not really the command line, just the string the user entered via the OS' GET RECORD function, i.e. the proper input string). Besides, SpartaDOS X doesn't use CIO for string input, so if this works under SDX, I am the most surprised. The example printed in the manual will work on every SpartaDOS (and, if anyone cares, also on OS/A+ and DOS XL). It calls the procedure that parses the command line automagically, so you do not need to worry if the user gave a space or a comma for the separator, if he typed in the correct number of parameters etc.

I think I have found that thread. The conclusion was that it was Gustafson: http://groups.google.pl/group/comp.sys.ata...mp;dmode=source Also the FAQ says so. This is interesting, because SDX soooo internally differs from the 3.x, and I tend to really admire its designer. Comparing to SpartaDOS 3.x, the SDX is almost like Windows 95 to Windows 3.11 :]

No, this is horribly wrong. $24 is the ZBUFA address of ZIOCB. It only contains an address to the last used CIO buffer (for _any_ operation). If this ever works, it does only by an accident. The correct way to access the command line is to use the vector at COMTAB+3. The COMTAB address is pointed to by the $0A vector. An example routine to parse the command line parameters is included in the SpartaDOS manual, i.e. here: http://trub.atari8.info/sdx_files/4.41/Manual%20V4-41.pdf on pages 172-3 (or 6.28-9).

There is some description of the problem here: http://atariki.krap.pl/index.php/GTIA This is in Polish, but as long as you can tolerate automated translation, you can take a look at this: http://66.102.9.104/translate_c?hl=pl&...qvzvOvHxCVAN4Sg

Yes, and now go implement it in a SIO driver, and see how this works. PS. PAL/NTSC compensation is not necessary, because the thing you calculate is the clock multiplier.

I vaguely remember that I tried once to replace the loop with a stable delay generated by the VCOUNT, and it did not work. @ijor: it would be of course good to use a POKEY timer to generate this timeout, but I think that multiplying the delay by increasing the number of cycles the delay loop runs is simpler. At least, you calculate the clock multiplier only once (at boot time), and then store it in a safe location, and you do not need to worry if POKEY timers are not used by something else, if IRQ is on etc. (SDX SIO works with IRQ disabled).

The OS isn't a problem, as it is "slow". And despite that, even 20-30% speedup of its execution does not create any problem with SIO (I have tried that on the F7 board). I am of course speaking about RAM-based SIO drivers, like in SpartaDOS. With clock factors like 4x or 8x, even if this works, it is probably pushed to some limits, and so not all devices will react correctly, or there can be occasional failures (which you won't notice easily, because every command is retried up to 16 times). In any case, calibrating will solve any possible problem with this delay, up to 450 MHz

This is probably pure luck, that your serial devices are fast enough. Every SIO driver on this world contains a busy loop that makes some delay between setting the COMMAND line on the SIO, and sending the actual command to the device. When you clock CPU 4 times faster, this loop is 4 times shorter, of course. When you clock the CPU 5 or 8 times faster, or even more (on the accelerator I have), the loop becomes yet shorter. So no worry, the loop calibration is necessary anyways, to compensate this.

Why you do not report this? There is the bugtracker for that: http://dlt.krap.pl Please provide more information about these files which do not load, or better send me one for inspection. So far I have never come across a _correct_ binary file, that SDX would refuse to load, so you can help. @wood_ji: on the same site there is a very detailed manual, that can answer most of your questions. Putting the DOS on the cartridge has some advantages, as well as disadvantages, but IMHO there are more advantages, for example, the MEMLO can be very low (~ $1000 is normal). I am strongly convinced that the SDX is the most advanced DOS for 8-bit Atari (its functionality practically equals MS-DOS).

everyone knows. (including god) Hardly No, he is right this time. Every cheap crap sells well, and everyone knows that.

It is not intended to speed things up. It just allows new programs to fully utilize the 65C816 potential (i.e. the "native", 16-bit mode). Sorry for the lack of precision on my part - I was wondering about the combination of the board with the OS - and hence the increase due to the faster CPU and, in certain instances, the faster routines in the OS (E: and floating point come to mind as places where you've optimized the OS). These are somehow faster in the OS, yes. And I already have an idea how to accelerate E: more radically. As for the floating point, I think that ROM is clocked still at 1,77 MHz (or 1,79), so the speedup is not too significant. And this is good because otherwise SIO would not work, or could have some problems. For the same reason, I also expect problems in the SpartaDOS, which loads its SIO drivers into RAM. In Sparta X we already added loop calibration to tune the SIO delay loops in case the machine is accelerated. As for the FP, Initially I wanted to use the Charles' Marslett FASTCHIP and speed it up with 65C816 instructions, but I dropped the idea after I have discovered, that FASTCHIP conflicts somehow with Turbo BASIC XL, so that TBXL operators "raise to power" and "LOG" do not work correctly.

It is not intended to speed things up. It just allows new programs to fully utilize the 65C816 potential (i.e. the "native", 16-bit mode).

If $130 for a fully programmable and customizable GTIA replacement is a high price, and $75 for a "simple hackable thing" is low price, then someone here has a problem estimating what is worth money, I'd say. "Especially these days", when US dollar is cheap. Despite that, in serial production, I think, it would get a bit cheaper, if it matters so much - $130 was just the price of the first 20 VBXEs.

Yes, you plug it directly in the motherboard. I can't see how your second sentence is related to the first. We have been hearing about Atari computers for 30 years, does this mean that they're somewhat overengineered? But there is no ANTIC bus (I mean the lines by which it controls the GTIA) on the CART/PBI connector. Which means that you either get no compatibility or crap display - while VBXE offers both. So it is a matter of tradeoff something for something else. And btw. VBXE exists. I have one. There was a demo distributed some time ago in a form of an AVI file or something. So you had an occasion to see, how If not, I can tell you: without problems. What does mean "expensive"? The cost of an unit is about 300 PLN (not counting shipping), which is equal to 130 USD. This is less or more the price one paid for Atari 65XE in late 80's, and the computer at that time was CHEAP as dirty water (in terms of Western prices, of course, because at out side of iron courtain 130 USD was an incredible lot of money, maybe something like 5000 or 10000 - five or ten thousands - USD now). So at this price, VBXE exists, offers compatibility (with existing software and existing hardware, including existing cartridges), flexibility, incredible features, and its display is of top quality (its it RGB, so the picture sharpness is no worse than on VGA). Since I am an Atari enthusiast, I can pay this price for top quality enhancement for my computer, and I wouldn't get a cheaper (note: not cheap, only _cheaper_, we heard about 50-75 USD, if I remember, so this is around a havf of the price you pay for VBXE) replacement that, offers much less, and does not exist (yet). Exactly like I prefer a more expensive, but top quality hard disk controller instead of the (insert here the adjectives you prefer) MyIDE, eventhough it is cheap, or in the past I preferred a disk drive over the cassette recorder, eventhough that latter was something like 1/10 of the price and was "easier" to operate. So, like I said, this is a matter of taste. Besides, I am not going to advertise VBXE here, for I do not sell nor produce it, and I am not an expert of its internals and operation either. For details, if any doubts remain, you can mail its author, i.e. electron.

By the way, electron, whom I met at the Głuchołazy meeting this year, has promised a 640-pixel mode for VBXE (with RGB quality).

Much more I would like to talk to the original Sparta X developer, as there are traces of some ideas in the code, which haven't been implemented. Such things can be now made, but first I would like to know what the original idea was behind this and that. For example, there is a subsystem called BLOCK_IO, its even mentioned in the user's manual. It has 5 functions defined, and all of them are called by the filesystem driver, but only three are actually implemented. What was the projected purpose of the remaining two, I can only guess (and I do). Also, it seems that it is not an accident at all, that SDX is so similar to MS-DOS. From some parts of the original code one can have thoughts that it originally might have been an actual MS-DOS clone. For example, in 4.22 the code of the SEEK function is totally brain-damaged (and it doesn't work well, we had to rewrite it), but, actually, its structure perfectly fits the method the SEEK should be implemented for FAT filesystem. So, you see, I really would like to swap some mails with the original developer, whoever he was