AGiambra

Hi. Magic Spell is one of my creations. It was published in the September 1986 issue of Analog magazine. I've attached an ATR with Magic Spell on it. I also included Fastload which allows you to build up a personal dictionary faster. When you run Fastload, you point it to a document which already has correctly spelled words in it. It will load all the words in the document to the dictionary without any prompts to the user. Make sure you only feed it documents containing correctly spelled words. Have fun! Angelo Magic Spell.atr analog_no_46.pdf

When the Ultimate 1MB Upgrade is present SECTCOPY.COM will switch itself into bankswitching mode. If you use the SWAP option and then copy a disk, the target disk will have errors. This has been corrected on the attached disk. I also updated the first post in this thread with the correct versions. Unfortunately, I cannot edit the post that begins "More Improvements" so do not download from there. Use the disk here or on the first post. Thanks. Sectcopy.atr

As I mentioned earlier, the SECTCOPY and SECTVTOC programs were written for the Ultimate 1MB Upgrade and will not work on Atari 130XE machines. Attached are copies that will run on the 130XE machines. They will automatically detect and copy single density and double density disks. They will also automatically detect and copy Atari DOS 2.5 disks. Enjoy. SC130XE.atr

Good question. No, MAGICLON does not turn off BASIC. Here is the correct procedure: Insert the disk with MAGICLON. Press OPTION and boot your system. If you do not press OPTION, when you run MAGICLON a warning message will appear: "REMOVE CARTRIDGE" and it will not proceed. Since you have pressed OPTION when booting, MAGICLON will reboot the system with BASIC disabled. It works the same as the TRANSLATOR disk. MAGICLON does not intercept the START key until after SELECT is pressed and it loads itself into memory. Also, when I intercept the START key, my program only checks if START, OPTION and SELECT are pressed. All other combinations are treated normally. I have modified MAGICLON so that you can load cassette files as well. Simply press START and then press SELECT. The system will beep waiting for the cassette. At this point load your cassette in the normal manner. Finally, I've made improvements to MAGICLON and have attached a new ATR. The name MAGIBRK has been changed to MAGILET. When you use MAGILET, pressing any key on the keyboard dumps the running game/program to disk. Hope this helps. MAGICLON.atr

More improvements Sectcopy.atr

Larry, Without getting into too much detail, the 130XE has an extra 64M of memory. It is accessed by tweaking bits 2 and 3 of PORTB ($D301). The extended memory is accessed 16K at a time depending on which bits are on or off. The extended memory is accessed via a "window" at $4000 through $7FFF. The Ultimate 1MB Upgrade uses bits 1,2,3,5,6 and 7 to control access to the extended memory. Like the 130XE, all extended memory is accessed via $4000 through $7FFF, 16M at a time. but there are many more banks available. The sector copy programs I wrote are tweaking all six of the aforementioned bits in PORTB. Obviously, if you run it on a 130XE, the 130XE will not understand the various configurations and you'll end up with garbage on your destination disk (or the program will crash - I have not actually tried this to see what happens). I actually wrote versions of my SECTCOPY programs for the 130XE. However, all the later enhancements which allow it to detect Dual Density disks or to copy Atari DOS 2.5 are not in these versions since I wrote them some time ago. If it can be of use to some of you out there, I can return to the 130XE versions of my program and add all the later enhancements. Hope this helps. PS I just tested the SECTCOPY programs on a 130XE. Sure enough, the program locks up when I try to run it. Because it is referencing memory configurations that do not exist and the program doesn't know what to do.

I've made improvements to two of the Sector Copy programs. Features of the two programs are: Both programs will automatically detect the density of the drives. Both programs will now also automatically detect and copy an Atari 2.5 disk. SECTCOPY will copy all 1040 sectors. SECTVTOC will copy only used sectors. It is no longer necessary to insert a double density drive in drive 1 before you load the sector copy programs. You can now boot from a single density drive with Sector Copy on it and run it. Then insert a double density source drive and press START. The program will detect the density of the source disk and copy it correctly. Both programs will also automatically detect how much memory you have in your Atari. If you 320 Rambo, 576 CompyShop or a full 1 MB of RAM, the programs will detect and use it. If you have STOCK memory installed, it will also be detected. IMPORTANT: These programs were written for the Ultimate 1 MB upgrade. Atari 130XE machines also have extended memory but these programs should not be used on an Atari 130XE. The memory on these machines is handled differently. Have fun! Sectcopy.atr

Thanks IVOP. I did contact Albert and I have successfully edited all the attachments on this post with the latest versions. Good advice! I wanted also to point out the correct way to use the sector copier when copying double density disks. The proper procedure is to boot your Atari from the double density disk you wish to copy (or from any double density disk). Insert the Sector copier disk is Drive 2. Execute the program using D2:COPY NAME where copy name is SECTVTOC or SECTCPY3 or any of the copier programs. Now insert the double density disk in drive 1 and a blank formatted double density disk in Drive 2 and press START. The reason you must do it this way is because when you start the sector copy program the first thing it does is check Drive 1 to discover the density of the disk there. So a double density disk must be in Drive 1 so that the program knows that this is a DD copy.

I discovered some bugs in my Sector Copy programs when it comes to copying double density disks. I am sorry that I did not test these thoroughly enough. I have fixed the bugs and thoroughly tested each one of the programs. They are now working correctly. Attached is a new copy. Throw away your earlier ones and replace them with these. Thanks for your patience with me. Hah!

