drac030

I did not analyze the Colossus Chess code, so I cannot say why this or that instruction was used in that particular place of that particular program. But the most common cases have already been provided: 1) X is already in use, 2) you forget that zp,Y is in fact abs,Y.

Possibly (with the margin of probability that he might have overlooked the fact that LDA zp,Y did not exist). But what is the point? PS. "must have written" and "must have known", if I am not mistaken.

As said, there is no LDA/STA zp,Y addressing mode, so abs,Y is used instead when X is not available for a reason. Assemblers usually automatically (and silently) promote LDA $80,Y into LDA $0080,Y, so with some bad luck you can live half your life not even fully realizing that LDA zp,Y does not exist. The wrap-around could of course be intentional if the author is a pervert. But most people are not, thus I think it is more probable that the negative base address comes from the accident I sketched out above, i.e. addressing some zp table with index register increased by some constant, this constant being subtracted from the base address: LDA zptable-$80,X. Then moving "zptable" below $80 shifts out the base address below 0, which most assemblers silently accept.

Noone. That is the decision of the assembler ($xx-constant, where constant>$xx) without the coder knowing. Sadly, same with STA $FFFE,Y which is much harder to avoid.

Replacing the absolute,X mode with zp,x (i.e. e.g. STA $FFFE,X with STA $FE,X) should fix the wrap-around problem. Or rather replace it with another wrap-around, but not so problematic this time.

This gave me right direction, thanks, there are indeed wrap-arounds at $6ec4-$6edc and $6ef9-$6f0e (both places being undoubtedly code). But, what is baffling me: my binary file generally does not match your list. I have loaded the program without execution, but e.g. code at $903A is SBC #$09 and not what you listed above.

Could you post an example? I seem to not be able to spot any, but perhaps I am looking at the wrong place.

Ah, so. Having just casually looking into the code I did not see that, but that is possible. In that case, however, the real Rapidus Accelerator has some provision to fix that: you can enable mirroring of the zero-page at $010000-$0100FF. And indeed, with this enabled, the situation seems to be improved even at 40 MHz. So my guess about the race condition seems to be wrong.

Altirra's Rapidus emulation (System->Configure System->Peripherals->Devices->Add->Internal Devices->Rapidus Accelerator) is not very compatible, e.g. SysInfo did not work on it last time I checked, but in this case I do not think it is a real problem. Even with the generic turbo mode Altirra offers (System->Configure System->CPU->65816), Colossus Chess 4.0 indeed tends to do illegal moves or plainly hang. The problems seems to occur even at 10 MHz or 7 MHz. So I guess that the program has a race condition, that by accident does not occur at 1.77 MHz. I guess that would not be very easy to fix.

That instruction ($d0 $fe) is "BNE *" which, indeed, is an infinite loop and causes the program to hang whenever it enters it with the condition not met (Z=0). I would however refrain from calling this a "catastrophic bug". I would also refrain from applying that patch relying on the current information. First of all, it is not a bug, it looks intended. Before trying out that branch instruction the program calculates a checksum (out of its own memory), and then, if this checksum's value is anything but the expected value, it enters that loop and indeed hangs. So it is rather some sort of protection against unauthorized modifications and such, and should not influence the program if it is not internally modified. Second, that code cannot influence the program's execution, because it is executed only shortly after program's start, and when the chessboard gets drawn, that area of memory is zeroed out. So any possible hangs during the match cannot be directly related to that loop. I would rather suspect that whoever experiences them, has a hardware problem with his Atari (failing RAM, most probably). In any case, the patch does really nothing, it just cancels that integrity check (or its first stage). I guess that if I am correct that comment on Atarimania should get deleted, because it is misleading (and even blames the author of major failure in programming). @www.atarimania.com

The disassembly window seems to have problems when the listing begins at address below $0080, and especially at $0000 (in 65C816 mode also in higher addresses like $3F0000). Setting the address at $0000, then clicking down arrow causes the address field to automatically count up. Then after reaching $82-$83 it either stops or resets to $000000. In 6502 mode, could the disassebler display illegal instructions as "???" instead of interpreting them, when they are not enabled in the options?

