Jump to content

Bus Pinout on Proto #3


Recommended Posts

22 hours ago, BruceMcF said:

Yes, I was a little disappointed it did not show up here, but what I really want to show up here is a detailed description of the new expansion card format, and that post did not have many technical details.

At a glance and squinting at the silkscreen above and comparing it to a published signal breakout from the prior (proto2) 50 pin slot, it looks like: 

'BUS_L' and 'BUS_R" are labeled on the old diagram but not here; however the silkscreen above shows  AUDIO_? and AUDIO_?  (? is because I can't see the suffix).   It could be these are the same signals... but I don't know.    VPB - (vector pull) has been added.    NMIB - (Non Maskable Interrupt) has been added.    Seven (7) more (by my count) GND  paths have been added.  A second 3.3v has been added.   Virtually all signal locations have been rearranged.

From where I sit:   NMI on the add-on card slot is good for obvious reasons.  Probably also that vector pull signal.   If memory serves, 'vector pull' is sort of a  'look at me to see if the processor is acting on an interrupt vector' kind of signal.    I have no idea how that all works in practice but its probably worthwhile addition. 

 

 

Link to comment
Share on other sites

The bus pins may be a little misleading as some of them have the 65C816 names labeled.  I am debating on exactly how to label the board, or whether or not I should at all.  Even though the system is designed to be a 65C02 based machine, I designed it such that a 65C816 will work electrically in the board.  The Kernal isn't a fan of the 816, so it would have to be running a different OS, but we wanted to make sure people had the option to do what they wanted with the system.  When I moved to the 60 pin slot, I had enough room to move nearly all of the CPU lines over.

Untitl.png.2559952e362510388dae3db5dfcd0d1a.png

So long story short, I should probably label the board based on the 02 names, but I've been focused on making sure you can still plug in a 816 with no HW mods needed other than swapping the chip, and the code of course.

The Audio lines are inputs which are sent to the audio mixer, left & right channel.  I know it's unlikely there will be a need for more sound chips with the VERA and the YM2151, but I thought someone might want to add a SID, or maybe put the SAA1099 back on later, etc.  It will just allow you to pump audio in from an expansion card.  I moved the pins to line up with the actual layout of the CPU to simplify routing.  It's the beauty of nothing being carved in-stone.... Yet. 

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

1 hour ago, Kevin Williams said:

  The Kernal isn't a fan of the 816, so it would have to be running a different OS, but we wanted to make sure people had the option to do what they wanted with the system. 

Unless I'm mistaken, the 816 defaults to 6502 emulation mode, so maybe the kernal would work unless the CPU is switched to native mode.

I do love the idea that a 65c816 is part of the design - I really liked that CPU, as it was in my favorite computer of the 80s, the Apple IIgs.

Link to comment
Share on other sites

5 minutes ago, Jeff Pare said:

Unless I'm mistaken, the 816 defaults to 6502 emulation mode, so maybe the kernal would work unless the CPU is switched to native mode.

I do love the idea that a 65c816 is part of the design - I really liked that CPU, as it was in my favorite computer of the 80s, the Apple IIgs.

Being in 6502 emulation mode would not be exactly the same as the 65C02 instruction set. I think the differences are small enough that one could write a kernal / BASIC that worked for either 65816 in emulation mode and 65C02, but if any of the bit set / clear instructions were used they would be NOPs in emulation mode.

Link to comment
Share on other sites

While this is true, the reality is it's not working correctly.  I'm not 100% sure why, but the VERA is not initializing correctly with the current kernal.  Michael Steil is not a fan of the 816, so I'm guessing it won't be high on his priority list. 🙂

Link to comment
Share on other sites

3 hours ago, Kevin Williams said:

I thought someone might want to add a SID, or maybe put the SAA1099 back on later, etc. It will just allow you to pump audio in from an expansion card.

It's a nice feature but I wonder if it is worth the two expansion slot pins.  Did you consider the PC motherboard way, a pin header and CD-audio cable?

 

2 hours ago, Kevin Williams said:

Michael Steil is not a fan of the 816

Same here.  I can't muster even a little nostalgia for it.

Link to comment
Share on other sites

12 hours ago, Scott Robison said:

Being in 6502 emulation mode would not be exactly the same as the 65C02 instruction set. I think the differences are small enough that one could write a kernal / BASIC that worked for either 65816 in emulation mode and 65C02, but if any of the bit set / clear instructions were used they would be NOPs in emulation mode.

 

12 hours ago, Kevin Williams said:

While this is true, the reality is it's not working correctly.  I'm not 100% sure why, but the VERA is not initializing correctly with the current kernal.  Michael Steil is not a fan of the 816, so I'm guessing it won't be high on his priority list. 🙂

