Jump to content

drac030

Members
  • Content Count

    2,598
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by drac030


  1. 4 hours ago, Stephen J Carden said:

    Once again why are people loading and running this file when it is a problem file. (...) Draco was kind enough to turn it back into source.

    The source code presented in post #3 is an extract - in source form - from a larger program of mine, and the result of my debugging, why that program crashes badly while being loaded under SpartaDOS 3 and derivatives, whereas in the rest of the DOS-es listed it loads and runs fine.

     

    The listing pinpoints the exact code which causes the crash (in init1), and, because that code seems completely legit, the cause of the crash must be a problem inside SpartaDOS 3 binary loader, which goes bananas when an init segment is doing an OPEN call to the CIO.

     

    It may be actually very simple to fix, e.g. perhaps some internal channel number should get preserved across a call to jmp ($02e2).

     

    I know that people have teh SpartaDOS 3 source, and Real.DOS has its active developer, so this could get fixed. That is why I posted this, just as a bug report.

    • Like 3
    • Thanks 2

  2. The "Image" in the first post is not visible (at least for me). So I am not sure what version of SDX is this.

     

    There was a problem with pathname end detection before, but it should be fixed as of 4.49e. Generally the problem is that path and file names should be EOL-terminated, but many programs neglect the termination, assuming that the DOS will be magically able to detect the end of a file name, no matter what binary garbage follows. Before 4.49e this magic sometimes led the DOS to believe that what follows is a path separator, and (consequently) that the file name given is a directory name. Thus error 150 "Path not found".

     

    As I said, the magic should get improved as of 4.49e. If it still fails, a test case would be most appreciated.

    • Like 1

  3. Even if "undocumented entry points" are in fact documented somewhere, this does not automatically mean that they are to be used by direct JSR calls. There are two different things: 1) the, as they say now, API contract, and 2) things documented "for your information".

     

    The API contract is the stuff the OS designers guarantee to work across all OS revisions. Like CIOV $e456, accepts input parameters such and such, does this and that, returns this in X, that in Y, A is sometimes defined, but most of the time undefined. "Undefined" means that the returned value may change across OS revisions, because that value is accidental from the point of view of the program: it depends on the method used to execute the defined OS function, but the methods are in fact private internals of the OS (or any program, in fact, which exports some function to be externally called) and cannot be relied upon; some better method (shorter and/or faster) of doing things may be used in the next revision and thus the "undefined" stuff returned may change.

     

    The same applies to the location where the actual OS routines reside: the actual address is most of the time accidental and belongs to the category of methods; and methods are private to the OS. It is often good to know what are the side effects, performance etc. and this its the reason for documenting such stuff as "FYI" - but relying on them is just praying for problems.

     

    As about the ROM vectors at $E400, it should be remembered that only the default drivers can be called that way. In fact all CIO devices should be called so that the call goes indirectly through the HATABS.

    • Like 2

  4. 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.


  5. 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.

    • Thanks 1

  6. 3 hours ago, Wrathchild said:

    858E B9 F5 FF                LDA    unk_0_FFF5,Y

    903A B9 F5 FF                LDA    unk_0_FFF5,Y

    ...

    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.


  7. 17 minutes ago, Wrathchild said:

    Having delved into the code in trying to port this CC4 to the 5200 I would say a Rapidus patch would probably be tricky due to the code using some very odd use of indexing into the zeropage by exploiting wraparounds.

    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.

    • Like 3

  8. 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.

    • Thanks 1

  9.   

    6 hours ago, devwebcl said:

    Colossus v4.0 has a catastrophic bug, in which it can lock up endlessly (most likely while the computer AI is thinking to move), v4.1 fixes this by changing just 2 bytes, the only instance of $D0 $FE changed into $EA $EA to make v4.1 which was patched, not recompiled.

    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

     

    • Like 4

  10. 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?


  11. 15 hours ago, Peter Rabitt said:

    I am still trying to get programs off the sd card to floppy disk to use in test and repairing disk drives 1050 and the  Indus. Yes I downloaded the programs from the web. Most here from our users and them moved them to the SD cards from my pc... I can see them when I boot one of the SD type units but have no way to move them to the drives...If I boot with SDX i get 0000 free sector when i try to access the SD cards.

    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.


  12. 10 hours ago, Faicuai said:

    "Absolutely The Best and Most Powerful 8-bit Disk Operating System (as of 9/2021)".

    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.

    • Like 1

  13. 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

    • Like 7
    • Thanks 2

  14. 9 hours ago, phaeron said:

    #1 and #4 may be tricky or slow as it's not easy to check for 'unmapped' -- open bus reads are actually another kind of mapped, plus the debugger will insert memory layers.

    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.

    9 hours ago, phaeron said:

    I'm curious about #3. Is 16MB wrapping really an issue? SBC $FFFFFF,X I could see as it's $FF FF FF FF and probably a bogus insn, but LDA $FFFFFF,X only when wrapping?

    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.


  15. 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.

    • Like 1

  16. 2 hours ago, ivop said:

    Use those 8-bits (the instruction) as the address bus to a 256B EEPROM, and latch its databus with a shifter. Now you have 8 bits per instruction to determine whether the bus is needed or not

    ... 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.

    • Like 1

  17. 7 hours ago, Xebec said:

    Please educate me here -- is this the case even when the 6502 is executing instructions that take several cycles to complete?  

     

    Like if an instruction takes 6 clock cycles to execute, it needs the memory bus for all 6 of those cycles?  

    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.

     

    7 hours ago, Xebec said:

    And just to make sure I'm understanding, a 65C816 at double speed might be a better bet for a simple no-cache speedup?  

    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.

     

    • Like 2

  18. 49 minutes ago, Irgendwer said:

    I don't think that this is true.

    What about the single byte 2 cycle instructions (e.g. CLC, SEC, TAX, TXA) ?

    What about the additional cycle when crossing a page boundary or performing a branch?

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

    • Thanks 1

  19. 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.

    • Like 2
×
×
  • Create New...