reifsnyderb

Altirra comes with it's own compatible ROM. If you want to download Atari ROMs, a quick google search will fine them. Also, Atari ROM source code is on this site and I've confirmed it compiles.

This is sort of what I am doing. But the firmware will be driving the I/O through the OS as PBI low-level I/O. Once the card is enabled, it reads the DCB and acts if the DCB has the disk drive device called. When the card is enabled, by the OS, $4000-$7FFF will be a 16k bank to the 4MB on the card. Then, it handles the function by using the DCB buffer and the RAM bank. Once done, the OS will disable the card....which will restore the memory. Each I/O will result in the extended memory window being toggled. The card will also be able to re-map drives. i.e. D1: will be a RAM Disk, Physical D1: will be D2: For configuring the system, the $4000-$7FFF bank will contain the system configuration firmware, if selected during boot-up.

Ok, as promised, here is the source that could be patched into the OS. To patch it into the OS, the top init section needs to go someplace like after the memory is cleared on boot-up. The main section needs to be JSR'd to from the PIO and space needs to be made in the OS. (I dumped the international character set on OS 6.1.) ramdisk_portb_os_patch.zip Right now, this can be used to add a built-in RAM Disk or RAM Disks using PORTB banking. (The extended memory can be partitioned into up to 4 RAM Disks.) This code will be used as the base for the RAM Disk card. Instead of PORTB banking, banking will be ported to a register like $D100....which will only be available when the card is active anyhow. The only issue I can see is that if you were to try to use something that uses a huge disk buffer, like a sector copier, and access one of the configured RAM Disks it will fail. I put a subroutine in place to ensure that a DCB buffer won't try to use a buffer in the banked range. Also, attempting to write to a RAM Disk outside of it's boundaries will result in an error 144. Also included is a section to re-map disk drives.

I'd have to update the board to use CPLD's in order to add all of the registers required without using a humongous board. The existing board was designed with glue logic and a couple of PLC's due to the chip shortage. While they have been hard to come by, I just saw Mouser now has over 7,000 of the ATF1504's in stock. My preference is keep all the logic 5VDC so as to avoid level shifting as much as possible. It may be more feasible now once again. I was thinking some more about this and, at least for the short term, I'll stick with the current design and see if I can get it working. If I have to re-design the board, I'll put the ATF1504's on it and bank the ROM and RAM through a window in the $D800-$DFFF range. I put all of the code to calculate the bank/sector offset in a single sub-routine so adapting the code should be an easy swap. For the short term, I'll put in some code to check the buffer location and fail on a read/write to a buffer in the $4000-$7FFF range. If there are too many failures, I'll know this isn't going to work. I just learned I have to keep something else in mind during testing: I was using DOS 2.5's setup program as a test to copy to and load it from the RAM Disk. After a few cycles of copying and loading the system locked up. That sent me on a path trying to find out what was happening with the RAM Disk. So, I tried some of my earlier RAM Disk code, that was still keeping configuration variables in page 6, and had the same failure. So, I loaded an unmodified OS R2 and executed the program multiple times. The result was the same. I guess the moral of the story is to keep in mind that even the old software has some strange bugs in it.

It doesn't sound like there are really any great options for banking. The $D800-$DFFF region also is used for the PBI ROM. It would be possible to bank that region as long as the ROM is banked as well. This would most likely result in stuffing 4MB through a 1k window and require a more complicated card with more registers. Using $D600-$D7FF would conflict with VBXE thereby necessitating only using 1/2 of that windows and having a configuration. So, that would result in stuffing 4MB through a 256 byte windows and having a more complicated card with more registers. <sigh> The other option is to keep it as I have it now and use the big 16k window. I don't suppose it would be possible for U1MB to have a future update whereby the PBI /EXTSEL signal would turn off all of it's supplied memory? Otherwise, I guess if somebody were to have a U1MB, to use this RAM Disk card with a 1090XL (or 1091XL) board would require the 1090XL supply the RAM as well. So it would be a redundant extra expense. I've got the card made and sitting nearby right now. I'll get it working first and go from there. Worst case, I'll be able to turn on my Atari and have a 4MB RAM Disk, printer spooler, re-mapped drives, and some other options. So, I should be able to have MULE load almost instantly.

So, U1MB will keep the PBI EXTENB signal low when it enables it's extended memory? Does U1MB have a setting to omit it's extended memory in favor of normal operation?

Do you see any issues with the banking window being at $4000-$7FFF? I didn't consider the buffer also being in that location.

It is a new hardware design.... The banking window is at $4000-$7FFF. I figured that since Axlon and PORTB banking use that window it should work fine. It seems to work with DOS 2.5 and SDX. I haven't tested with others. Banking 4MB through a 512 byte window at $D600-$D7FF would require at least two registers. PORTB is being used only for development and testing. The bank will be on when the parallel device is set active via $D1FF.

The 800XL was very good and my first computer. It's not quite as easy to upgrade as the 800. However, had Atari released the 1090XL the 600XL and 800XL would have had the potential to be more a much more powerful machines.

I wonder how this will affect developers of retro hardware....

I completely agree! In many respects, the 800 was the most powerful of all of the Atari computers.

On that note, new 800XL system boards are also available. Including the one I made, there are two possible system boards.

I think @Ray Gillman is talking about using a clone of the original system board with clones of the LSI chips.

Are you just summing up the 128 bytes of each sector and dropping the carry? The $800 sectors are only available with the right OS. With Atari's DOS 2.5 there is extra space, of course. I too am wondering about how much the checksums slow down the operations. I've added the capability of partitioning the memory into multiple RAM Disks. So, there is some waste. I am still pondering how to add checksum information.

I just realized that by changing the DUNIT value, in the stack, might break the "illusion" of re-mapping the drives by providing the real drive to any software that checks the DUNIT value after the SIO request is made. So, I now think the stack should be left alone and just DUNIT changed. For example: RDRMP2 INY ; Y is the new DUNIT STY DUNIT ; Overwrite DUNIT with new DUNIT value. JMP RDRMP4