rcgldr

Looks like I can use the PC Mirror feature. I would create a directory on the PC for the files I want to transfer to/from the Atari, and then use APE to emulate an Atari DOS 2.0 floppy using the PC directory. For CP/M, I can use the ICDS program to transfer between CP/M and Atari DOS 2.0 (or PC using the PC Mirror feature).

That's what I was thinking when I played it, but the youtube videos show the players getting through the black levels by memorizing where the gaps and ladders are.

I'm not sure what the issue is. Those are the calculated bit rates assuming Pokey divisor of 6 on the Atari side, and 58 cycles or 14.5 us per bit on the Indus side. What I'm wondering about is if the sector image is being moved in memory on the Atari and/or Z80 side. The Z80 side internal memory transfer would take about 1.3 ms, the Atari side about 1.7 ms, which wouldn't add much to the transfer time of 37.12 ms per sector at 68.8 kbps. So even if both sides move memory, that's 40 ms per sector, or about 64 kbps.

I recall fixing that (there should be INC DE and INC HL before the DJNZ instruction). I still can't find the 5.25 inch floppy drives I used for the ATR8000, or the set of "master" 5.25 inch floppy disks I had at the time. What I did find were older copies of this stuff scattered about in storage bins (totes). I'm missing a tote. I'm pretty sure that the retailer that included a free copy of the Indus doubler to customers that bought the Indus GT had the fixed version. I'm wondering if Indus ever released their version of the doubler, since I haven't found anyone else that reported getting a copy of it from Indus. I can easily fix the source again, but I need to wait for an SIO2PC that I ordered to arrive, so that I can get the source code and Z80 assembler onto an Indus CP/M disk (or virtual disk) in order to get a fixed copy of the bootable doubler. The ATR8000 is no longer an option since I'm missing a storage bin.

I have a version of Pitfall with a no damage hack. It's not a good hack, as touching objects will cause duplicates to appear, but there's no harm done to the player's character, making it easy to complete the game. I've got an SIO2PC on order, and when I get it, I'll make an image backup of it.

Since I've seen a few youtube videos of this. Some of the level screens are completely black, and it's not until you get a game over that you see a partially lit map of that level. Is there a hacked version of Montezuma's Revenge where the levels with black screens have been patched to show these black levels like normal levels?

I'm assuming I'll be able to move files between a PC and the PC based floppy images on a PC using the APE program (no Atari computer involved for PC only transfers between PC files and virtual floppy images)? The point of this for me was some way to transfer files from a PC to an Atari 8 bit computer. Once it's on an Atari DOS image, I have ICDS CP/M program that can transfer files from an Atari DOS floppy (or the SIO2PC emulated floppy) to the Indus CP/M floppy. There is also an IBTW CP/M utility that will read a file and write the Indus 256 byte sectors starting at sector 1 needed for Indus boot, but I don't have that on an Indus CP/M floppy (yet), or the file (such as the doubler), but currently as long as I have one good copy of the Indus double floppy, I can use the Zsid debugger and Init to make copies of the Indus doubler floppy. Eventually, if it's wanted, I'll make a utility to create an Indus doubler floppy that can run on a standard (no ramcharger needed) Indus GT drive.

Sometime during the 1980's, the price of an Atari 400 dropped to $70, and Fedco (a local chain in California) was selling them with $50 rebates, so the price was $20. During the late 1970's and early 1980's, CP/M systems were popular, mostly for WordStar, the first cheap WYSIWYG and interactive text editor, which was ported to early PCs. I recall my kids using WordStar for homework. There were also database and spreadsheet programs, but these were mostly used in business environments. On a side note, I saw an interactive editor demonstrated back in 1973 on an HP 2100 with a CRT monitor where I worked. It worked well, but tied up what was a fairly expensive mini-computer system, and at that site, we used teletypes for batch entry or batch editing commands, lugging around 14 inch single platter removable disk packs that held the source files. The source files were periodically backed up using mylar punched tape, as the life span of magnetic media wasn't well known back then.

