Jump to content

drac030

Members
  • Content Count

    2,598
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by drac030


  1. 26 minutes ago, 55five66six said:

    By RGB, you'd mean I'd need one of these to convert to HDMI?

    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.


  2. 43 minutes ago, wildstar87 said:

    I'm talking about utilities that are part of Spartados, not something outside of that.  I know you are part of the development team

    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.

     

    43 minutes ago, wildstar87 said:

    I'm not even necessarily complaining about the fact that these things don't work, it is just the expectation when people say, "yeah Spartados supports it.." That stuff should just work if it's part of the OS, and when it doesn't

    So, what, specifically, are the things that do not work, when they should?

    • Like 1

  3. 2 hours ago, wildstar87 said:

    I also tried to get a monitor that was 15Khz compatible, and while the monitor I got did display, it was definitely outside of it's normal range,

    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.

     

      

    2 hours ago, wildstar87 said:

    NTSC Artifacting does not work on VBXE (or Sophia), so some games like Flight Sim that use this to display color, will not render colors, and be essentially B&W.

    NATURALLY. It is not NTSC, nor PAL. It is RGB. No artifacting or any other color distortions in RGB.

     

    2 hours ago, wildstar87 said:

    Yes, the 80 column is nice, but limited to software with drivers, even in Spartados, not all things are supported, different add-ins, or utils do not work in 80 columns.

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

     


  4. 3 hours ago, ilmenit said:

    Many games in MadPascal or CC65 come with the sources available and designing a lang for 8bit Atari it may be worth checking how their are solving problems of e.g. memory alignment, built-in runtime functions, zero page variables/data or linking with music player.

    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.

    • Thanks 1

  5. 1 hour ago, ilmenit said:

    do not get oversensitive. Isn't "vandalizing" too strong word and making a new thread a bit overreacting?

    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.

    • Like 1
    • Thanks 1

  6. On 11/5/2021 at 5:21 PM, Kaj de Vos said:

    It turns out you need FreeBSD 12 or newer. Are you able to test on that?

    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.


  7. 50 minutes ago, ascrnet said:

    for some reason I don't know on your 800XL it doesn't disable basic as the RAM detection routine needs it disabled

     

    6 minutes ago, bf2k+ said:

    Yes my tests ae done with SpartaDOS X.

    Use the X command to run the program. The "unknown BASIC ROM" is in fact the SDX Library ROM.

    • Like 1
    • Thanks 1

  8. Quote

    Meta remote cross-compiler for Atari 8-bit


    * compile.ape Windows, Apple Mac, Linux, FreeBSD, NetBSD, OpenBSD

    This is a command-line program that takes a Meta program text and produces a binary Atari 8-bit program. So far, it has only been tested on Linux. We are interested in reports of success or failure.

     

     

    I tried it on an AMD64 PC running FreeBSD 10.1. The result: illegal system call (core dumped).

    • Thanks 1

  9. 7 hours ago, mr-atari said:

    You can still read LiteDOS disks as discussed.

    Since write-support is not supported in ATARIDOS.SYS, nothing changed in that respect.

    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.

     

    • Like 2

  10. 4 hours ago, GoodByteXL said:

    The original version on the 1985 disk from Happy Computer has
    MD5 (TURBO.COM) = 8EA3BF2EA89405AC347B2DBFAB5DE047
    and is 18104 bytes in size.

    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:

     

    obraz.thumb.png.85da40a59696d52f36f855e329149973.png

     

    "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):

     

    obraz.thumb.png.0bd105929ebe29927b6a600dba700f2b.png

     

    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.

     

    4 hours ago, GoodByteXL said:

    The difference of those two files:
    ?dif at 0042C1:E1 & 0042C1:E5
    ?dif at 004408:FD & 004408:F9

    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.

    • Like 5

  11. 40 minutes ago, CharlieChaplin said:

    All these patched versions still show 1.5 on the loading screen, some of them even still show 34021 bytes free.

    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.


  12. 13 hours ago, CharlieChaplin said:

    Mr. Atari provides a patched/changed version of TB XL, created especially for LiteDOS by one of the AA members here. That's why it gives 8k more RAM with LiteDOS.

    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.

     

    13 hours ago, CharlieChaplin said:

    But "standard" is not easy to define nowadays, since there are already various TB XL versions e.g. 1.4, 1.5, 1.6, 2.0, 2.1, 3.2q and maybe others.

    "Standard" TBXL is 1.5, 34021 bytes free.

    • Like 1

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

     

    • Thanks 1

  14. This would be less or more this in SpartaDOS X batch language:

    ;-NEW FILENAME.EXT
    ;
    PATHSPL %1,,,,,%X
    IF EXISTS $TEMPLATES$>*.$%X$
     COPY $TEMPLATES$>*.$%X$ %1
    ELSE
     COPY NUL: %1
    FI

    This requires the PATHSPL.COM command, which needed to be written and will be available on a next SDX Toolkit disk release.

     

    The $TEMPLATES$ environment variable must point to a directory containing the "templates", i.e. stub files for each filename extension. If one is not present, a 0-length file will be created, otherwise the template will be copied to the file name given as the parameter.

     

    The batch file of course can be made a bit more complicated by adding "categories", i.e. subdirectories to the directory pointed to by the $TEMPLATES$ variable, it will make it - the BAT file - about 8 lines longer.

     

    The PATHSPL command just splits the given pathname into device, path, full name, base name and extension.

     

    • Like 3

  15. This depends. It certainly saves you the manual access to that simple directory structure (changing the drive/dir in the SC panel, for example, just to copy one file from there, then change it back). If the file manager allows to create any file type without that, it can be more convenient, especially if there is a file association mechanism implemented in the shell (like RUNEXT in SDX). But in reality, the implementation may be more complex than it is worth, considering that we do not seem to have many complex data files which need to be specially structured before use. Maybe BAS, M65... music tracker modules... and ATR which can already be created in CLI using dedicated software.

    • Like 1

  16. I see, so nevermind. Anyway, the binary he posted is messed as it can be seen above, but the first problem is that it overwrites the very code that is loading the program (in DOS 2.0s and 2.5 - under any other DOS it overwrites God knows what) . And the OP seems fixated at the idea that what is there "shouldn't be needed by a cc65 program", and is unable to connect the fact that he is overwriting a part of the OS with the fact that his program crashes in the middle of loading. What a mess.

    • Haha 2
×
×
  • Create New...