W65C02 on R1 of the Advanced PCB Remake For the Atari 800XL --- YES, it works! :-)

[reifsnyderb]

Something that bugged me about the idea of how difficult it is supposed to be to get a W65C02 running on an Atari is a simple question:  How great of a business decision would it be to create a "modern" 6502 CPU that can't be used as a replacement CPU?

 

This sounds like a bad idea to me.  What further confused the issue is that Western Design has instructions to use their CPU in an Apple I and Apple IIe.  (https://www.westerndesigncenter.com/wdc/AN-002_W65C02S_Replacements.php)  This seems to indicate that the W65C02 should have the voltage levels to work fine in an 8 bit computer....such as the Atari.  All it needs is some /halt logic. 

 

It is also known that Atari originally used a 6502B on the early 400's and 800's.  This required several additional chips to act as buffers and, essentially, create the clock signals external to the CPU.  Then, Atari had a chip created that we refer to as "Sally".  This Sally 6502 chip eliminated 4 chips and had the /halt pin so ANTIC could stop the CPU directly.

 

Then, there is the Byte Attic series with at least 3 videos on how the Byte Attic guy made an adapter board for the W65C02:  https://www.youtube.com/watch?v=iTJLFSFqFeE&ab  While this was quite an effort, it still left me wondering why a W65C02 was so difficult to use.

 

Over a year ago, and after looking carefully at a 6502B board in a 400, I was able to run the W65C02 in a 400.  A couple pins needed swapped and the BE pin had to be wired to the one flip flop.  Not a big deal, really.  So, I felt it should be a lot easier to run a W65C02 on an XL.

 

Less than 3 weeks ago I started working on another 800XL board.  This board was supposed to be a quick upgrade to bring an 800XL closer to the Sweet 16 Spec. and add a few nicer features.  As with a lot things, it evolved.  It's now an upgrade board with more features and will, eventually, have 2 breadboard locations.  (An idea cherry picked from the Apple I and Apple II R0 system boards.)  In the thread, that started with my original concept, I theorized as to how to use a W65C02 on the new board.  (https://forums.atariage.com/topic/355940-thinking-of-getting-a-new-atari-800xl-board-made/page/3/      (last post)  )  That entire thread also has more information on the board I used to run the W65C02.

 

I also theorized that the W65C02 bus enable pin (BE) could be used to "replace" the two transceiver chips Atari used to isolate the 6502B from the address bus.  On the W65C02, the BE pin will set the address bus, data bus, and RW to high impedance when set low.  So, that's 2 chips eliminated.  Another chip could be eliminated by using a programmable logic chip, such as an ATF16V8, to generate the clock signals and handle the /halt single from ANTIC.

 

This evening, I installed a W65C02 on the Advanced PCB Remake board.  Testing shows that so far, MULE runs off of floppy disk, the PacMan and Donkey Kong cartridges work.  Side3 sometimes works and I was able to play the PacMan Arcade Re-make off of it as well as run a few other programs.  (Side3 not quite working right is probably a timing issue I have to resolve yet.)

 

Here is the W65C02 wired in.  Not shown are several lines on the underside of the board.  The 74F08 was also removed as it was no longer needed.  (Actually, the board somewhat worked with the 74F08 still installed as I forgot to remove it the when I ran the first test.  I was surprised that the ATF16V8 was able to over-ride the 74F08.)  The ATF16V8 was able to replace that chip as well.  (Admittedly, without the 74F08, the light pen input is lost.  Not that it would work on a modern LCD display, anyhow.)

 

 

Here is the schematic whereby I made note of how to wire the ATF16V8B into the board.  All of the connections are listed and a Sally chip model is shown as a reference.  Note that Pin 11 needs wired to ground as well.  (This schematic is a design note, of sorts.)

 

 

Here's the 400/800 CPU board schematic:

Note the 4 chips needed to handle the /halt, clock signals, and address bus transceivers.

 

 

 

 

Edited November 12, 2023 by reifsnyderb

[reifsnyderb]

Here's the PLC WinCupl code to make this work:

 

 

Name       800XL 2023 Advanced PCB Remake - W65C02 Test;

Partno     NA;

Date       11/11/2023;

Revision   00;

Designer   Brian Reifsnyder;

Company    N/A;

Assembly   2023 Advanced PCB Remake - For the Atari 800XL;

Location   Bread Board;

Device     g16v8ms;

******************************************************************/

/*    800XL 2023 Advanced PCB Remake                */

/*    W65C02 PLC Control Chip                                         */

/*                                                                                        */

/******************************************************************/

/*  Allowable Target Device Types: ATF16V8                    */

/******************************************************************/

 

/**  Inputs  **/

 

Pin  03      = Phi0         ; /* Phi0 From ANTIC                */

Pin  05      = CPU_RW       ; /* RW from CPU               */

Pin  07      = A_HALT       ; /* /HALT from ANTIC          */

 

/**  Outputs  **/

 

Pin  13      = B_Phi2          ; /* Buffered Phi2                     */

Pin  14      = RW               ; /* RW From CPU                  */

Pin  15      = BE                ; /* CPU Bus Enable               */

Pin  16      = CPU_Phi2    ; /* Phi2 to CPU                  */

Pin  17      = Phi2_Sally     ; /* Phi2 as from Sally           */

Pin  18      = Phi1               ; /* Phi1 as from Sally           */

Pin  19      = Pulse             ; /* Pulse to set L_HALT          */

 

/**  Latch  **/

Pin  12      = L_HALT    ; /* /HALT Latch               */

 

/**  Logic Equations  **/

/**  # is or  **/

/**  ! is not **/

/**  $ is xor **/

 

B_Phi2     = Phi0;           /* Buffered Phi2 signal.            */

Phi2_Sally  = Phi0;           /* Phi2 as generated by Sally.      */

Phi1       = !Phi0;          /* Phi1 as generated by Sally.       */

 

CPU_Phi2    = Phi0 & L_HALT;  /* Phi2 to CPU.               */

 

!RW         = !CPU_RW;        /* RW from CPU to computer.         */

                                  /* Note:  When BE is low, CPU RW     */

                                  /*        is high impedance.                       */

 

BE          = L_HALT;         /* CPU Bus Enable.                  */

 

L_HALT.d    = A_HALT;         /* Latched /HALT.                         */

 

Pulse       = !Phi0;          /* Pulse to latch L_HALT.                   */

 

 

 

 

[reifsnyderb]

Picture of entire board:

 

[Chri O.]

WinCupl😁

Interesting just another distraction in my hobby.... let me knock the dust off the Afterburner - GAL chip programmer.

😁

[phaeron]

Compatibility issues that I know of between the 6502 and the 65C02:

• Undocumented instructions not supported
• JMP (abs) handles page crossing with extra cycle
• No false reads from the wrong address on page crossing when indexing
• D flag is cleared on interrupt
• Decimal mode takes an additional cycle to produce correct flags
• 65C02 stops on write cycles when RDY is pulled, meaning STA WSYNC will occasionally end one cycle too early, and INC WSYNC will always be one cycle early
• Read-modify-write instructions do two reads and one write instead of one read and two writes -- this invalidates ASL IRQEN style tricks for fast IRQ acknowledgment
• Absolute indexed RMW instructions are one cycle faster when not crossing a page

In theory, if you run a math pack benchmark like SysInfo, it should show the 65C02 running slower than a 6502.

[reifsnyderb]

7 hours ago, phaeron said:

Compatibility issues that I know of between the 6502 and the 65C02:

• Undocumented instructions not supported
• JMP (abs) handles page crossing with extra cycle
• No false reads from the wrong address on page crossing when indexing
• D flag is cleared on interrupt
• Decimal mode takes an additional cycle to produce correct flags
• 65C02 stops on write cycles when RDY is pulled, meaning STA WSYNC will occasionally end one cycle too early, and INC WSYNC will always be one cycle early
• Read-modify-write instructions do two reads and one write instead of one read and two writes -- this invalidates ASL IRQEN style tricks for fast IRQ acknowledgment
• Absolute indexed RMW instructions are one cycle faster when not crossing a page

In theory, if you run a math pack benchmark like SysInfo, it should show the 65C02 running slower than a 6502.

Thanks for posting this list.  It's quite comprehensive.   🙂

 

Some thoughts:

 

Is there any list of how many programs use the undocumented instructions?

 

Regarding RDY:  If RDY stopping the processor on write cycles is an issue, it should be possible to run the RDY signal through the PLC and only have it pulled low on read.  It's interesting that the 6502 datasheet states:  "This input signal allows the user to halt the microprocessor on all cycles except the write cycle." 

 

Another thought with RDY:  If RDY were to be ran through the PLC, maybe RDY and BE could be used together as another way to simulate the /HALT signal?

 

I am interested in running the benchmark.  Not having the keyboard available is an issue, though.  I don't want to connect the keyboard because de-soldering the connector could be miserable.

 

 

 

 

 

 

 

 

[tebe]

12 minutes ago, reifsnyderb said:

Is there any list of how many programs use the undocumented instructions?

a lot

 

http://drac030.krap.pl/pl-kompatybilnosc.php

Edited November 12, 2023 by tebe

[xxl]

8 hours ago, phaeron said:

Read-modify-write instructions do two reads and one write instead of one read and two writes -- this invalidates ASL IRQEN style tricks for fast IRQ acknowledgment

I remember a case where the program didn't work for this reason

[drac030]

41 minutes ago, tebe said:

a lot

 

http://drac030.krap.pl/pl-kompatybilnosc.php

That list has an English version: http://drac030.krap.pl/en-kompatybilnosc.php

 

And it lists the whole lot of 9 programs which use illegal opcodes.

[Overange]

49 minutes ago, reifsnyderb said:

 

 

I am interested in running the benchmark.  Not having the keyboard available is an issue, though.  I don't want to connect the keyboard because de-soldering the connector could be miserable.

 

 

 

 

 

 

 

 

Shame you cant link in the TK_II Keyboard circuit using a PIC16F1847 with PS2 connector, just to get keyboard input.

[reifsnyderb]

11 minutes ago, drac030 said:

That list has an English version: http://drac030.krap.pl/en-kompatybilnosc.php

 

And it lists the whole lot of 9 programs which use illegal opcodes.

MULE isn't on the list????    (MULE works!)

[reifsnyderb]

12 minutes ago, Overange said:

Shame you cant link in the TK_II Keyboard circuit using a PIC16F1847 with PS2 connector, just to get keyboard input.

I am thinking of figuring out and jumpering the correct keyboard connections.  I just have to simulate the arrow keys and return key.

[kenames99]

I was thinking you could just incorporate the transkey II circuitry directly on the board complete with ps2 plugis. somwhere by the joystick ports maybe?

 

Ken

 

[reifsnyderb]

1 hour ago, kenames99 said:

I was thinking you could just incorporate the transkey II circuitry directly on the board complete with ps2 plugis. somwhere by the joystick ports maybe?

 

Ken

 

I was thinking about putting a small breadboard section in the area between the joystick ports and the SIO connector.  Transkey could be installed there.  I'd rather not go down the road of adding loads of odds and ends as the original goal was for the board to have as few components as possible.  The breadboard areas allow somebody to more easily customize the board.

Edited November 12, 2023 by reifsnyderb

[+mytek]

1 hour ago, reifsnyderb said:

I was thinking about putting a small breadboard section in the area between the joystick ports and the SIO connector.  Transkey could be installed there.

You have my blessing if you decide to do that. To make things easy, here's the simplest implementation (only 4 Pokey connections required)...

 

PS/2

 

The Console key connections can be paralleled with the original mechanical tie in points, since they tri-state when not being used from the PS/2 keyboard. If you want both the PS/2 and the stock keyboard to work at the same time (or the stock one all by itself), on first power-up using the PS/2 keyboard execute a CTRL+ALT+X to switch TK-II's KR outputs to tri-state operation (this is a non-volatile selection, so only needed to be performed once).

 

EDIT: If you have some series resistors inline to the GTIA Console and Reset Circuit for connection of the mechanical switches, it would give better protection to the TK-II if its Console switch connections are done on the output side of those resistors (so in other words they would be connected directly to GTIA for instance).

 

TK-II PIC16F1847 Firmware LINK (it might be possible to buy a pre-programmed chip from TBA)

 

                PS/2 Jack Connections

 

[+scorpio_ny]

1 hour ago, reifsnyderb said:

I was thinking about putting a small   The breadboard areas allow somebody to more easily customize the board.

Initially, I was not sold on the idea of the breadboard because it would be as neat as a baked in design. But this could be a “ killer app” because I can see people building projects into the board without going through the process of fabricating a custom small PCB to incorporate the changes. And if one still wanted a small custom PCB, you have a nice spot on the motherboard to mount it.

[reifsnyderb]

1 hour ago, mytek said:

You have my blessing if you decide to do that. To make things easy, here's the simplest implementation (only 4 Pokey connections required)...

 

PS/2

 

The Console key connections can be paralleled with the original mechanical tie in points, since they tri-state when not being used from the PS/2 keyboard. If you want both the PS/2 and the stock keyboard to work at the same time (or the stock one all by itself), on first power-up using the PS/2 keyboard execute a CTRL+ALT+X to switch TK-II's KR outputs to tri-state operation (this is a non-volatile selection, so only needed to be performed once).

 

EDIT: If you have some series resistors inline to the GTIA Console and Reset Circuit for connection of the mechanical switches, it would give better protection to the TK-II if its Console switch connections are done on the output side of those resistors (so in other words they would be connected directly to GTIA for instance).

 

TK-II PIC16F1847 Firmware LINK (it might be possible to buy a pre-programmed chip from TBA)

 

                PS/2 Jack Connections

 

I added a breadboard section, on the top right, that is laid out conventionally, with the +5VDC rail, the GND rail, and the interconnects between pins like a conventional breadboard.  I decided on putting the +5VDC rail on the right so if a chip is mounted it would usually have pin 1 to the upper left.  The console keys are already broken out to make it easier to play MULE without having to install the board in a case.  🙂   (I suppose the console key pads could find other uses as well.)

 

 

 

 

Edited November 12, 2023 by reifsnyderb

[reifsnyderb]

52 minutes ago, scorpio_ny said:

Initially, I was not sold on the idea of the breadboard because it would be as neat as a baked in design. But this could be a “ killer app” because I can see people building projects into the board without going through the process of fabricating a custom small PCB to incorporate the changes. And if one still wanted a small custom PCB, you have a nice spot on the motherboard to mount it.

I wasn't going to do the breadboard, either.  But then the requests came in and I thought of what Apple did on their first boards and it seemed like a nice compromise with lots of capabilities.  The breadboard made installing the W65C02 rather easy.  Using the breadboard on this first revision also helps to find any problems and fix them for the next (and hopefully final) version of the board.

[+David_P]

1 hour ago, reifsnyderb said:

 The console keys are already broken out to make it easier to play MULE without having to install the board in a case.  🙂   (I suppose the console key pads could find other uses as well.)

 

 

I for one am relieved that MULE compatibility remains the critical test for all your hardware hacking.

[+scorpio_ny]

2 hours ago, reifsnyderb said:

I wasn't going to do the breadboard, either.  But then the requests came in and I thought of what Apple did on their first boards and it seemed like a nice compromise with lots of capabilities.  The breadboard made installing the W65C02 rather easy.  Using the breadboard on this first revision also helps to find any problems and fix them for the next (and hopefully final) version of the board.

That’s great! Will you publish the schematics to things you have already tested? Such as the  W65C02?

[reifsnyderb]

44 minutes ago, scorpio_ny said:

That’s great! Will you publish the schematics to things you have already tested? Such as the  W65C02?

I'll have to put together a manual, of sorts, for this board.  I plan to include instructions, schematics, WinCupl code, etc., for as much as possible.  The base schematics for using a W65C02 are already in this thread.  I did remove that hold-up resistor, however, and just modified the WinCupl code.

 

I did look, briefly, at what would be involved to natively support a W65C02.  However, there is still a slight timing issue that's a problem.

 

On the other hand, I just finished a complete game of MULE on the board with a W65C02.  So, that's promising.   🙂

 

[macsonny]

This is fantastic! 

 

Sally-to-W65C02S-adapter/README.md at master · TheByteAttic/Sally-to-W65C02S-adapter · GitHub

 

Does anyone know the size of the board and number of layers so I can order from PCBWay?

 

Edited November 13, 2023 by macsonny

[reifsnyderb]

1 minute ago, macsonny said:

This is fantastic! 

 

Sally-to-W65C02S-adapter/README.md at master · TheByteAttic/Sally-to-W65C02S-adapter · GitHub

 

Does anyone know the size of the board and number of layers so I can order from PCBWay?

 

I have no idea on that board.  I am doing this on a new, more modern, 800XL board.  🙂

 

[reifsnyderb]

First the system is running fine with the W65C02 unless I use the Side3 cartridge.  With the Side3 cartridge it is unstable and will usually fail to boot.

 

On a hunch, I put the 74F08 chip back in place to buffer Phi0 and Phi2.  After a little more testing, it seems that I need to make sure that Phi0 goes into the 74F08 buffer prior to going to the PLC.  Also, Phi2 needs to pass through the 74F08 buffer as well.  Once I re-installed the 74F08, and routed both signals through the 74F08, the Side3 cartridge seems to work fine unless I plug the 1091 in.  While the system works fine using only the PLC as a buffer, it appears the additional delays are required to make the Side3 happy.  (Picky, picky.)  Originally, I eliminated the 74F08 altogether because I figured that if any buffering was required the PLC would also double as  buffer with it's 10 ns delay.

 

Making the above changes appears to improve the stability when using the 1091 and a 320k RAM card.  However, there are still some occasional memory corruption problems.  (i.e.  Intermittently fails to boot and sometimes has a slightly corrupted display.)  Limited testing with the 1091 shows that the 80 column card works by itself as the proper Altirra BASIC and Atari BASIC Ready prompts always come up on boot.  This indicates there aren't any serious problems reading the ROM.  So, my guess is that the problem may be write timing with the RAM.  The 1091 uses a 74LS123 to generate a short Phi2 signal for writes and both the 1090XL and 1091XL have address and data buffers.  I suppose it's possible there is a difference in write timing between the Sally and the W65C02.  Given this theory, the next step appears to be to examine the data sheets and closely compare the timing between the W65C02 and the 6502.

 

Edit:  I think I found the problem and it was that I no longer needed the buffered Phi2 coming off of the PLC as Phi2 is now buffered normally.  I think it's working with the 1091XL and 320k SRAM card.  More testing is needed but it appears to be stable.   🙂

 

 

 

Edited November 14, 2023 by reifsnyderb

[reifsnyderb]

Updated schematic.  Sally still shown for reference...