Commander X16

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. 

 

 

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.



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. 

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.

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.

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. ?

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.

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.

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.

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.)

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. .