Jump to content

drac030

Members
  • Posts

    2,768
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by drac030

  1. I doubt. I've got an impression, that fitting MARIA into XL/XE is rather hard, because the chip keeps its registers on the zero page, conflicting with the CIO, and also on the 6502 stack area limiting its size.
  2. http://drac030.krap.pl/si211.arc ?
  3. http://atariki.krap.pl/index.php/XF521 Better photo appreciated.
  4. Tezz: the software is being written and as it is done, the board is being debugged. It for example turned over, that the on-board RTC is inaccessible. The author is fixing such minor flaws now, apart of it the unit I have works very good. I have no idea, when it will be available to get, at what price etc. - these are things the author should be asked about. Gunstar: the turbo board is an external device, it only plugs into the Atari expansion port and into the motherboard as said above. There is no reason why it should not be compatible with existing RAM upgrades. Basically, as you said, the turbo board has its own memory, and Atari has its own memory (possibly expanded the standard way). These areas remain separate. There is an operating mode of the board, that sort-of replaces the 64k of Atari memory with the board's memory. This works so that a part of the turbo board memory effectively works as a write-through cache for the first 64k of Atari address space. But, this applies only to *main* 64k of Atari memory. Any expansions (like additional 64k in 130XE banks) won't be cached, so accesses will be slow (still averagely 20% faster than without the board, it has to be said). ROM upgrades are not a problem either, the boards has its own separate ROM, but normally it boots off the Atari ROM, whatever is in the computer. There are three modes, you can select with a switch in which mode the board should "wake up" when powered up: "Normal" - this is like the Warp4 board, the memory that resides in the first 64k ("old", i.e. Atari memory, main RAM, ROM, BASIC, RAM banks etc.) is slow (1,77/1,79 MHz), everything else operates at full speed. In this mode the board boots off the Atari ROM. "Fast" - similarly, the board boots the Atari ROM, but the first 64k memory is cached. This needs special OS (like mine) to operate best, as the OS has to configure the onboard MMU at startup. "Software" - this is identical to the "Fast" mode, except that the board's internal ROM is booted. A very nice and powerful device, generally.
  5. Not yet. The version with fixes is 4.40, which is to be released really soon, but not today
  6. Not directly. The original 4.20/4.22 cartridge is 64k, 4.39 is twice as big (128k). So some modifications have to be done, I am not even sure, if the original cartridge can be easily modified for that. Try asking via private mail the SDX Upgrade page maintainer ( http://trub.atari8.info/index.php3?strona=...upgrade_en.html ), he should know more about hardware issues.
  7. Out of these listed in your sig? Sure. As for Atari XL and XE computers, I think most of them (all?) have Atari logo and serial number on the underside label.
  8. There is an issue: the default CONFIG.SYS loads the R-Time 8 driver (CLOCK.SYS), and this searching for the RTC causes the Maxflash to switch its banks unexpectedly (for the DOS). It somehow works with Maxflash 1 Mb, but never with the 8 Mb version, AFAIK. To work this around, make own CONFIG.SYS file, as such: USE BANKED DEVICE SPARTA DEVICE SIO Save it to the main directory of your boot disk (must be SpartaDOS formatted), and reboot. The DOS should now load your CONFIG.SYS instead of the default CAR:CONFIG.SYS, and so the problem with the R-Time driver should be avoided.
  9. So, if it goes directly to the memory test, this means that the ROM fails the checksum. 800 OS "works fine", because AFAIK it does not calculate checksums I thought that perhaps the FP ROM got permanently disabled (this is where the PBI goes into), but BASIC wouldn't work then. It may be, that the damage appears in one of the places the 800 OS really doesn't use, i.e. $C000-$CFFF and SelfTest itself. If so, the left bar out of the two for the ROM in memory test should get red (or something).
  10. Where? http://atariki.krap.pl/index.php/DOS_4.0 http://drac030.krap.pl/DOS40_Atari.rar
  11. Can you check, when you boot it with the 800 OS, if the Atari BASIC works?
  12. I don't have XEP80 myself, but AFAIK, the XEP80.SYS driver included with the SpartaDOS X doesn't disable Antic.
  13. I have no idea. The most difficult thing to emulate is custom chips, not the CPU anyways.
  14. This shows nothing, because PBI devices are not handled directly by the OS-ROM (it only enables the PBI ROM and hands over the control to it). As it was already pointed out twice (or more?) in posts above, the PBI devices thus can have up to 256 units ("partitions"), and - separately - SIO limits were discussed, which don't apply to PBI, and vice versa. So, if someone comes, cites the post where it is said that SIO is limited to 16 drives, and puts an example of the BB allowing 26 drives as a counterargument, I can only assume, that he does not follow the argumentation accurately enough. As for SIO - _serial_ drives - the OS ROM is obviously limited to 16 units per device, because the SIO protocol is defined so by its designers: in a command only 4 bits carry information about the unit number.
  15. Nope, I have European 65XE and the GTIA it has is good.
  16. Since when the BlackBox is a serial device and so SIO limits apply? See post #10.
  17. Some can. Or, perhaps, even all can be fixed, but not everything is worth the necessary effort.
  18. Few can be of some use, yes. But it is not deadly advantageous, as you can see from the percentage of programs actually using them. Moreover, a part is used apparently not to make code faster or shorter, but to make disassembly more difficult.
  19. Depends, what do you mean for "full 6502 instruction set". The 65C816 certainly has all official 6502 instructions. The only problem may be, if a program uses illegal 6502 instructions - it won't work on 65C816 machine then, because opcodes illegal in stock 6502 are assigned to new instructions in 65C816. From experience, I can say that very few programs actually use illegal 6502 instructions and thus refuse to run on the new processor. This is like 10 games out of 130 I tested, maybe 2 (rather old) demos out of 40 I tested, I don't recall any utility program which would have problems, but I think one or two can be found, probably.
  20. I overlooked that question. Well, it is difficult to say. On standard Atari, the 48k Spectrum emulation certainly is not a speed daemon. I expect however, that a version written specially for the 65C816 accelerator may be actually usable as a true emulator. This would obviously depend on the accelerator clock speed, and again, it is rather difficult to estimate the final result, but from the experience I got writing the 6502 version of the emulator, and from some draft 65C816 code I did, I now tend to think that at 14 MHz the emulator may be nearly as fast as the ZX Spectrum itself.
  21. Really? Why? Coz in ZX-81 the Z80 creates the display. Well... go ahead.
  22. I think it would... if the entire emulator code fits in about 22-25k, it is possible. I may be wrong, but I think that ZX-81 is more difficult to emulate on Atari, than the ZX Spectrum
×
×
  • Create New...