Could you provide exact steps to reproduce that effect? SDX should never display "0000 FREE SECTORS" on the media it does not recognize, UNLESS the file system on that media is severely messed up.

From my experience with Atari I can certainly say that SpartaDOS X is extraordinary as a DOS for Atari, but perhaps it can be named so without involving the Absolute. I am also sure that "8-bit" there is meant as "Atari 8-bit". In the Atari 8-bit world I do not know of anything which could be comparable. As for the 16/32-bit world, certainly the ST TOS is more powerful being windowed, having some (limited, but still) multitasking capabilities, being able to address big disks etc. SpartaDOS X is close to some of that, though, all the more considering the limited resources it has to live with. I am sure that there may be other 8-bit operating systems which in themselves look (and perhaps also are) more powerful, like perhaps GEOS, SymbOS etc. (also FJC's GUI). SpartaDOS X in this company does not look very impressive, but has (IMHO) the great advantage of being backward-compatible: all the new features aside, one can still run programs which were written long before SpartaDOS was even intended. Its internal design is certainly well-thought and ingenious. The deficiencies, if there are any significant ones, are mostly just human errors in the implementation.

For the interested, here is one chapter out of the SpartaDOS X 4.50 Programming Guide, which is now being in the works. The chapter in question is about SIO (Sector I/O) device drivers in SDX. Subsequent chapters on the kernel drivers etc. are planned, but it will take some time considering that the relatively simple matter of the SIO driverage took 8 pages. Critical remarks (including related to the language) welcome. sdx_sio_drivers.pdf

I thought that attempted accesses to the unmapped area might be detected if that area generated some sort of exception. Such as the ABORT interrupt. But it is of course up to you to decide, if it is possible or worthwhile. #1 is rather important (that is why it was 1 on my list in the first place). The scenario: code or stack corruption cause the program to jump to the unmapper area. That area is filled with $FFs, which is a valid instruction (SBC $FFFFFF,X), so it gets executed in infinite loop until the history buffer gets completely filled with it. So it usually takes a while before one could trace this back to the code which jumped to there. If the core stopped immediately, it would be immediately known too. So maybe the easiest way to achieve this is to fill the unmapped area with $00s instead of FFs. "Stop on BRK instruction" will then cause the wanted effect. It could be an issue as it would mean that there is a bug in the program which accesses the memory it should not. It is, by the way, the same with 6502 and 64k boundary crossing: programs do that, but I would not be mistaken much if I said that probably at least half of the time it is unintentional. I even saw an example, how it is made, in a source code: they used an off-the-shelf procedure and, without peeking into, put it to the memory much lower than its original author intended. And the original author used LDA label-constant,X or something like that. Due to assembling the code to very low addresses, the "constant" happened to be greater than the value of the "label". The result: negative argument of LDA and 64k boundary crossing, being a bug in the program.

Feature request. Could the 65C816 emulation optionally be stopped on the following conditions: 1) when the code jumps from the mapped RAM/ROM to the middle of nothing (e.g. to the addresses over $3FFFFF when only 4 MB RAM is mapped), 2) when the code jumps into the I/O area $D000-$D7FF; 3) when an instruction is trying to cross the 16 MB boundary (e.g. LDA $FFFFFF,X with X>0), 4) when an instruction is trying to reach into unmapped area (e.g. LDA $800000 when only 4 MB is mapped), 5) when the PC wraps around at a 64k boundary, 6) when the stack wraps around at $0100 and $01FF in emulation mode, 7) when the stack wraps around at $0000 or overlaps with I/O area in native mode, VIII) when the stack grows down to the zero page in native mode. I think the numbers 1 and 2 would be the most useful. The number 2 might also prove useful in 6502 mode. Thanks in advance.