If the drives used a UART instead of bit banging, then host communication could occur in parallel with disk I/O operations, doubling the speed, but then there may be a limit on the baud rate versus the specified length of the SIO cables. On a side note, I thought a had a formula that worked for most of the speeds, but not for a divisor value of 8. What I suspect is the count down timer cycles during a transition from 0 to -1 as opposed to from 1 to 0, using the "borrow" bit as the cycle trigger. Then the 6 cycle delay noted in the spec should mean that the bit rate = (1790000 / (divisor+7))/2 or 895000 / (divisor+7). Using some examples, hex 5cc = 1484: 895000/(1484+7) = 600.3 bps. 895000/(40+7) = 19042.55 bps, close to the spec rate of 19040 bps. 895000/(10+7) = 52647 bps, close to the drives doubler speed of 52631 bps (19 us per bit). However, 895000/(8+7) = 59667 bps, not 57600 bps. While 89500(6+7) = 68846 bps, close to the 68695.5 bps stated for super syncromesh rate (58 cycles = 14.5 us per bit, with 4mhz Z80, this is not possible with 1mhz 6502).

I already ordered the atarimax and APE. Overall the FTDI would have been cheaper since the driver is included.

I've since confirmed that USDoubler also runs at exactly 19 microseconds per bit, ~ 52.631 k baud I don' t know why the articles about ultraspeed mention 3x = 57.6 k baud.

I plan to buy the USB version of the SIO2PC interface. I assume I need the APE for Windows software as well. I downloaded a Z80 assembler tool set that should be the same as the one I used before on my ATR8000, which may not even run anymore and I can only find the 8 inch floppy drives that i used with the ATR8000. Fortunately, I already have ICDS on an Indus CP/M floppy, which can transfer files between CP/M and Atari floppies, and I also have the 6502 assembler on an Atari DOS floppy. So the only tool missing was the Z80 assembler stuff.

Link to source file. Upon entry, the Indus reads and loads sector 1 into 7F00H, and passes the address of the Indus sector buffer in HL. That sector in turn reads sectors 2 through 5 starting at 7C00H, except it branches to 7C00H before transferring sector 5 to 7F00H (to avoid overwrting the first sector code). The code at 7C00H moves sector 5 image to 7F00H, then sets the command interrupt vector to point to the emulator code, and returns. The drive's host interface is handled manually 1 bit at a time using timing loops. Standard rate transfers use the Indus ROM transfer functions. Fast data rate transfers are handled in the emulator code, 76 cycles or 19 microseconds per bit, about 52.6 K baud. It's my understanding that the 1050 doubler is also 19 microseconds per bit. Articles mentions that the speed is 3x from 19.2 K baud to 57.6 K baud or 17.4 microseconds per bit, which it could be on the Atari computer side, but there's enough margin that the bit sampling of the start bit, 8 data bits and stop bit will not cross a data bit boundary since the data bits are sampled at about 1.5 bit times after the start bit to end up near the middle of data bit periods. If data is from Atari to drive, then the stop bit to start bit transition takes a bit less time from the drive's perspective, and if the data is from drive to Atari, the stop bit to start bit transition takes a bit longer from the Atari's perspective. http://rcgldr.net/atari/IDBL.MAC

I have two versions of Indus CP/M floppies. One is the CP/M that I created for Indus and works in double density mode. I didn't go through all of the BIOS, but I did confirm that the INIT program matches my source code for it. I also found a couple of floppies labeled "Dave Small single density CP/M", but they didn't work and i don't recall how I ended up with them. I don't know what, if any changes, were made by Indus to the CP/M that I created for them. There's another program that I called ICDS.COM, which can transfer files between disks, and between CP/M and Atari DOS floppies. I've forgotten if SpartaDos floppies use the same directory structure as standard Atari DOS floppies. Unfortunately, the Z80 assembler I used is on 8 inch floppies for the ATR8000, but I don't know if it will even run anymore, and I can't find the 5.25 inch floppies I had for the ATR800. It should have XMODEM on it so if I can find a PC based XMODEM, I could transfer it that way. I'm pretty sure I used Microsoft's M80 (assembler) and L80 (linker), and it looks like a few web sites have this, so I may be able to get the assembler that way and by using SIO2PC, then ICDS, eventually onto an Indus CP/M floppy. I have the 6502 assembler on an Atari 8 bit floppy so it's only the Z80 assembler I need to find.

Keep in mind that Atari 400 / 800 / 65XE / 800XE run their 6502 at 2 mega hz, while the Apple II runs at 1 mega hz. The 6502 in an Atari 1050 runs at 1 mega hz. The Altair 8800 ran it's 8080 at 2 mega hz, but with the smallest instruction taking 4 cycles, it was like a 6502 running at 0.5 mega hz. The Z80 in an Indus GT runs at 4 mega hz.

