Commander X16

22 hours ago, EMwhite said:

His next video is being contemplated now.  As a Patreon support of Ben's, I requested that he both interface directly to his 6502 project (which would be very close to what X16 has to do) and leverage an inexpensive microcontroller to do the dirty work.

Would be very interesting to see what he comes up with! To me using a microcontroller would be cheating a little bit, unless it is one that was also available in the same era or is less powerful than the main CPU ?

@Stefan Great analysis work! I take it you are also interested in how this works.

20 hours ago, Stefan said:

It will be interesting to see what changes, as the team is redesigning this code according to @Lorin Millsap above in this thread.

Same here, very curious to see what they come up with. I guess the interrupt driven method saves some cycles compared to constantly polling at some interval.

By the way, @kktos also had a great idea by storing key presses in RAM to be able to access them very quickly! I think this is also done by the C64 KERNAL...

39 minutes ago, JanSwanepoel said:

Would be very interesting to see what he comes up with! To me using a microcontroller would be cheating a little bit, unless it is one that was also available in the same era or is less powerful than the main CPU ?

I actually don't really view the X16 as  "Retro" computer, but more a bare-metal 8-bit learning, gaming, and demoscene computer. It has several modern implementations already when you look at it (like an ATX form factor, modern SRAM chips, modern banking implementation, SD card support, etc.).

It's just a frame of mind and just my opinion but this means, to me, using a microcontroller would be a-ok here. Of note, the PS/2 keyboards likely had some sort of uC or at least a set of logic gates for the output. And given Kevin like's ATTiny's (given his latest video), while that's a modern uC, it's still 8-bit. And it's through hole and also updateable which I think would be really need for a keyboard controller. You could upload your own keymap behavior for instance. It's also off the shelf, popular, cheap and with great availability.

If we were really leaning on Commodore heritage here, using another 6502 to manage peripherals might be a more period-specific implementation here (thinking about the disk drives having their own 6502 variants for instance). But that would be a lot more costly in board design and part counts than just using a cheap uC.

uC's may be necessary for these sorts of things, but at least if using something well known like Arduino-compatible chips, it means the system is still largely off the shelf, hackable, and still 8-bit.

So Ben's next video is out and he did not disappoint by coming up with a very interesting solution without using a microcontroller! I suppose the only drawback is that you can't really talk back to the keyboard to switch the LED's and stuff like that. Losing the parity bit is probably also not really a big issue unless your circuit is really noisy. If it's really an issue I guess it could also even be handled by some additional circuitry...   

 

On 3/11/2021 at 5:52 PM, m00dawg said:

Of note, the PS/2 keyboards likely had some sort of uC or at least a set of logic gates for the output.

The PC/AT and the PS/2 series both used an Intel 8042 microcontroller to operate the host end of the keyboard interface.

It’s a shame PS2 sends 11 bits because the VIA has built-in shift register functionality, but only 8 bits wide. The VIA could shift in the PS2 data automatically and the kernel could just read the latched value at leisure.

But not only are there too many bits, there are also too many bytes... maybe VIA could pause the PS2 device between each byte but the problem remains that the parity and stop bits will push the 2 MSB of the keycode out of the latch.

now, the joysticks don’t have this problem. THEY return 8 bits per latch (rather 16 but that’s just two runs of shifting in 8 bits) However, I bet the clock/latch pins of the controller ports aren’t connected to the correct pins of the VIA to do this in HW.

If this is the case, understandably, they’re not going to redesign the board to leverage this.

now I’m curious and gonna go look that up... lol



Update:

Quote

I bet the clock/latch pins of the controller ports aren’t connected to the correct pins of the VIA to do this in HW.

Confirmed - the emulator's via.h specifies that the DATA pins of the controllers 0..4 are connected to VIA1:PA7..PA4, and the common latch/clock pins are driven by PA2 and PA3, respectively.

The shift register uses CB1 and CB2. Using these, it would've been possible to do hardware-accelerated joystick polling, but it would've limited the system to using one joystick per VIA, and would still have required one data pin to be an output for sending latch commands to the controllers. Using SR mode 2, the VIA would shift in 8 bits from the controller every time you read from the shift register. Mode 2 means shift one bit each clock cycle, and stop after shifting 8 bits. So in this regime, you can assume the latch holds the previous value shifted in (except for the very first time, which could be done once during system init to seed this). You would just read from the latch however many bytes you want from the controller, and prior to reading the last byte (every byte for NES, every other byte for SNES), you would set and clear the latch pin so the final read will simultaneously trigger the VIA to shift in the first byte of this latching.