Jump to content

X16 Booted on 65816


Wavicle
 Share

Recommended Posts

Tracking an issue in my latest PCB gave me a brain tickle back to a conversation I had with Adrian Black (who famously has a Digital Basement) and Tech Man Dan Retro Tech Dan at VCFMW this past weekend. The '816 wouldn't boot on X16 due to a VERA timing sensitivity. Fixing VERA's timing issue should, in theory, correct both problems.

Presenting Commander X16 booted on a W65C816S at 8MHz:

image.thumb.png.ba3d76352c8d800790068eff445dbfa9.png

Edited by Wavicle
Corrected Dan's online moniker
  • Like 7
  • Thanks 3
Link to comment
Share on other sites

So when I went to click on the "WOW!" icon, I couldn't find one.  But I don't want to have to make do with "Like".  So...

oooooo   oooooo     oooo   .oooooo.   oooooo   oooooo     oooo .o. 
 `888.    `888.     .8'   d8P'  `Y8b   `888.    `888.     .8'  888 
  `888.   .8888.   .8'   888      888   `888.   .8888.   .8'   888 
   `888  .8'`888. .8'    888      888    `888  .8'`888. .8'    Y8P 
    `888.8'  `888.8'     888      888     `888.8'  `888.8'     `8' 
     `888'    `888'      `88b    d88'      `888'    `888'      .o. 
      `8'      `8'        `Y8bood8P'        `8'      `8'       Y8P 
                                                                                  
Edited by rje
  • Like 1
  • Haha 2
Link to comment
Share on other sites

On 9/13/2022 at 9:45 AM, Wavicle said:

Tracking an issue in my latest PCB gave me a brain tickle back to a conversation I had with Adrian Black (who famously has a Digital Basement) and Tech Man Dan at VCFMW this past weekend. The '816 wouldn't boot on X16 due to a VERA timing sensitivity. Fixing VERA's timing issue should, in theory, correct both problems.

Presenting Commander X16 booted on a W65C816S at 8MHz:

image.thumb.png.ba3d76352c8d800790068eff445dbfa9.png

First of all. Amazing and WOW! Secondly ... What is a W65C816S about? Sorry for my silly question.

Is this a new processor?

Link to comment
Share on other sites

On 9/13/2022 at 7:55 AM, svenvandevelde said:

First of all. Amazing and WOW! Secondly ... What is a W65C816S about? Sorry for my silly question.

Is this a new processor?

It's the full(er) part number of the 65816. The "16-bit"* successor to the 6502 that was in machines like SNES and Apple IIgs. David mentions the reasons for not using it in his dream computer #2 video. The biggest problem with the '816 wasn't so much demultiplexing the AD bus as getting the CPU and VERA to talk at all.

* not really 16-bit but did have a 16bit ALU and most registers were widened to 16 or 24 bits (I think the PC was widened to 24 bits, I could be wrong on that).

Link to comment
Share on other sites

Probably the biggest deal with 816 after the 24-bit bus is the segment pointers (forgive me, folks, if my terminology is off - I have -zero- experience with 816 assembly). I think of it as "portable zeropage" but even more is portable than that. The stack is portable, and there is a data segment as well - so you can make it point to any arbitrary table and then walk through it relative to the segment and not its actual address - these sorts of things speed up execution, and make multitasking and relocatable code easier.

Link to comment
Share on other sites

The "Programming the..." by David Eyes is over 600 pages, and for a reason; addressing modes and shifting back and forth from an 8 bit to 16 bit Accumulator and X/Y and 'l'ong/far instructions, but mostly compiler errors is a bit much for casual 6502 programmers.

