Jump to content

drac030

Members
  • Content Count

    2,578
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by drac030

  1. XEP80 fans would probably love the updated XEP80.SYS driver in current SDX, which is accompanied with a tool to tune the display parameters live. I am not sure, though, if the current beta is ready to be released. @phaeron could you add a separator after BRL?
  2. 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.
  3. 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.
  4. 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. 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. 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
  5. 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.
  6. Setting the opening of the source code aside for now, it was said something about extension of SDX. "Extension" implies that something is lacking. I would be interested in learning, then, what ideas of possible extensions people could come with.
  7. Since Fujidude has not logged on for a long time now, I have incorporated these scripts into the Toolkit disk so that they would not perish. I have now updated the comment. Also, there is a 4.49 already
  8. Indeed, a typo on page 125. I have sent a mail to the documentation master, @GBXL, about it. Thank you.
  9. READHEX? You have to run it with the X command.
  10. I do not know really because I do not use RespeQt. Anyways, write speed is the rate at which the Atari sends the data. Read speed is the rate at which the PC sends the data. Maybe there are big intervals between the command stage and data stage and that is why the overall reading speed is lower than expected. Why the writes seem slow too, I have no idea. As I said, the figures you get are only slightly better than normal results for US=2:
  11. The only thing abnormal in your setup is the effective speed around 7 KB/s while the bitrate is 125 kbps. If I have to guess, it might be due to retries occurring because the serial connection is not stable. Here I am getting effectively about 9 KB/s at nominal bitrate 98 kbps (US index 2). Correction: this is PCLink which gives me that. On a 512-byte ATR I get about 7 KB/s like you. Still, this is US=2, not 0. And no, deleting the file at the end would not affect the benchmark results.
  12. It is the RWTEST deleting the temporary file.
  13. It does not. The error is real, but that code is not used anywhere anyways.
  14. It is a game for three players, obviously.
  15. That sounds like an idea for an ultimate game: Press Start to win, press Option to lose, press Select to pause.
  16. Or maybe replace "START to begin" with "START to win" to make the game even more fun.
  17. Because it is easier to dream about new hardware than to write a program for the actual one. We really have the hardware and the tools - the number of programming languages will probably soon exceed the number of programmers, if not already have. This is the lack of manpower what beats everything.
  18. That is true. GBXL sent me disk images he created with versions of RespeQt later than 4.0. It looks like the program accepts 512-byte sectors, but calculates offsets as if the first three sectors were 128-byters. This is how it looks like: The underlined row is the first 16 bytes of the bitmap. It has been written at offset $90 ($80 of image data, not counting the header), and this effectively overwrote the large part of the sector 1, which contains the bootloader. Here the bootloader is cut short at its very beginning. The underlined data is supposed to be written at the offset $0210 instead. Next figure: Now what is it? Sectors 2-17 contain the disk bitmap (VTOC). This is an empty image, so all the bits, except for the few initial positions, should be set, indicating that the corresponding sectors are free. Yet in the middle of that area we have 384 bytes of zeros. Next figure: This is the beginning of the main directory data sector in the image, sector 19. (19*512)-512+16 = $2410, and what do we see here? $2290 - 384 bytes earlier. No wonder why these images cannot be read.
  19. You are speaking of VBXE? It does not generate sync signals, 50 or 60 Hz frame comes from the Antic. @Faicuai I am sure that you are right, first impressions often define taste for something for years. But I was not speaking of that. Actually, the first computer which had a hardware 80-column mode I saw was Amiga 500. Then PC/AT with Hercules card. Then Atari ST. Then XEP80. Then, yup, IBM 3270 (or was it 3290? I do not remember), because there was a node of EARN at my university. But, as said, I am not speaking of the 80-column screen itself, just of Atari 8-bit system font displayed in that resolution. It got me immediately, probably because it was both familiar and new at the same time. Also the 1090 80-column board uses this font (AFAIK), so it probably looked equally well.
  20. I must say, that when I first saw how the standard Atari system font looks like when displayed in 80-column resolution, I was very impressed. It looks as if it was drawn especially for this purpose.
  21. I also did a search. "Shit" returns 370,000,000 hits. So, please, what was your argument, again?
  22. If SpartaDOS 3 source code is available, maybe someone could consider fixing this:
  23. I know that I also know that for you it is the cause to reject the device, but that does not deny basic facts: that XEP is a very miserable 80-column solution, being slow, kludgy, producing awful display. Worse even, even built in its times, it could be better, it has just been awfully engineered. It seriously looks like someone's kid project for school. What for? You already have the ALT*.SYS drivers, what is the point in creating them again? It is true that this forum is pure waste of time, thus I indeed tend to avoid it, but I must admit that it is entertaining sometimes and I cannot resist
  24. Why? The topic is "what is hot in 80-column upgrades". Some (minority of) disputants promote the agenda, that XEP80 is the hottest thing we have now, whereas some other (who actually have XEP and VBXE) disagree. What is the reason to stop discussing it?
×
×
  • Create New...