Jump to content

drac030

Members
  • Posts

    2,770
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by drac030

  1. Do you know if this driver (ARCLOCK.SYS) work with a cartridge version of SpartaDOS X (ver. 4.21)?

     

    I see no objections, i.e. I think it should work without problems. Just get the current version, i.e. the one which can be found on the SpartaDOS X 4.41 cartridge, because any older one will most probably contain bugs that have been fixed before it got incorporated into new SDX.

  2. That tells you how to mod the original intSDX but doesn't tell you how to make the original intSDX.

    I think this is the page that I need to have in English http://hardware.atari8.info/sdx.php

     

    The page you need is translated there, in the first section named "I. Prerequisite: intSDX with the old SDX 4.22". It even says below that:

     

    "the following is just a short English summary of the information from the designer's (Pasiu) page"

     

    and the "designer's page" is this one: http://hardware.atari8.info/sdx.php

     

    The first section is the instruction how to build the 64k intSDX.

     

    Only the section two contains the instructions how to mod the 64k intSDX to make it a 128k intSDX.

  3. I think the later versions 3 & X had a Menu.Com program which could be used with them if you had to have a menu, but I never had any use for it.

     

    SpartaDOS' MENU.COM is nothing like the DOS 2.5 menu, it is rather a copying tool. In X it allows to copy files over from one floppy to another using only one disk drive (the ordinary COPY command does not allow swapping floppies).

     

    there is no version 6 of SpartaDOS

     

    ... yet :)

  4. Would the fact that MyIDE does not have Percom support stop it from working with parta?

     

    I currently have no idea. Must look up the sources. Certainly, SpartaDOS establishes the density now according to the PERCOM information returned. If none is returned, Atari 810 SD or Atari 1050 ED density is assumed.

     

    Is is so much trouble for MyIDE author to release an upgrade with READ PERCOM support? This command is de facto standard.

  5. There was an effort to make Sparta Dox X 4.39 into a MyIDE cart. It did quite well also for both internal and external.

     

    Provided that there are active SpartaDOS X developers who actually have the source code and can compile it directly into a ROM image, these "efforts" you mention to binary-patch a release version in a hope that it would somehow work, and the patcher did not omit any register reference or did not overwrite anything important, are rather funny form of aberration IMHO.

     

    The correct procedure to have a type of cartridge supported by SpartaDOS is actually to sponsor one device to the project maintainer. ABBUC did so with Turbo Freezer 2005, so their Turbo Freezer is supported.

  6. Thanks. Is there a specific reason? I thought that the "flash-part" of those cartridges are compatible with each-other.

     

    The reason is that noone has MyIDE+flashcart, so there is no way to test the images. The same applies to the MyIDE driver someone wrote. It can't be included in the cart release, because there is no way to test, if it works correctly.

  7. Rybags was suggesting a cartridge based auxillary processor that would take over some of the Atari's workload. Such a device would run at a much higher clock speed than the original system, perhaps 8 times faster. With no interrupts or refresh or HALTs from ANTIC, the throughput would approach 12 times the Atari in GR.0. The advantage to using a 65816 is that code running in the Atari could be exported to the cartridge with few or no changes required. The FP calculations, for example. If you were running a word processor, the pages could be kept in cartridge memory and manipulated by the aux processor, based on commands from the main program running in the Atari.

     

    Ok, I understand now what are you referring to. Surely, it would speedup FP calculations and such, but in fact FP calculations are rarely used. I guess that all the gain would be wasted on communications with the cartridge and its coprocessor. You know, the calculations even the BASIC interpreter does are mostly ordinary integer stuff, most of the speed gain you can do with an accelerator comes from the fact that every CPU instruction is executed faster - not from the fact that just FP calculations are faster.

     

    The nice thing about the cartridge is that it can take over the OS very early in the boot. It can then configure the system as it wishes.

     

    I can't imagine how it could configure the system f.e. to use the native mode interrupts, in the other way than replacing the XL OS with something loaded into the RAM below the OS. This is "replacing the OS" I mentioned above and it is way better done by replacing the ROM. There are already some 32-in-one OS-es, so what is the problem with adding one more, this time really necessary?

     

    Does the Warp 4 run at higher clock speeds?

     

    Yes. The high RAM (past the $FFFF) is clocked at 7 MHz currently, maybe 14 MHz in the near future.

  8. This type of upgrade would run code in a 64K block of its own memory, although you could run it in 16-bit mode if you wanted - it would just be difficult to develop the routines without a system platform that ran 16-bit code. (maybe an Apple IIGS?). There are no interrupts to deal with, no HALTs, no REF. Everything would run at high speed, but, in 8-bit mode, the only use for the extra memeory is data storage.

     

    I don't understand what you are talking about. 65C816 by itself is not faster than 6502. It only can run at higher clock speed, and can do 16-bit calculations and moves with single instructions. To use the 16-bit instructions normally (with interrupts enabled) you have to replace the OS.

     

    What does the Warp 4 configuration look like?

     

    It is an ordinary Atari with the CPU replaced and some (1 MB for example) of additional, directly addressable fast RAM located past the first 64k.

  9. I'm not aware of any special requirement for accessing data in the extended blocks.

     

    I am not speaking about accessing data. I am speaking of running code.

     

    Regardless, this is a speed upgrade, not necessarily a memory extension.

     

    The only speedup you gain in Warp 4 comes from running code in the high memory.

  10. On cart it would not work, I guess. The entire goal is to have the new and the old memory directly adressable for programs, and this means that the CPU has to be replaced.

     

    The OS has to be replaced too, the old XL OS does not allow to switch the CPU to the mode in which it is able to run code in the extended memory (past the first 64k).

  11. Right, it was called "Laser Demo", not "Lasermania Demo". I remembered that scroll, because, after I saw it, I was able to reproduce the effect using just the same method Rybaqs mentioned, i.e. with two fonts shifted one bit off one to another.

  12. I was thinking along the lines of Sparta dos 2.3, but Sparta dosX would be very low as well

    At least SpartadosX will work on an 800, even better if the 800 has an axlon compatiable ramdisk :)

     

    But on a 48k 800 it won't be low on MEMLO, rather contrary. :) With Axlon, though, it should be as low as on an expanded 130XE, yes.

     

    Other DOS-es load either to main memory or to the RAM under the OS, like DOS XE or SpartaDOS or whatever. The superiority of the SpartaDOS X is that it can occupy whatever memory you want: the main one, or the one under the OS, or the 130XE/Axlon banks.

×
×
  • Create New...