... and be aware that one and the same opcode may be executed in different number of cycles depending on the internal CPU state. E.g. LDA abs,X is "normally" 4 cycles, but 5 when a page boundary gets crossed. In that latter case the spare cycle could not be detected, and so it could not be shortened. This would exclude quite a number of frequently used instructions in frequently used (i.e. indexed) addressing modes, and that in turn makes the whole thing yet less worthwhile.

Yes, as stated previously. For example, ASL absolute needs 6 cycles: a) 1 to fetch opcode, b) 2 to fetch argument, c) 1 to fetch operand, d) 1 to do the shifting, e) 1 to write operand back. Out of that the stage "d" is the internal operation cycle. Assuming you are able to identify, which cycle is internal, cut the CPU off the bus for that time and switch the clock to 3.5 MHz, you at best make the instruction occupy 5.5 instead of 6 cycles, i.e. you are gaining 1/12, that is, about 8%. Another is RTS: a) 1 to fetch opcode, b) 2 dummy cycles, c) 2 cycles to pull address from the stack, d) 1 to increment it. Out of that stages "b" and "d" can be shortened so that instead of 6 cycles the instruction takes 4.5. The gain here is at most 3/12, i.e. 25%. CLC: a) 1 opcode fetch, b) 1 dummy. By clocking at 3.5 MHz you gain 1.5 instead of 2 cycles, i.e. 25%. JMP: a) 1 opcode fetch, b) 2 argument fetch. No dummy cycles. Gain: 0. LDA abs: a) 1 opcode fetch, b) 2 argument fetch, c) 1 operand fetch. No dummy cycles. Gain: 0. And so on. Yes, because (again, as stated) it has signals which allow the external circuitry to identify the spare access cycles and act accordingly. But with just doubling the clock the overall speedup will be hardly worth the effort.

These are all memory-access cycles. In 6502 you have only one RW line and it always indicates either read or write cycle.

Long time ago (like around 2007) there was a prototype 65C816 accelerator. It could be configured so that the memory was running at the stock clock and the CPU was accelerated to 10.64 MHz (stock clock x6) - so the only speed gain in that configuration was from the internal CPU operations being fast, whereas memory accesses were slow. In that configuration the average speed gain was around 25%, i.e. just about the same as if you disabled the Antic DMA on a stock computer. I hope this anwers the question how much would one gain by just doubling the CPU clock.

On 6502 (unlike on e.g. 65C816) every CPU cycle = memory access cycle. So without accelerating the bus you would get nothing.

Ok, so this means that one sector is transmitted at 100 kilobytes/s. But 128 bytes per sector * 26 sectors per track = 3328 data bytes per track. 288 rotations per minute = 4.8 rotations per second. 3328 * 4.8 = 15974.4 bytes per second = 15.6 kilobytes/s maximum, with ideal sector skew. If so, saying to the press that the disks work at 100 KB/s does not seem very fair.

I have compared 1450XLD OS-es (there are two versions) with 800XL OS some years ago and I do not remember any difference like that. If I am not mistaken, 1450XLD drives are supposed to be PBI devices. Which mean that they have own ROMs activated by the OS as necessary (the same mechanism is used by Karin Maxi external floppy drive, or IDE+ HDD, or whatever else). The "necessary" time is e.g. OS initialization. The PBI ROMs get called one by one, so this would be the opportunity to check if the drive has finished initializations (and to wait, if it did not) and if there is a floppy inserted. At least, that is my guess. Surely I would like to know how these drives work, how fast they are ("100 KB/s" mentioned in the sources probably means 100 kilobits/s) etc.

Oups, a too-quick update apparently. What about now? svbxe109b.arc

Indeed, that function was busted. Try this: svbxe109.arc There is yet some bad interaction between this driver and the CON.SYS driver regarding the local color. The symptom is that after POKE $2F4,$81 (or $83) any new characters are not visible. I am currently not sure how to solve that, but there is a workaround: after POKE'ing as above, just do CLS or, if clearing the screen is not desirable, do POKE 711,PEEK(709) (i.e. copy the global foreground color to the local foreground color).