Jump to content

drac030

Members
  • Content Count

    2,578
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by drac030

  1. The poll lists things which I either already have (CPU accelerator, 80-column solution, audio expansion) or can write myself (the software part) or do not need (pretty much the rest). This leaves me without options to vote for
  2. What about building something smaller first, but actually working?
  3. Just stick to $80-$FF and $0400-$06FF, if you really really need. Otherwise just use the regular and extended memory. By loading stuff into the OS locations you are only praying for problems. Experimenting may lead to obscure problems which will get difficult to debug in the future. Also, the golden rule: write a working program first, optimize later.
  4. No wonder. Everything from $0349 onwards deemed "locations used by BASIC and OS but not needed by program". Including the IOCB #1 MyDOS binary loader uses, along with the MyDOS binary loader itself and the entire MyDOS.
  5. This probably is the reason for the bizzarre behaviour you are observing: you are overwriting vital system areas then are wondering why the system does not work. Just post a binary file you are trying to run, it will probably get clear quickly, why it does not work.
  6. 132 is "BAD CIO COMMAND", your program is invoking the CIOV with an invalid I/O command code stored in the control block.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. Could you post an example? I seem to not be able to spot any, but perhaps I am looking at the wrong place.
  17. 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.
  18. 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.
  19. 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
  20. 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?
  21. 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.
  22. 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.
  23. 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
  24. 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.
  25. 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.
×
×
  • Create New...