David was right to NOT choose the 65816 (since part of his design criteria was to provide a platform for Commodore peeps, some of which were interested in porting code, some of which were interested in coding new games and apps).  [I'm generalizing so please be kind].

Stefany Allaire chose the 65816 and uses them on all of her C256 line machines from the FMX through the 'U' and 'U+' to the GEN X (embedded), but chose the 65C02 for the Jr. which is in the hands of about a dozen developers at the moment.  The Jr. is very much a 'rightsized' machine, meaning that the video modes, graphics capabilities, etc. are rightsized to match the 65C02 while *816 systems go 'big'.

The CPU indeed has a 24 bit adds bus (internally) so you'll need to get used to FF:FFFF addressing.  From a hardware perspective, however, you'll note that [in dip form] it's still a 40 pin package, so how does that work?  It's multiplexed, so therefore, it's complicated.  So HW engineers will have their hands full and that's where people usually give up or opt to pass.

This single page covers some of the diffs fairly well but if interested in 65816, grade the 'Eyes' book on Amazon, it's printed on 'white pages' paper, if that means anything you : ) https://apprize.best/programming/65816/23.html

 

 

Link to comment
Share on other sites

On 9/13/2022 at 1:18 PM, EMwhite said:

...The CPU indeed has a 24 bit adds bus (internally) so you'll need to get used to FF:FFFF addressing.  ...

In the above application, the upper 8 bits of the address bus are ignored. The richer set of instructions, more suitable for use in a general purpose 8bit computer than the 6502, are available, but the addressing would be the same 64KB memory map, HighRAM window and ROM window.

It is a better processor for assembly language programming, better for Forth programming, better for C programming, better for Pascal programming and better for Sweet16 programming, but the 65C02 has a smaller die mask.

  • Thanks 1
Link to comment
Share on other sites

In this particular implementation, the upper 8 bits of the 24-bit address are always ignored. Fixing this while retaining X16 compatibility would require a CPLD and a major architecture change to the board. On my latest PCB, I ensured that it was electrically compatible with the 65C816, but nothing beyond that.

The issue I fixed was a marginal timing condition on VERA where it snapped the address and data bus on writes at the rising edge of /WE. The precise reason this did not work is not clear to me, however the general reasons were: the datasheet specifies only 10ns from the falling edge of PHI2 when the write address and data are guaranteed to be held on the bus; the propagation delay of the NAND gate that drives /WE eats up most of that time; the stray capacitance of /WE on the board eats up a little more; the level shifter on VERA eats up a tiny bit more; I *think* that VERA sees /WE fall ~1-2ns before the end of the holding window. For some reason that 1-2ns isn't enough and VERA would occasionally catch some signals transitioning and end up with a corrupted write.

On the 65C02, this pretty much always ended up being the correct data written to the wrong address. In particular, for reasons not at all clear to me, it was always, or almost always, A2. I worked around the issue on the boards I took to VCFMW last weekend by adding a 30pF cap on A2. This would slow A2 falling from logic 1 to logic 0 by about 1ns and VERA would always catch the correct value. The 65C02 write value was always correct because the CPU doesn't start slewing those until well after the falling edge of PHI2 (except when writing the return address on the stack following a JSR or interrupt, but hopefully nobody designs a computer where VERAs IO windows overlaps the 6502's stack page.)

On the 65C816, the data lines switch to the address bank somewhere around 10.5-12ns after the falling edge of PHI2. I don't think VERA ever saw a write that wasn't $00 (the address bank of everything in emulation mode).

The fix was to sample the address and data bus on every VERA clock edge (every 20ns). When /WE is deasserted, the snapped bus state is the one seen on the last clock edge. There's a voice in the back of my head saying that there may be a metastability in there if VERA's clock edge is very close to /WE deassertion, but I've yet to see anything over millions of read/write cycles. I tried to avoid this by using the second-most-recent bus state, but that did not work. I'm not sure why.

  • Like 1
Link to comment
Share on other sites

More HW savvy readers may ask the obvious question of why I needed to add capacitance to VERA when Kevin's PCB did not. The most likely answer (to me, anyway) comes from a size comparison of the two PCBs:

Proto_comparison.jpg.5a133ee0a2e94b1867cb3308a10bd239.jpg

Kevin's board is micro-ATX and mine is mini-ITX. The trace length of the address and data lines on the official board are 2.5-3 times longer than mine. Those longer wires necessarily have more stray capacitance, and one doesn't need a great deal of additional capacitance to get it working. Considering all of the wires on the official board have to cross nearly the full width of the micro ATX board *twice* and then some, it seems to make sense.

The reason I had to dig down on this timing issue and not continue using a 30pF cap on A2 is that on my latest board (the green one in the first post) I tightened up my trace lengths even more and now VERA was missing A4 and occasionally A0. While pondering the exact cause and solution to the problem, my brain wandered back to the discussion I had with the other retro hardware experts Sunday evening and then had my eureka moment: the issue causing my current board to misbehave worse than the previous one and the issue preventing 65816 from working on the board had the same underlying cause: /WE deassertion wasn't seen by VERA until we were right on the edge of missing the correct bus state.

After getting the board to boot from 65C02 without adding more load caps, I swapped in a 65C816 to test the theory. After removing the 30pF load cap from A2, it worked!

  • Like 7
  • Thanks 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use