Well, that kinda sucks. If a kernal rewrite (or replacement) is necessary anyway, might as well aim for the 816 - not saying Michael should do it or that it should be included at release, just something to do down the road if there's enough interest.

Link to comment
Share on other sites

10 hours ago, picosecond said:

It's a nice feature but I wonder if it is worth the two expansion slot pins.  Did you consider the PC motherboard way, a pin header and CD-audio cable?

It's a feature I'm actually quite glad to see, although not sure if/how it would work with multiple sound cards. Kevin mentioned above he thought it was unlikely there will be any sound cards given the YM and VERA but I actually think the opposite based on following the project. Given the DPCM on the VERA is a one-shot (non-looping) audio buffer, I could see (and half expect) someone is going to come out with a sample based card (ala GUS PnP perhaps) to enable sample-based trackers and music makins. That plus I'd expect someone to make a SID card because SID. Not sure how popular those might be but I'm expecting it. Though granted, at this point, I'm not planning on it in CommandTracker. Juggling the 2151 and PSG is enough for me to manage for now.

All that said, I would think a system that's using multiple sound cards might be more of a rarity so I do wonder how that'd work. Just looking at the board layout I don't see say any resistors to form a passive mixer for each card slot. That might require sound cards having to consider the cases where there's more than one sound card being used with some solutions to manage that (like maybe jumpers for whether or not the audio goes through resistors first or something). This is the case where a pin header might be more useful as one can have a passive mixer board into the pins for the cases where there's multiple sound cards, but then that clutters things.

Of course, there's always the option to just output the audio externally like most sound cards did and then folks can just use an external mixer.

Link to comment
Share on other sites

28 minutes ago, Jeff Pare said:

 

Well, that kinda sucks. If a kernal rewrite (or replacement) is necessary anyway, might as well aim for the 816 - not saying Michael should do it or that it should be included at release, just something to do down the road if there's enough interest.

Well, there's no rewrite planned that I'm aware of, just modification of the C64 kernal to match the hardware of the X16 and extend the API.

Having contributed a bunch to the official emulator, forking my own, and poking with the CPU and memory mappings, my guess is that it's not so much a problem with VERA initialization as that the '816 either has a conflicting opcode with the 65C02 that the kernel is using, or is expecting some new piece of memory to be mapped in a way that conflicts with what the kernel is doing, and the kernal is crashing or entering an infinite loop before it gets to VERA initialization.

(I would have guessed a conflicting opcode, but added memory wonkiness because someone on the unofficial Discord server suggested the 65816 has a hardwired memory requirement -- similar to the 65c02's CPU stack from $100-$1FF -- that the kernal isn't taking into account.)

Link to comment
Share on other sites

2 hours ago, StephenHorn said:

Well, there's no rewrite planned that I'm aware of, just modification of the C64 kernal to match the hardware of the X16 and extend the API.

Having contributed a bunch to the official emulator, forking my own, and poking with the CPU and memory mappings, my guess is that it's not so much a problem with VERA initialization as that the '816 either has a conflicting opcode with the 65C02 that the kernel is using, or is expecting some new piece of memory to be mapped in a way that conflicts with what the kernel is doing, and the kernal is crashing or entering an infinite loop before it gets to VERA initialization.

(I would have guessed a conflicting opcode, but added memory wonkiness because someone on the unofficial Discord server suggested the 65816 has a hardwired memory requirement -- similar to the 65c02's CPU stack from $100-$1FF -- that the kernal isn't taking into account.)

It’s probably the opposite. The 816’s stack and Direct Page can be moved. So it may be that they need to be initialized as part of the startup procedure. . 

Link to comment
Share on other sites

34 minutes ago, TomXP411 said:

It’s probably the opposite. The 816’s stack and Direct Page can be moved. So it may be that they need to be initialized as part of the startup procedure. . 

In emulation mode it is supposed to start with ZP & stack at their well defined 6502 locations. I've never used an '816, just based on my reading. The opcode issue could be real if any of the bit set / clear extensions are used in the kernal or BASIC as emulation mode apparently doesn't support them, though they are available in native mode.

Link to comment
Share on other sites

27 minutes ago, Scott Robison said:

In emulation mode it is supposed to start with ZP & stack at their well defined 6502 locations. I've never used an '816, just based on my reading. The opcode issue could be real if any of the bit set / clear extensions are used in the kernal or BASIC as emulation mode apparently doesn't support them, though they are available in native mode.

 

1 hour ago, TomXP411 said:

It’s probably the opposite. The 816’s stack and Direct Page can be moved. So it may be that they need to be initialized as part of the startup procedure. . 

