Jump to content

drac030

Members
  • Content Count

    1,836
  • Joined

  • Last visited

  • Days Won

    1

drac030 last won the day on July 26 2016

drac030 had the most liked content!

Community Reputation

774 Excellent

1 Follower

About drac030

  • Rank
    Stargunner
  • Birthday 07/28/1970

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Warszawa, Poland

Recent Profile Visitors

17,482 profile views
  1. drac030

    drac030

  2. For that matter, DLT has no logo I know about
  3. Considering all these difficulties, "with almost no restrictions" in the topic seems to be a bit of overstatement. But the matter is interesting, any chance for a practical application (in a preview form at least) any time soon?
  4. HPU is a circuitry in Rapidus which allows to intercept direct reads or writes (or read/writes) to the hardware registers at $d000-$d7ff. When HPU is active and an access to that area is attempted, the CPU gets the abort interrupt.
  5. The exit through INTINV is supposed to occur only when the OS-es have not been swapped, i.e. the corresponding bit in the MCR did not change. By the way, that call does not really "reinitialize interrupt vectors", it just (re)enables the NMI. Technically it is correct, *if* you want hotswapping, you have to keep one ROM to be an exact copy of the other. Because of the way the board works, it would have to be an ordinary 6502 OS (but not XL OS, which is lacking the 65C816 interrupt services).. But as the FastROM is not really that fast (IIRC it does not run at 20 MHz, it is 10 or 6.66 MHz), this is not a very attractive approach. It is much better to have an 65C816 OS in the FastROM, and keep the XL OS as an alternative in the motherboard ROM. Besides, the "original specification" refers mostly to early prototypes. They were lacking the configuration menu, the board was entirely configured using POKEs at SDX CP prompt. One then could think OS hotswapping to be an attractive feature.
  6. I must say I do not quite get this comment. The config menu only changes the contents of the EEPROM. Later (in the PBI #0 module) the new settings are applied to the board's registers, and if the OS bit has changed, a cold boot should be forced. Everything that should happen with interrupts disabled, so switching OS-es should not cause any problems. And I have never noticed it did on the real hardware.
  7. Well, it may be difficult to implement in the emulator, but in real life it is a pretty cool extension board: no new motherboard needed, no chips reseated, it just goes into the CPU socket plus you have to add three wires, and that is all. Moreover, the CPU does not get interrupted by Antic, when executing code in FastRAM, so you can f.e. easily have both the display enabled and pretty much undisturbed sample replay, which is not the case on the default Altirra emulation (I mean the 65C816 turbo mode). But, having said that, I must also say that the exact emulation of the Rapidus board is IMHO not really needed unless someone wants to use its very specific features (such as the 16 MB banked SD-RAM). The generic Altirra emulation (65C816 + 21 MHz + 4 MB high RAM) seems in most cases good enough to test programs. Of course, I appreciate the now improved debugger support.
  8. The menu settings are controlled by the PBI #0 module (check PM), without it the configuration will not work. Also, the Rapidus does not really "stay" in the 6502 mode. When the "Classic" mode is selected and the machine is rebooted, the system starts in 65C816 mode first, then (again, by the PBI #0 code) the 65C816 is halted and the 6502 gets a reset signal and is started.
  9. For 130XE there is MAE http://atariki.krap.pl/index.php/MAE
  10. So your name is Jeff Williams. As far as I remember from the documentation, Alfasm supports the 65C816 high RAM, produces binaries with 24-bit addresses in headers ($FBFB is the signature) and uses the regular extended banked RAM to store symbols during assembling. I wonder why you rather would not develop that program further.
  11. It is only patched lightly so that when you type DIR in the BASIC XE direct mode, it will display the current disk directory rather than the directory of the D1: With BASIC XE there are some general problems. The CAR.SAV function does not save its entire memory in the EXTEND mode, for example. It would probably be best to develop a separate command (separate from CAR.COM, that is) which would be used to start BASIC XE and load/save its SAV files, than to embed all this in the CAR.COM command. Besides, please check PM.
  12. The file version of MAC/65 should work fine, it has always worked fine for me. Just remember to do assembling to disk rather than from disk
  13. SIDE2 build (which was used to program Bits-of-the-past Supercartridges) does not contain code which can correctly handle the pass-through cartridge port. This code was left out because SIDE2 does not contain a pass-through cart port. This means that it may accidentally work with some cartridges as long as you do not try to do file I/O while in the cartridge... and especially as long as it is not an OSS-supercart, which is banked, and therefore the system has not only to be able to switch it on and off, but also after switching it back on to be able to restore the correct configuration of the banks. When the code which does that is not there, you will run into mysterious trouble like OP did.
×
×
  • Create New...