Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by drac030

  1. Rosetta stone is not very relevant here, because now we are living in the times after the Rosetta stone (so one can learn hieroglyphs from a textbook), and also there were times when the knowledge of the hieroglyphs had not been lost, and you were able to learn them from a teacher. So for the sake of a better analogy, we can say that it is Greek instead of hieroglyphs (because the knowledge of Greek has never been lost). The point, at least as I understand it, may be somewhere else. You are claiming that Meta has "Human-friendly syntax" and is "Closer to human language than most computer languages". Perhaps it is so. But for the untrained eye, the examples available in this thread contain much too many usual code symbols (=, [], ~ etc.) to be recognized as a human language: perhaps it is "closer", but still not does not look like close enough. For example: unsafe!!! constant reference volatile byte! [ RTCLOK= ~14 ] In human language it would be rather something along the lines of label volatile byte number 20 as "RTCLOK".
  2. By this definition ("learn it") pretty much everything is "human-readable", even Egyptian hieroglyphs.
  3. So far he has not even been able to explain this: Basically, "nothing works, see, how bad it is", but when asked about details, then "oh, I do not know exactly". Gosh.
  4. Yup, might have been. Like 10+ years ago. So how long ago you tried and which version of SpartaDOS we are talking about?
  5. What FDISK? FJCs FDISK works on VBXE in 80-column mode. True, it is about just the only program which does not display itself in VBXE 80-column mode. What is "the menu system"? SpartaDOS X MENU _does_ work in 80 column VBXE mode. Program names of that other stuff, please? Even approximately.
  6. Not sure. As said above, VBXE outputs the same kind of signal as Amiga or Atari ST. Monitors like Commodore 1084S, 1085S, Atari 1224 or 1435, European TVs with SCART connector should be okay. Any converter from that format to VGA/HDMI should also be okay.
  7. Yes. Nowadays everyone has the luxury of being able to contact active developers directly, either via e-mail or through the fora. It is not 1990, when, to get some support, I had to send a letter written on paper (and in a truly alien language!) to the other half of the globe, only to receive no reply just after six months. And now, as to the point being raised, we all are here on AAge. Maybe not every day, but still. So, what, specifically, are the things that do not work, when they should?
  8. VBXE does not produce own sync signals, these still come from the standard Atari hardware. So if the monitor got the signal from the outside of its normal range, it definitely was not the fault of VBXE, but rather the fault of your scaler. NATURALLY. It is not NTSC, nor PAL. It is RGB. No artifacting or any other color distortions in RGB. "Utils" need to use system calls to produce display on 80 columns (e.g. TBXL is able to draw a circle on VBXE display - a miracle problably). Otherwise, when the ANTIC screen memory is written to directly, it obviously will produce no display on VBXE (nor XEP80 nor on anything else).
  9. While that is an undoubtedly true statement, we do not assume that OP is a 5-year-old kid and does not know that? Or that he does not know that asm, cc65, Mad Pascal exist? Or what they do or what they do not, or what they can or what they can not? Or that he should do that thing and not the other? Just re-read the very post which led to the thread having been derailed, especially its beginning. I will say no more, I do not want to pollute this thread with more irrelevancy.
  10. I agree with OP here, the thread has been derailed, additionally in a very embarrassing way (unfortunately, I am not able to express Polish "żenujący" any better). So closing this one and starting anew - without involving himself into pointless discussions about asm, cc65 or MadPascal - seems quite a rational decision.
  11. This also assumes that English syntax is human-friendly
  12. If SDX relocatable format is supported, could you provide an example of the "Hello World" program using the PRINTF library call?
  13. No, and my own FreeBSD box is an i386, so even if I upgraded the system to 12+, it would not help much, I guess. But do not let it bother you, I am writing my stuff exclusively in assembler anyways and I prefer to do that directly on the target machine, so I am only marginally interested in high-level programming languages, the less if these are cross-compilers only.
  14. Use the X command to run the program. The "unknown BASIC ROM" is in fact the SDX Library ROM.
  15. I tried it on an AMD64 PC running FreeBSD 10.1. The result: illegal system call (core dumped).
  16. Or special startup code which does its best to overwrite the binary loader
  17. Man, I do not care what it is or what it is not. It is you who wants support in ATARIDOS.SYS, so it is your problem, not mine, to make the format reliably detectable among everything else.
  18. Something changed, though: I was getting bug reports about false positives in identifying disks as LiteDOS format which were not. That is hardly surprising, because just only one byte, which additionally can show values anywhere from $41 to $7F, is hardly enough to identify the format. Just bear in mind that not the entire world consists of AtariDOS II format. In nearly any other disk format (SDFS, FATFS, CPMFS, Atari DOS 3) sector 360 is a data sector and can contain anything. In AtariDOS 4 the first byte equal to $43 in sector 360 identifies the disk as double sided. Similarly for innumerable bootable whole-disk programs and demos. Thus to avoid falsely positive identifications, I had to extend the check to further bytes of VTOC, where the text "LiteDOS" was present. But in new format it is missing. So the SE version does not provide any certain method to identify its format for sure, and in the current state of affairs it only increases ATARIDOS.SYS's susceptibility to recognize disks which it should not recognize.
  19. @mr-atari I noticed that the SE version's disk format is apparently not the same as in the example disk images you submitted some time ago to us to get the read support implemented in SDX's ATARIDOS.SYS. Does this mean that the old format is abandoned and support for it should get removed?
  20. The size difference made me curious, because my copy does not have any visible bytes of garbage at the end (or anywhere), so I have downloaded the ATR from AtariWiki to find out the differences. Here is the file structure of the "original" (18104), with two interesting points indicated: "Segment A", 2 bytes in size (or 6 including the header info) just sets the MEMLO to $3629. And here is the structure of "my" TBXL binary (18108 bytes): My copy is 4 bytes longer, because it has 10 bytes more code, but at the other hand the segment setting the MEMLO is missing. When you run the program however, the MEMLO still gets set to $3629, so it seems that the absence of the first segment does no harm. Let us take a look at what makes the "segment B" longer. It gets loaded at $6000, extends to 1 page and a half and consists seemingly mostly of code. The additional code is located at offset 71 ($47) from the beginning and looks like this: 00:6047: A9 29 LDA #$29 00:6049: A0 36 LDY #$36 00:604B: 8D E7 02 STA MEMLO 00:604E: 8C E8 02 STY MEMLO+1 So this sets the MEMLO to $3629, compensating for the missing segment A. The rest of the differences in the segment B, as far as I can tell, are confined to the shift of addresses resulting from the insertion. So in the "original" we have JSR $6101 immediately before, and in my copy this is JSR $610B (+10 bytes shift) etc. This does not look to me like a binary patch. Quite contrary, the differences in the section I am calling here "segment B" look as if these four instructions were inserted, then the entire program reassembled from source. In other words, it looks like a later revision made by the author. That binary I am quite sure that it is the same copy I got on cassette in the middle of 1988 (or maybe early 1989). The datestamp it bears now is most probably the day and hour when I copied TBXL from old floppies to a subdirectory on my first hard disk, then did CHTD on the contents of that subdirectory (and yes, the runtime and the compiler have the exact same datestamp). In any case, the "segment A" in the 18104-version looks like a quick patch to setup the MEMLO, added last minute before release. Then, when the tape version was being prepared later, that patch has apparently been removed and that snippet of code was inserted instead. Mine, taking the 4-byte shift into account, matches the values on the left. Also, the differences definitely are not related to DOSINI/CASINI initialization, this is some FP code which differs here and it more looks like accidental damage than a patch. I would not trust the version on the right untill proved that the changes make sense.
  21. TBXL 1.5R, SpartaDOS X, Rapidus, fully loaded config: So it is really relocatable and respects memlo. However, it has a bug. Details on PM to @dmsc
  22. Ah so, if you are so good at identifying the patched versions vs standard versions, please identify this one for me then: TBXL 1.5, 18108 bytes, md5 38C6E6F99BA101341A41595C0FFBF03B. On my hard disk it is dated 24 June 1996, 20:52:00.
  23. Maybe post it, then, because I am very curious about a version of TBXL which gains 8k of user memory having dropped the memlo by about 4k. "Standard" TBXL is 1.5, 34021 bytes free.
  24. TBXL has its bottom memory location hardcoded (at $3629), and MS-BASIC *probably* looks at memlo ("probably" I am adding in afterthought, because it has been long time since I used MS-BASIC last time, and my memory may be failing me). In any case, dropping memlo no matter how much does not gain any memory under the regular TBXL, ?FRE(0) will be 34021 even with no DOS at all.
  • Create New...