Yeah, I've only every used an 816 in an emulator. Bit Set / Clear extensions are one possibility ... they obviously would not have been in the original codebase, so it's whether they have been added ... another, given the issues with timings and the fact that Vera might be quicker to read than other chips on the board, is the $00 on the data bus during the first phase tangling something up.

Another might be a "tacit bug" ...  a misdirected branch "executing" an unimplemented opcode as a NOP, but it is a 65816 opcode, which if NOT in the 65c02 opcodes actually performs it's native mode action, 65c02 even if in emulation mode. IOW, emulation mode is emulating 65C02 OPCODE functions, not "emulating a 65C02".

Edited by BruceMcF
Link to comment
Share on other sites

2 hours ago, Scott Robison said:

In emulation mode it is supposed to start with ZP & stack at their well defined 6502 locations. I've never used an '816, just based on my reading. The opcode issue could be real if any of the bit set / clear extensions are used in the kernal or BASIC as emulation mode apparently doesn't support them, though they are available in native mode.

That would do it, I suspect.

Personally, I'm just very disappointed that they didn't go with the 816 from the start. It only takes one extra chip to make it work as intended, and we wouldn't have the silly 4K banks. Instead, we'd have up to 16MB of RAM in 64K banks.

I started designing a (very non-Commodore like) OS for the 816 back when Stefany got started with the Feonix. Building an OS to operate with multiple 64K banks and 16-bit reads and writes is much, much easier and faster than the way the CX16 was designed. I get why Michael and David went with something familiar, but the 65816 with a 24 bit address space would have been so much better, the difference is almost night and day. 

Edited by TomXP411
Link to comment
Share on other sites

Note that the bit set/clear instructions that are not available in the 65816 are unavailable in any mode ... they are the Rockwell extensions, and those opcodes do other things in the 65C816 instruction set.

Link to comment
Share on other sites

3 hours ago, BruceMcF said:

Note that the bit set/clear instructions that are not available in the 65816 are unavailable in any mode ... they are the Rockwell extensions, and those opcodes do other things in the 65C816 instruction set.

Thanks for the clarification. That makes a lot more sense. I was under the impression from quick reading that was not the case.

Link to comment
Share on other sites

These are the $x7 and $xF opcodes, RMB0-RMB7, SMB0-SMB7, BBR0-BBR7 and BBS0-BBS7. In the 65816, these are four new address modes for the 8 main accumulator operations, ORA, AND, EOR, ADC, STA, LDA, CMP, SBC ... op [d]; op [d],Y; op al; and op al,X ... 24bit indirect and post-indexed addressing, 24bit absolute and X-indexed absolute addressing.

 

Edited by BruceMcF
Link to comment
Share on other sites

1 hour ago, BruceMcF said:

These are the $x7 and $xF opcodes, RMB0-RMB7, SMB0-SMB7, BBR0-BBR7 and BBS0-BBS7. In the 65816, these are four new address modes for the 8 main accumulator operations, ORA, AND, EOR, ADC, STA, LDA, CMP, SBC ... op [d]; op [d],Y; op al; and op al,X ... 24bit indirect and post-indexed addressing, 24bit absolute and X-indexed absolute addressing.

I was subconsciously aware of this, but having never used an '816 didn't think it through thoroughly. It is confusing in part due to the fact (as I understand it) that 65c02 didn't include the bit instructions, but later added them and introduced the 65sc02 that didn't have them. So rather than leaving 65c02 alone, it was updated and a new part was created to keep the older functionality, and that part no longer exists.

Again, as I understand it. I may be way off base, it's hard to find the complete information because at this point, all details of 65c02 document it as including the bit instructions but originally it was a proper subset of 65c816.

Link to comment
Share on other sites

3 hours ago, Scott Robison said:

I was subconsciously aware of this, but having never used an '816 didn't think it through thoroughly. It is confusing in part due to the fact (as I understand it) that 65c02 didn't include the bit instructions, but later added them and introduced the 65sc02 that didn't have them. So rather than leaving 65c02 alone, it was updated and a new part was created to keep the older functionality, and that part no longer exists.

Again, as I understand it. I may be way off base, it's hard to find the complete information because at this point, all details of 65c02 document it as including the bit instructions but originally it was a proper subset of 65c816.

Yes, Rockwell added these instructions to the original 65C02. WDC added a few other instructions. Rockwell had a big order for their version of the chip (IIRC it was a French telecoms company, but that may be wrong) ... and so WDC added the individual bit instructions to their version of the 65C02 so they could be second source for that company.

However, that was just to gain that market. The 65C02 instructions that the 65816 "emulation mode" emulates is their original WDC65C02 design. Those are specialized instructions primarily for using the 6502 in a controller application with I/O memory mapped into part of the zero page, and with the relocatable direct page, that wasn't in line with what the 65816 was targeting.