Well, as usual I got a little ahead of myself. I noticed that when the program is run it displays SECTOR COPY DD indicating that this is a double density operation. It displays this even though a single density disk is inserted. My apologies. Attached is a new ATR with corrected copies.

I've come back to this project to improve these programs. I rewrote all of them so that the programs will automatically sense whether the drives are single or double density. In addition, all of the programs will automatically sense whether the Ultimate 1MB is installed and extra memory is available. If so, the programs will use it. The only requirement is that the source and destination drives must be the same density. The new versions of the programs are: SECTCOPY - The program will copy all sectors from the source drive to the destination. SECTVTOC - This program will copy only used sectors from the source to the destination.

I am always up to a good challenge. When CharlieChaplin said that the Freezer creates a self-booting disk that does not require a special loading program, I thought, "I can do that!"' Attached is a new version of MAGICLON that no longer requires MAGIREAD. Like the Freezer, it will create a self-booting disk that loads directly into the copied software. But unlike the Freezer, it will restore the GTIA and ANTIC registers so that the copied software will run correctly. Have fun! PS I removed earlier versions of the ATR just to avoid confusion. MAGICLON.atr

I downloaded your copy of the Freezer and used it to copy Way Out. When it reloaded, the same garbage appeared on the screen that my program initially had. Apparently the Freezer does not copy the registers of the ANTIC and GTIC chip. MAGICLON does and when reloaded, no garbage appears on the screen. Makes me feel good that MAGICLON is better than the Freezer. Hah.

I heard about the Freezer but never knew much about it so I appreciate your post. I was so excited to get MAGICLON working that I just wanted to tell someone about it. I didn't think anyone would want it though. But since you asked, I am attaching it to this post. A caveat: It does not work on all programs. If the game turns off interrupts, then when you press SELECT, START and OPTION together, nothing happens. Having said that, here is how to use it: Run MAGICLON. It will display a screen that says PRESS SELECT. Insert the disk you want to copy and press SELECT. The game will load. Once the software is running, remove the original disk (IMPORTANT). Insert a formatted disk and press START, SELECT and OPTION at the same time. The system will write to the disk. Be patient; it has to copy a lot of data. To run the copied program, run MAGIREAD. At the SELECT screen, insert the disk that was crated and press SELECT. The software will load and run. IF START, SELECT AND OPTION do not work, try running MAGIBRK. This version will write out the data disk when the break key it pressed. Sometimes if one way does not work, the other does. If neither work, well, you just cannot copy that software.

As I said in my first post, I began working on MAGICLON in the early 80s. There were a lot of things I did not quite understand about interrupt processing and so MAGICLON always "kind of" worked. Being an ultimate perfectionist, it bugged the crap out of me that it didn't work perfectly. In the 80s I finally put it away, but every so often (at 5 or 10 year intervals) I would return to the project for another attempt. In a nutshell, it works like this: The first thing that happens is a copy of the 800 OS is loaded into memory. Since it only occupies 10K, it frees up memory from C000 to CFFF. This is where my code resides. I intercept the interrupt that checks if the START key was pressed and point it to my code. When the user presses START, OPTION and SELECT together, it causes an interrupt which jumps to my code. I write all the contents of memory from $0000 to $BFFF to the disk. The biggest problem I had was getting the copied software to run after it was reloaded into memory. Remember, I captured all the data and wrote it to disk during an interrupt. So after all the data is reloaded into memory, I should have been able to execute an RTI instruction (return from interrupt) and the Atari should have picked up exactly where it left off when the data was captured. This was the thing that I could not get to work from the 80s all the way up to last year. That's when I pored through all the documentation I could find and finally learned that the one piece of information I should have captured and saved on the disk was the stack pointer. If the stack pointer is not set properly, when you issue an RTI instruction the Atari will not access the stack at the correct location. Once I learned this, I saved the stack pointer on the disk and voila, the next time I ran the program, the copied software started right up at the exact spot where it had been interrupted. This should have been the end of the story but when testing a game called Way Out, the screen had garbage on it after it was reloaded. The program worked okay, but there was junk on the screen. Why? Well, it turns out that saving everything in memory is not quite enough. There are two special chips in the Atari besides the processor called GTIA and ANTIC. They are responsible for what goes on the TV screen. And here I faced the biggest challenge. I also needed to save the contents of certain memory locations within these chips. But guess what? You can write to the registers in these chips, but you cannot read back what you just wrote. So if a game stored a value, 12 say, in $D009, my software had no way of reading that value from the chip. This kept the program from being perfect until I had my final brainstorm. Why not scan all the code that is loaded into memory looking for instructions that write to either the GTIA or and ANTIC chip. Typically the code would look like this: LDA #$12 STA $D009 Once I found the store instruction, I could simply back up and capture the value that was to be stored. One final problem existed. Often, you'd find code like this: LDA #$12 STA $D006 STA $D008 STA $D009 If I wanted to find out what was stored in $D009, I couldn't just back up to the prior instruction. I needed to make sure the previous instruction was also not a STORE command. If it was, I needed to keep backing up until I found the LOAD instruction. As I processed each STORE command, I built a table of each location that had been accessed and what value was in it. Now with the table stored on disk, when the disk was reloaded, the final thing that happens is I access the table and write all the proper values back into the GTIA and ANTIC registers. To my ultimate delight, when I reloaded the Way Out game and it restarted, the screen was clear of garbage. It looked exactly the way it looked when the program was initially dumped. Only 40 plus years to get the program running perfectly. That's not too bad....I guess. Hah hah.