I'd like to begin this month's discussion by reviewing what we will accomplish with this modification, what we won't, and what we can't. A number of 8-bitters have commented on the project, raising a few valid questions and concerns.
First,
a clearer overview of the project:
This PBI hardware is designed to add additional computing power to your existing 8-bit Atari computer. MAJOR computing power. With a GR.0 screen, the 8-bit has approximately 20,000 CPU cycles to do things with during each video frame. This project adds an additional 210,000 CPU cycles to that capability. Along with the additional cycles, a 65816 also includes more efficient instructions and 16 bit operands. These two factors can result in a 2000% (20x) speed increase over the standard 1.79mhz 6502. This upgrade will increase the practical range of such tasks as image processing, page formatting, or data compression and probably represents the maximum resonable clock speed we will get on our Atari with current technology. Slower and more versatile methods may be employed to 'crank up the clock' - but that is not the focus of this hack. This is maximum overdrive. Kinder and gentler modifications will come later, OK?
What
do we have to give up?
If we could construct a complete, new circuit board for the entire 8-bit computer, nothing would be lost in this upgrade. But, nobody could afford it. So....
Memory upgrades are out. We can't use any of the internal memory because we can't make it run at 14mhz. Maximum overdrive, remember? This does not preclude expanding memory past 64K (more on that later), but the DRAM bank selected, $D301 type upgrades are out for now. This is not so bad... Even the biggest, baddest IBM PCs cannot run main memory at 14mhz. A 66mhz IBM actually runs a small portion of its memory (the cache) at 33 mhz and pages (moves) data to and from main memory at 8mhz. Even the cache can't run at 66mhz - only the CPU internals can run that fast. Our AUX processor runs all of its memory at 14mhz. This means that a poorly written IBM routine (one that jumps all over main memory) will run slower on a 66mhz PC than on the upgraded Atari (actually, the 65816 executes many instructions in fewer cycles than the 80x86 devices - a 14mhz 65816 will run on par with a 25mhz 80x86 in many applications).
The old Atari hardware is not available to the AUX processor. This includes ANTIC/GTIA, PIA, POKEY, cartridge and the PBI buss. None of these chips will run faster than 1.79mhz anyway, and the existing 6502 will still retain full functions on the hardware (including the PBI). The shadow registers are available, of course. $2FC will show you the last keystroke and $2C4 will set playfield 0 color and lum, for example. You will be able to alter the display list at $230 from the AUX processor as well as write directly to the screen at ($58) just like you did from the 6502. Just be a lot faster.. ....
Without an active effort on your part, it will not add any capability to your machine. It does require that software be specifically targeted to run in the AUX processor. This does not necessarily mean that code will have to be written for the 816. 6502 routines that do not use the hardware registers may well run without major modifications. All that is required is a CALLing code segment in the 6502 and parameter passing routines between the two CPUs. The AUX CPU has the option of using or not using the 6502s zero page and stack or any other memory. Existing code blocks (floating point math routines at $D800 - $DFFF come to mind) can be moved and run with a little effort. The AUX processor has access to ALL of the 6502 RAM as well as his own, independent 64K block.
What
might we get (besides turbo speed)?
One very nice aspect of this hack is the utility of having interrupts handled by the existing 6502. This allows the 65816 to run a continuous routine without interruption - a necessity for high speed data transmission. Many devices (modems, floppy drives, video capture ADCs) have very little capacity for holding data as it is being read or written. A floppy, for instance, starts reading a sector of data from the diskette with only two bytes of storage. If you don't read the data from the controller by the time two bytes are waiting, the read fails with an overrun. What this means is that if you take an interrupt during a read or write (where the CPU has to stop what it is doing and service the interrupt), the current sector will have to be re-run. This requires you to wait until that sector spins around under the head again - 200ms. This makes for very slow floppy drives. When using a modem, even the IBM systems require special buffers to run at high speeds (over 9600 baud). Adding floppy controllers, serial ports and A/ D or D/A converter chips to the AUX processor will not only allow very high speed operations, but the normal Atari interrupts for VBI, DLI and timers can still take place concurrently.
Consider the current SIO or PBI hardware. A 1050 is a 650x processor that runs a single floppy and communicates with the main CPU via the SIO. The 850 is a 650x processor that does serial and parallel transmissions, also communicating to the 6502 via SIO. Same for the P:R connection, the XF551 and most other SIO devices. With the AUX processor, all these operations can be handled at high speed with communication directly into memory. Even new functions can be implemented on the AUX processor, since it will be designed to seamlessly accept additional I/O chips. 80 column adaptors, A/D converters and SCSI interfaces fit into this category and present the only practical path for scanners and video capture devices (although the 8-bit has a low resolution display, it can certainly manipulate large graphic files as well as print them - even a high end PC does not have the resolution to display a full page 300 dpi laser image).
To work on large data objects may require much more than 128K of total memory. The current 20ns SRAM chips cost $20 each - a price that is low enough to allow 4 or more banks to be included in the upgrade. This would allow 512K or more of high speed memory to be accessed by the 65816 or even the 6502. It may even be possible to use the old $D301 control scheme for the 6502 while the 65816 will use all the SRAM memory directly.
OK,
enough discussion. Where were we?
Fine Tooned Engineering has now made available a 65816 upgrade that plugs into your existing 8-bit (those with 6502C processors - C014806). It runs at the same speed as the old 6502 and seems to run all the same software. Installation is as simple as unplugging your 6502 and inserting the new board. Almost all systems have socketed 6502s, so no soldering should be required (you 130XE folks get the short stick on this one). Once installed, the complete 65816 instruction set will be available to machine language programmers, including native mode and extended addressing (with no other changes, extended addressing is of little value, but a fairly simple external upgrade plugged into the PBI can provide useful extended memory space).
The
new instructions
Many of the old instructions can be executed on 16 bit operands (ADC, LDA, PHA, etc.), but 16 bit operations require native mode which I will discuss later. The instructions I am going to outline are all available in 6502 emulation mode (you default to emulation mode after RESET). Just code them in!
STZ
How often do you want to load $00 into a memory location? Instead of LDA $00 and STA $mmmm, you can now just STore Zero - STZ $mmmm. One step, no waiting, no alteration to the accumulator. Works in zero page, indexed and zero page indexed modes, too. Very cool.
TXY and TYX
I had to look this up. Hard to believe that it is only available on the 65816. Transfers the X index reg to the Y (TXY) or the Y index to X (TYX)
BRA
BRanch Always. No need to CLC and BCC LABEL or whatever. This is an unconditional branch. Need at least one in every program....
BRL
Ah.... first of the big time instructions. BRanch always Long. Know how you seem to be trying to do a relative branch just a teensy bit farther than allowed (more than 127 bytes away)? You used to have to 'land and refuel' to get where you wanted - sometimes more than once. BRL will unconditionally branch 32K from your instruction, forward or backward. No more error 10 on our ED/ASM! This instruction is eqivalent to a JuMP relative..... great for those relocatable routines.
XBA
The 65816 is a 16 bit CPU - which means that the internal data path (the X and Y regs and the accumulator) are 16 bits wide. In emulation (6502) mode, these registers are forced to use only 8 bits, but that does not mean that the accumulator is limited to only half of the register. The A register is the standard 8 bit accumulator. The B register is the 8 bit extention of the accumulator, making it 16 bits wide when in native (65816) mode. This B register can swap its contents with the A register using the XBA instruction. This is the only access to the B reg and would be useful when you want to save the value of A without throwing it on the stack or back into memory (I can already see where I could use this one...). XBA swaps the contents of B and A. Another XBA puts them back... Bubble sort, anyone?
LDA
LoaD Accumulator? Isn't that a 6502 instruction? Well„, yes, it is. But, even though we are in emulator mode, we can use some of the 24 bit addressing found on the 65816. There are the Long addressing modes - those using 3 byte addresses which work even in emulation. This lets your 8-bit directly address 16 megabytes of memory. No setup is required. No control registers - zip. Just LDA $mmmmmm. Done. Even better, the program counter (where we get instructions rather than data) is also extended. You can JSL $mmmmmm. You do need to be careful, though. If you JMP up into bank 10, your interrupt is not going to know where you were executing (the stack and zero page stay in the first bank, however). These Long addressing modes work on a variety of istructions besides LDA and STA.
There are additional instructions that you can use on your 816, in fact, all opcodes are now significant - they all execute something. Anyone writing 65816 code needs to write to WDC for the 65816 data manual. Tell them Bob sent you....
Ok - lots of really neat new stuff in emulation mode. How about native (16 bit) mode? Well, one thing that happens to you in native mode is that the interrupt vectors get moved a little bit. You can't enter native mode without fixing that (and a few other OS problems....) Stay with emulation mode for the time being. Maybe some rugged soul will patch up the OS for us and then we'll all be able to run 16 bits, native.
So,
what about the AUX processor?
At the moment, I am adding additional memory to the FTe 65816 processor. Using 4 SRAM chips, you have 512K of memory that can be directly addressed by the 65816 under the covers of your 8-bit. It is also arranged in a configuration that will be used concurrently with the AUX 65816 hanging out on the PBI. For those who may want just the memory and internal processor, you could use 512K SRAMs (when they are available) and have 2mb of storage.... Anyone planning on 14mhz in the AUX processor might want to keep it under half a meg. Too much loading (too many SRAM chips) may make the high speed CPU unreliable. This is a fairly simple hack - turn off internal memory with the -EXTSEL line and gate all EXTENB (which means we are accessing memory) to the correct SRAM bank. More on this next month....
Bob