I forget whether Western originated the TSB and TRB instructions or whether they included those following an earlier 65C02 design, but those are much more flexible instructions in addressing and occupy much less of the instruction set, even if they usually have to be preceded by an immediate load instruction.

Edited by BruceMcF
Link to comment
Share on other sites

5 minutes ago, BruceMcF said:

Yes, Rockwell added these instructions to the original 65C02. WDC added a few other instructions. Rockwell had a big order for their version of the chip (IIRC it was a French telecoms company, but that may be wrong) ... and so WDC added the individual bit instructions to their version of the 65C02 so they could be second source for that company.

I wonder why WDC didn't create a 65c02e (for enhanced, or x for extended, or r for Rockwell...) and make that the updated part. Adding them to the existing product seems more confusing that it needs to be.

Link to comment
Share on other sites

9 minutes ago, Scott Robison said:

I wonder why WDC didn't create a 65c02e (for enhanced, or x for extended, or r for Rockwell...) and make that the updated part. Adding them to the existing product seems more confusing that it needs to be.

It didn't modify the operation of their existing design except for the $x7 and $xF opcodes no longer being NOPs, and Rockwell sold theirs as 65C02's (maybe R65C02?), so it likely made sense in selling the updated chips as a second source to the target company. They weren't selling the two versions side by side, after all ... the 6502's at that time were selling briskly enough for industrial control boards that a month of overlapping inventories for a fully backwards compatible upgrade wasn't a problem.

Also IIRC (so no guarantees), the 65CS02 was not about the change in instruction set, it was about revising the chip to be fully static ... though at the same time additional instructions were added. The Rockwell and Western Design versions were fully static from the outset, so they had no need to single out their fully static version.

One thing I certainly don't recall is whether MOS or Fairchild or somebody else took the lead in the CMOS version of the CPU.

Edited by BruceMcF
Link to comment
Share on other sites

10 minutes ago, BruceMcF said:

It didn't modify the operation of their existing design except for the $x7 and $xF opcodes no longer being NOPs, and Rockwell sold theirs as 65C02's (maybe R65C02?), so it likely made sense in selling the updated chips as a second source to the target company. They weren't selling the two versions side by side, after all ... the 6502's at that time were selling briskly enough for industrial control boards that a month of overlapping inventories for a fully backwards compatible upgrade wasn't a problem.

Also IIRC (so no guarantees), the 65CS02 was not about the change in instruction set, it was about revising the chip to be fully static ... though at the same time additional instructions were added. The Rockwell and Western Design versions were fully static from the outset, so they had no need to single out their fully static version.

One thing I certainly don't recall is whether MOS or Fairchild or somebody else took the lead in the CMOS version of the CPU.

My understanding is the WDC was the lead on CMOS 6502.

65C02S is the fully static current part, but that is not the same as 65SC02. It really doesn't matter, I guess. I'd just like to know the real history and rationale for 65SC02 (because I guess the S position is important).

Link to comment
Share on other sites

According to http://forum.6502.org/viewtopic.php?f=4&t=1383&sid=4442153f5d07a1b0c9a9b4803b0cbd59&start=15 (which I guess is going to have to satisfy my curiosity):

Original 65C02 from WDC did not have bit instructions. Rockwell added them and WDC copied them (presumably for the second source reason @BruceMcF gave above).

GTE apparently used 65SC02 in their part numbers of the original 65C02 IP. Presumably once 65C02 (originally with a B suffix, now no suffix) had the bit instructions I'm going to assume WDC added the 65SC02 to their line to "second source" the GTE so there was identical parts available for both third party products. They've since dropped the 65SC02.

Link to comment
Share on other sites

On 7/16/2021 at 5:50 AM, Scott Robison said:

My understanding is the WDC was the lead on CMOS 6502.

65C02S is the fully static current part, but that is not the same as 65SC02. It really doesn't matter, I guess. I'd just like to know the real history and rationale for 65SC02 (because I guess the S position is important).

No, that's right, the fully static part is suffix S. Rockwell licensed the earlier "half-static" version from WDC, which could hold clock high indefinitely, but not clock low. Since Rockwell licensed Western's design, it seems likely that "their" bit instructions was something they hired Western to do, to streamline their modem code, which would explain why Western was the company able to second source Rockwell's version. And since Western's version was fully static, the second source was an upgrade on the original source.

Edited by BruceMcF
Link to comment
Share on other sites

It bears keeping in mind that it's not unusual for standard government contracts to give preference to parts that are available from more than one supplier, so it is possible that a different provider as a second source of a compatible part can be a useful step to land a large government order. In that case, rather, "hey, why are you selling the customized design I ordered from you?" it can be, "c'mon, how soon am I going to be able to show that you are also selling the customized design I ordered from you?"

  • Like 2
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