Probably too late now, but assuming bad reads didn't entirely stop the read process, then some type of ECC (error correction code) could have been used. The simplest scheme would be to XOR each block and put that XOR block at the end of the tape. This would work only if one of the blocks was bad, XOR'ing all the good blocks read would recreate the one black that wasn't read. The next step would be to group the data on tape into groups of 16, 15 blocks of data, one XOR block, so that any one block bad out of the 16 could be recovered. Higher level ECC could be used, but the cpu time could be excessive, and probably not needed for a device with a relatively low error rate. Wiki article: https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction

OK, I think I get your point. With the 68000, PC relative addresses only need 16 bit offsets. Compilers that supported this would locate some of the function scope static data between functions in order to use PC relative addressing for those variables. (This wouldn't help much for global static data, since multiple functions would need access.) Local variables aren't an issue since they are stack relative, so it's only the static variables. I don' t know if Alcyon C compiler supported this. For the Mac, handles and other forms of global data had to be located in the first 32K chunk of a program. I don't know if load files contained a table of code references to the global variables in the first 32K chunk in order to fix up the addresses to allow for loader relocated code (since this part would not be self-relocatable). I think there was a way to use 64K chunks on a Mac taking advantage of the fact that the PC 16 bit offsets were signed and could be negative. I seem to recall an assembler where a directive was needed between functions to provide space for near range access to static variable from adjacent functions, but I don't recall if this was a 68000 assembler, much less one related to Atari or Mac.

+ As already posted, it uploads code into the RAM of a standard Indus GT to put it into 1050 US double compatible mode. Being able to put a standard Indus GT drive into emulator mode was clearly intended. Code can be loaded into RAM and run by putting in a bootable floppy disk into the drive, holding "drive type" and then pressing "enter" (I usually press "track" after a boot to display the track to see when it goes idle (track 39)). A standard Indus GT ROM has it's own version of a DOS for programs loaded into RAM, it has 2048 bytes of ram, using 256 bytes for sector I/O, a few bytes for the interrupt vectors, leaving about 1700 bytes of space for an emulator program. All of the interrupt vectors go through RAM, so that a booted program can easily replace the vector addresses to do things like intercept host commands for emulation mode. Similar to a PC boot, the Indus only reads one sector, and runs it. The code in from that first sector then reads in the rest of the code. The Indus GT can be used with a Commodore 8 bit computer, which I assume is a different protocol, and I don't know if this is done using a emulator boot floppy, or if they use a different ROM.

I don't know how much of Atari TOS was written in C versus written in assembly and/or if the Alcyon compiler produced assembly code which then got assembled. I recall a multi-pass 68000 assembler than kept trying to change branches to short format, but I don't know if the Alcyon tool set's assembler did that. In assembly code, you could suffix a branch with ".s" to specify the short format. Back to the Mac programs having to deal with legacy mode, another issue was that programs were split up into two parts, a program part and a resource part. The resource part could be loaded in bits to save space, and also updated (written), which I didn't quite get. For most other environments, the writable stuff related to a program (default overrides like directory locations) is kept in a separate file. Once Macs started having 1MB or more or space, they could have had an alternate flat address space type program. I don't recall if the Mac operating systems included virtual memory support for the ones that had MMU's. I assume AIX, which was Unix with a graphical interface for Macs, supported all of this stuff, and it was released long before OS X. One historical toolset for the Mac was Prototyper, which allowed a programmer to use drag and drop tools to design a user interface, after which Prototype would generate the code to support the user interface, while the programmer then added code to what Prototype generated. Specially formatted comments were used to separate what was generated by Prototype and what was added by the programmer. Visual Basic for Windows was similar, and the engineers at a few computer peripheral companies I worked for used Visual Basic to generate the code for interactive graphs, diagrams, text boxes, ..., to work with computer peripherals during the design phase. It was a quick way to create diagnostic or development type programs.

Thanks for the tool. What I have been doing instead is formatting floppies that are PC compatible, since both Atari ST and PC can read those.

What I meant by backwards compatible was related to an environment originally limited to 128K on the early Macs. It seems pointless on a system with 1MB of ram and very few, if any, instances of applications that ran 24/7. All of the handles had to be located in the first 32K chunk. Many of the calls to the system could result in the handles being updated, requiring the programmer to update any local pointers via the handles again. The other issue was having to manually edit link scripts to move modules around as needed to fit in 32K chunks. Think C did this automatically. A friend of mine used a new version of MPW about 5 years after I used it, so I loaned him my books, thinking these would not be much help, but we were shocked by how little had changed in MPW over during those 5 years (compared to Microsoft's transition into Visual C/C++ versions). Other annoyances with the early Macs was the lack of DMA, something that the original PC and most prior CP/M systems had. Programs had to use "blind transfer" mode where polling was used for the first byte of a 512 byte transfer, followed by a hard loop to transfer the remaining 511 bytes, controlled by a hardware delay. There were third party SCSI cards that offered DMA, so I don't understand why the Macs were so late in including DMA. Another annoyance was the continuing promise of a pre-emptive multi-threading kernel, such as OS/2 or Windows NT. I recall the promise that pre-emption would be in version 5, then 6, then 7, ..., and it wasn't until OS-X that it was implemented (there was AIX, but it wasn't popular). The combination of a price increase for Macs in late 1989 and the later releases of Windows 3.0 and 3.1 brought the Macs down from around 25% market share to 5% market share, but to be fair, once 386 EISA clones were released, the top 20 companies accounted for only 50% of market share, with the other 50% being mom and pop operations building 386 PC compatibles from common components.

Going back to the early days: 1969 - Wang 720 C programmable calculator - it had cassette tape for programs or files and a type ball printer that could move paper both up and down to allow it to be used as a crude plotter. I wrote a few programs on it, including a "loader" program that let the user enter a number to select and load a program from a series of programs stored on a tape, a Runge Kutta 4 to solve basic differential equations, and some other general programs. (my experience with this was in 1971) http://www.oldcalculatormuseum.com/wang720.html 1975 - Altair 8800 (already noted above in a few posts) 1975 - IBM 5100 - a 50+ lb "luggable" that could run APL or Basic, lots of rom, but only 64K of ram in most cases. Very expensive. I saw two of these at a local junior college. https://en.wikipedia.org/wiki/IBM_5100 1976 - Generic "S100" bus (the bus used on the Altair 8800) and proprietary bus CP/M systems. 1977 - Apple II The main application for CP/M systems used by most businesses was Word Star, which continued to be popular when ported to early PC's.

That won't be needed, I have the source code. What I don't have at the moment is a way to assemble it an produce a binary, then get it onto a Atari compatible disk. I was using the ATR 8000 for that, but it's I need to setup a space for it, mostly for the twin 8 inch full height floppy drives, an ADM monitor, and I'm not sure if it will work. I still haven't found the 5.25 inch floppy drives I used to create Atari compatible floppy disks. Currently I'm just looking for one or more people here that I can mail a floppy to, hopefully so they can figure out a simpler method to reproduce it. Another issue is I don't have a lot of blank 5.25 inch floppy disks. I'll look into this stuff later on this week. I'd like to be able to get the z80 assembler / tool set and my source files onto a Indus CP/M floppy. I do have a program on a Indus CP/M floppy that will let me transfer files between CP/M and Atari DOS format using the Indus, a second floppy drive, and an 8 bit Atari. If the ATR 8000 will run, maybe I can switch to running it on 5.25 inch or 3.5 inch floppies.

Altair 8800 was probably the first "home" computer. It was a kit, but there were retailers that sold fully completed systems. One of the companies I worked for during the early 1980's, Pertec Computer Corporation (PCC) bought out Mits, the people who made the Altair 8800. The default operating system was called DOS made by Mits. One of the optional operating systems, was something call CP/M from some startup called Microsoft. There was a C compiler made by a consulting company that could be built for Mits DOS or CP/M (via conditional compile (#if ...) ) , so Microsoft's original C compiler was actually made by a third party consulting group. Pertec also made it's own CP/M system, the PCC 2000, based on the 8085 instead of the more common Z80. It had a monitor, two 8 inch floppies and an 8 inch hard drive (6MB or so) all in one case, and a bank switched memory that could exceed 64K. Most of the CP/M "BIOS" ran in the banked switched memory. There was an in house upgrade to 8086 which ran CP/M 86 with up to 256KB of memory, but it was never sold. https://en.wikipedia.org/wiki/Altair_8800 As for a console / computer, the Bally Astrocade had a Z80 cpu, and there was a "Zgrass" upgrade to convert it into a CP/M system. Some vendor also made a CP/M system with 64K ram, but I don't recall who. It's not mentioned in the Wiki article. https://en.wikipedia.org/wiki/Bally_Astrocade

Forgot to mention, some control key sequences for the 40 character terminal, using ^ to represent control key: ^ delete - toggles screen between left and right side ^ ; - scrolls screen left one character ^ . - scrolls screen right one character ^ 3 - "locks" screen in place (not sure on this one)