Jump to content

drac030

Members
  • Content Count

    2,598
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by drac030


  1. On 2/24/2022 at 7:22 PM, Larry said:

    Would the Rev E issue as you explain it also apply when using with MyDos?

    Yes - but probably only when you go to the IDE+ configuration screen, then press RESET or power the computer down while there. So, nothing really related to MyDOS.


  2. 18 minutes ago, Larry said:

    For instance, on my Rev E, it would not keep settings unless powered separately after the Atari was shut down.

    This may be unrelated to the power supply. Rev. E has the old V3021 RTC, which will lose the settings, if the computer gets powered down (or reset) in the middle of reading the time by the system. And programs which are constantly reading the time from the RTC are: 1) TD Line (notoriously beloved by lots of people), and 2) Sparta Commander with CLOCK=ON in SC.INI.

     

    To avoid messing the settings, one should do TD OFF and/or exit Sparta Commander before powering the computer down or pressing RESET.

     

    It is rev. F which fixes this by using a completely different RTC, not sensitive to this issue. IDE+BIOS supports both RTCs transparently.

     

    On 2/23/2022 at 1:33 AM, Peter Rabitt said:

    FAT 16 formatted on my PC an I added files to it but went back to the IDE and the FAT16 drive has unknown file system??? Using sdx 4.49

    SDX does not support FAT16 natively, you have to load an external FAT16 driver (FATFS.SYS) to access a FAT16 partition.

     

    • Like 1

  3. 5 hours ago, cwilbar said:

    if a 40 and/or 44 pin header could be added as well to allow for spinning platter drives..... that would be nice

    This! Definitely! It is my main objection against rev. E/F: these are excellent stuff in themselves, but an upgrade from rev. D and spinning-platter HDD is not possible. Even worse if one wants to upgrade the interface but also wants to keep the spinning-platter media. Therefore adding a header for a 2.5-inch HDD would be a major improvement IMHO.

    • Like 1

  4. Rev. S (or D/S) is D with one-channel Covox. I think rev. E and F have the Covox by default.

     

    As for the licensing and stuff, I certainly have nothing against it. I would however prefer to retain the rights to the IDE+BIOS so that I could still modify the sources at will and release updated binary versions from time to time.

     

    To my understanding, the physical storage may be the problem. Up to (and including) rev. D the IDE+ interface was primarily designed for the spinning-platter IDE drives. These are becoming rare, especially 2.5-inch drives of reasonable capacity (like 2 GB rather than 200 GB). As of rev. E the hardware switched to CF cards, which unfortunately are becoming rare (and pricey) too.

     

    I personally have no problem with spinning-platter HDDs, when the one I use daily goes down, I still have two replacement drives in my drawer. But getting new ones on the market may be difficult.

    • Thanks 1

  5. It says:

     

    CPU TYPE: 65816

    OS TYPE : RAPIDUS OS

    HIGH RAM: PRESENT

     

    Just a remark: on Rapidus OS programs do not need to scan for the High RAM, because the OS provides this information: PEEK(590) returns the number of additional 64k segments past the first 64k (0 = no additional memory, $FF = 255 additional segments for the total of 16 MB). PEEK(589) returns the most significant byte of the lowest address of the first detected High RAM segment ($01 = $010000).

     

    Also, kmalloc($FFFF) will return the total amount of High RAM free, kmalloc($FFFE) - the size of the largest free block. Any other value passed to kmalloc() will attempt to allocate the requested amount of pages and return the address on success.

     

    Under SDX, when 65816.SYS is loaded, the MALLOC() call with requested memory index 3 will allocate the High RAM, or return errors if not present. The relocating loader will use that call to allocate the High RAM and load stuff into it.

     


  6. @kheller2 Thanks a lot. This mostly agrees with my guesswork I did years ago:

     

    http://atariki.krap.pl/index.php?title=Format_AtariDOS_3&redirect=no

     

    although I can see now that I got one or two things wrong then.

     

    8 hours ago, kheller2 said:

    Bytes 14 - 15 = Pointer to EOF within last block

    Well, indeed, but, since a block is 1024 bytes, one could expect this number to be in the range 0-1023. But in fact this is low 16 bits of the file's size in bytes.

     

    8 hours ago, kheller2 said:

    By Support for DD, I'm assuming you mean sectors greater than 128 bytes.  The 1050 and 1450XLD [1983 version] ARE double density drives with MFM encoding, Atari just squeezed more sectors into the track vs increasing sector size.  DD to some folks means 512bytes, btw, not 256.

    I mean our traditional terminology, where 810 is single density, 1050 is dual/enhanced/medium density, and "double" is MFM with 256 bytes per sector (or possibly more). Not the FDC vendor terminology, where FM = single and MFM = double density.

     

    One more bonus way to crash the DOS 3 DUP:

     

    1) boot with BASIC on

    2) when READY appears, do POKE 82,1

    3) type "DOS", press Return

    4) in the DOS menu, select "F"

     

    Also, it seems that "Init disk" (and perhaps some more functions as well) does not work, if you have not listed a directory at least once after a boot.

     

     


  7. 56 minutes ago, kheller2 said:

    Please continue to ask.

    1) What is the purpose of sectors 10-15 on a DOS 3 disk?

    2) What is the exact definition of the first directory entry?

    3) What is the meaning of the bits in the status byte of a regular directory entry?

    4) Is there any provision for double density disks?

    5) Any other special entries in FAT (sector 24) besides $FD, $FE and $FF?

     

    (EDIT) A bonus way to crash DOS 3 DUP:

     

    a) boot DOS 3 with BASIC on

    b) when READY appears, do POKE 82,0

    c) type "DOS", press Return.

     

    • Like 1

  8. The "v16" version (post #5) runs fine from SDX. The earlier one I did not try. In U1MB one probably has to select a 130XE-compatible RAM extension (Compy Shop 320k or 576k). The program runs fine on 65C816 and Rapidus OS, and even with acceleration. As of 7 MHz the FPS indicator seems to go nuts, though. :)

    • Like 2
    • Haha 1

  9. 1 hour ago, Stephen said:

    Well, releasing nothing but shit code that doesn't work is one sure fire way of getting it.

    Actually, it is. Doing something blatantly against the rules and reason is one sure fire way of getting attention on the internet and otherwise.

     

    This is why, for example, in the academic world any stupid publications are customarily ignored. Otherwise publishing (at own expense) a book containing nonsense would be the best way to get a lot of citations (thus improving its author's Hirsch index), because everyone else would rush to quote the nonsense in order to refute it.

     

    • Like 1
    • Haha 3

  10. Hehe, I just took a look:

     

    lib_cfg\atarixl_small.cfg:

     

    #Code used for loading MEM.SAV, shouldn't be needed by a cc65  program.
        MEMSAVM_:    file = "memx1.bin", define = yes, start = $15A4, size = $015C, optional = yes;
    
    

     

    @Harry Potter you do not really believe what you have been told (that $15A4 is the address of the binary loader in DOS 2.0), nor what you saw yourself with your own eyes (viz. that the program built with these settings, no matter how simple, does not work), right?

    • Like 3

  11. Altirra debugger in 65C816 mode, history window:

     

    obraz.thumb.png.0e5aa560616b672d46c2d95b7d6c1243.png

     

    It is "Timestamp format -> Show cycles". But the cycles it seems to show are slow bus cycles (aka 1.77 MHz cycles), even when the CPU is set to 20 MHz. Fixable?

     

    Also: could it remember the selection?


  12. 3 hours ago, Larry said:

    What do you have your Rapidus in?

    It is 65XE with ECI. Pictured:

     

    image.thumb.png.cad090abc71449875e9fbe22ac9f89e2.png

     

    3 hours ago, Larry said:

    How stable is it?

    Perfectly. I use it for programming, i.e. hours-long sessions of editing the source, saving to HDD, assembling, reloading the source code, editing again etc. I would not do that on unstable machine to avoid the risk of losing/screwing the sources.

     

    3 hours ago, Larry said:

    Didn't you have a very early 14 MHz version at one time?

    Even earlier I had a 10 MHz prototype. Later the 14 MHz one. Yet later (about 2014) a 16 MHz one. After that, the first 20 MHz prototype. The photo shows the second 20 MHz prototype. I also have a production board (partly visible on the right). I use the proto with an experimental 40 MHz core (unfortunately, not compatible with the production boards for a reason).

     

    EDIT: the computer works in turbo mode by default (like 99,99% of its time). But never had problems in Classic mode either.

    3 hours ago, Larry said:

    Hope things are well with you!

    Thanks, I surely hope so too! ;)

    • Like 1

  13. 1 hour ago, JGRAHAM2 said:

    Thanks, is there any other firmware I should update?

    The firmware in the sense of "ROM software": FLND6502 v.1.1, MROM v.1.2 (MODULE.ROM only), Rapidus OS 2.43, these are the latest revisions.

     

    The firmware in the sense of "FPGA core": the production core 6S9054E is still the latest one and there are hardly any chances for a newer revision, I am afraid.


  14. 10 hours ago, JGRAHAM2 said:

    Looks like Draco has a newer MODULE.ROM. I’m not sure how to check the PBI0 as he recommends. Is it likely this one is different? It originally had the Sept 2016 version of the firmware I believe. It is now Nov 2016

    PBI #0 is hardwired to Rapidus. This may only be a problem if you use any other PBI device (like IDE+ for example). In this case the external PBI device should get configured to release the PBI #0.

     

    The BIOS/menu: the earliest version I have here is dated 15 Nov. 2016. But indeed, the production Rapiduses were shipped with slightly earlier version, date 29 Sept. 2016. I have no idea, why. In any case, the differences between the 2016-revisions are probably minor - what they exactly are, I do not remember, it has been 6 years.


  15. 4 minutes ago, DjayBee said:

    You can find all PORTB settings for standard RAM extensions in phaeron's Altirra Hardware Reference Manual starting from page 32.

    There is an error there, though: the table on page 33 lists the 192k extension as RAMBO, without separate ANTIC access. Maybe such extensions exist too, but the whole point of using bit 6 in 192k for banking is to keep bit's 5 function of controlling separate ANTIC access. So it is not RAMBO-type.

    • Like 1

  16. The overlap is not a big problem, most RAM testing procedures are aware that some extensions have this "feature" (e.g. 256k already mentioned), for example:

     

    http://atariki.krap.pl/index.php/Obsługa_standardowego_rozszerzenia_pamięci_RAM

     

    The overlapping banks are skipped (so that a program trying to use the extended banks will not accidentally pull out the carpet from under its feet, so to speak). The procedure should still be put outside the area which can be possibly swapped out. In general, this is a nuisance rather than a useful feature IMHO.

     

    Also, using PORTB bit 0 to swap banks is certain to cause incompatibilities, because programs expect the ability to swap the OS ROM in/out regardless of the state of the remaining PORTB bits, and, conversely, that doing that does not switch the extension bank which has already possibly been selected and swapped in. That is why the extensions to 2 MB are not in use, although they were designed in the past.

     

     


  17. 8 minutes ago, DjayBee said:

    IMHO it's strange that SDX crashes if something modifies MEMLO.

    It does not crash. Nor "modifying" the MEMLO is the problem. SDX tries to prevent programs from overwriting the system (the "Cubbyhole optimization" fellowship & consortes). Everything between $0700 and MEMLO is considered the system, thus if a binary file tries to load a segment into that area, it gets shot down mid-loading with "179 Memory conflict" error and the system returns control to the shell.

     

    Here the MSBASIC sets MEMLO first to $6A00, then tries to load itself between $1E00 and that. Since the MEMLO points to $6A00, the loader thinks everything below are resident system components, and therefore does not allow loading.

    • Like 5
×
×
  • Create New...