Jump to content

drac030

Members
  • Content Count

    2,598
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by drac030


  1. 20 hours ago, bob1200xl said:

    100 kilobytes/s on the PBI, I think.

    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.

     

    • Like 1
    • Confused 1

  2. 37 minutes ago, ldelsarte said:

    So, you turn on the computer and its built-in floppy drive at the same time. This is why the OS is modified to not display "BOOT ERROR" right away and wait for a floppy disk to be inserted.

    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.

    • Like 2
    • Thanks 1

  3. 10 hours ago, Stephen said:

    So far, so good.  However, poking with $82 in order to prevent the ATASCII - ASCII translation does not work.

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

    • Like 2
    • Thanks 1

  4. It will work with anything provided that the disk's geometry is the same as in Indus CP/M, that is: 1 side, 40 tracks, 18 sectors per track, 128 or 256 bytes per sector, two first tracks reserved, block size 1k, directory size 1 block in SD and 2 blocks in DD. Also, in DD soft interleave 1:1 is assumed, and 1:5 in SD.

     

    It could be configurable, of course, but there was no demand :)

    • Thanks 1

  5. I would guess that "DM" = Display Memory. It is calculated correctly regarding the RAMTOP. Just it is not regarding the Antic inability to cross a 4k boundary without the LMS. Thus if lowering RAMTOP for GR.8, one should always lower it by 4k (16 pages).


  6. I have uploaded version 0.94 to the same address as above.

     

    One major new thing is that ELSA is now able to generate SpartaDOS X relocatable binaries. I seem to have managed to make SpartaDOS X support more flexible than in MADS (let alone FA), for example, all 65C816 instructions and addressing modes will generate fixups, where applicable; also, labels declared as external symbols can be used in arithmetic expressions, the result of such an expression will then generate the external reference record when used, e.g.

     

    	.xref COMTAB
    
    lbuf = COMTAB+$3f
    ...
    ...
    	lda lbuf

    "lda lbuf" will cause the XREF record for the symbol "COMTAB" to be inserted into the object file.

     

    Also, fixups work between program blocks loaded to different 64k segments. To use this one will need to load an additional extension module, which will come with next beta release of SDX (on the Toolkit).

     

    • Like 5
    • Thanks 1

  7. 18 minutes ago, Kaj de Vos said:

    Yes, on SDX, not on previous SpartaDOS.

    I know, I am just saying that it is no matter that the manual says "Dx:", because this does not forbid using "D:" anyways. Of course SD 3 (maybe except 3.2g) has no concept of current drive IIRC, so what is "current" must be established by other means.


  8. 5 minutes ago, Kaj de Vos said:

    I will have to see if the problem is in my code or in CC65.

    After the recent, much revealing discussion on the left margin issue in CC65 libs, I would not be much surprised if it was the latter.

     

    6 minutes ago, Kaj de Vos said:

    Does SDX still take the original > SpartaDOS path separator?

    Yes, "\" and ">" are equivalent as path separators in SDX.

    • Like 1
    • Thanks 1

  9. 42 minutes ago, Kaj de Vos said:

    Is there any change in SDX in the XIO command for getting the working folder, compared to SpartaDOS 3?

    To be honest, I do not know - my first SpartaDOS years back then was SpartaDOS X and so it remains until this day. The CIO is not often used in SDX utilities, so I just checked, if XIO 48 works as advertised in the SDX User's Manual, section 6.3.18. But it seems so:

     

    obraz.thumb.png.e9243b57df791ce8c435048e6cb14188.png

     

    The program:

     

    test.zip

    • Thanks 1

  10. It seems that the limit of TSR programs initialized at reset has been exceeded. It is pretty short I admit (5 or so), SDX drivers do not need it, but OS drivers (E: and such) do, you install four of them... Try installing TSR.SYS (it is to be found on the Toolkit disk) as one of the first programs after SPARTA.SYS/SIO.SYS/[clock].SYS, then see if it helps.

    • Like 2

  11. Unless there is more out in the wild than I have, the "original build tools" consist of these files:

     

    1) XASM65.EXE, or "ICD Cross Assembler", serial number #0001 :)

    2) MAKECAR.EXE

    3) MAKEBIN.COM

     

    The first two are MS-DOS 8086 executables and do not work on Windows. Both are written in Borland Turbo C. There is the source module for MAKECAR.EXE.

     

    Also there is a source module for XASM65.EXE, named XASM65.C, but, judging from the project file XASM65.PRJ, it is only one source file out of the total of about 20 other *.C and *.H files, and apart of that one all others are missing.

     

     

    • Like 1

  12. 2 hours ago, ivop said:

    Unless it is proven to be better, and is indeed picked up by the community. Then either the DLT version vanishes, or you merge back the improvements

    Well, look around, then define "proven" and "better". Grab sources to some latest beta, change version to 6.0, add dancing hamsters, release, see what happens. As long as I could have something to say, I would not take chances. The fates of DR-DOS may indicate that it might not necessarily always be the worse-quality or less honest party which "vanishes".

     

    Plus, you seem to be optimistic about "merging improvements". This is an OS, it has to interact with software, some decisions in this field are and must be arbitrary, and relocating one internal variable arbitrarily may create an unsolvable conflict. And we do not have unlimited resources of CPU power and virtual memory to resolve such situations. So I would prefer to just get shit done instead.

    • Like 2

  13. 6 minutes ago, ivop said:

    Fear of forks is ungrounded IMHO.

    In the PC world, maybe. Here I know at least one individual who would love to release an incompatible fork just to create a conflict and get attention.

     

    7 minutes ago, ivop said:

    1) If the source was available in the first place (after there was no more money made on the binary project), that would have saved a lot of time and effort.

    Certainly. But it was also a very exciting adventure, to gradually discover how unusual and how advanced the SDX is as a DOS for Atari.

     

    9 minutes ago, ivop said:

    2) The current SDX is based on pirated code

    If so, then what? The copyright holder is free to sue DLT over that at any time. I would be very interesting lawsuit, I think ;)

    • Like 2

  14. Just as a side note, regarding, possibly, writing new kernel drivers, the analysis of SDX 4.21 sources would probably not help much, because SDX 4.2x does not allow new kernel drivers to be defined at all.

     

    I will expand the existing documentation with the chapters on the kernel etc. so that the (otherwise praiseworthy) desire to "study" the source code could be possibly alleviated.

    • Like 4
    • Thanks 1
×
×
  • Create New...