Commander X16

Yes, this is really just a quick and dirty bit of code I setup to get the power button working and make sure I could send data to it from the system.  This works, (except for the reboot command for some odd reason).  I never really took it any further.  



Sorry I've been away for so long.  I didn't intend to, but I wound up getting pretty busy over the last few weeks and now I'm less than a week from going to VCF Midwest.  When I get back, I'll hopefully be caught up soon thereafter and can focus on this more.

Take care!

-Kevin

4 hours ago, Kevin Williams said:

This works, (except for the reboot command for some odd reason).  I never really took it any further.  

Hard to tell without a schematic and a description of the failure, but assuming this screen cap is still the board:



 

I'm guessing that R38 and R8 are current limiting resistors for the LEDs and R39 and R40 are pullups for I2C, so you have no external resistor on the daughterboard connected to RESET_BUTTON_PIN. The ATTINY does have internal pullups that can be used on input pins, but that functionality appears to require you to specify the pinMode as INPUT_PULLUP (see lines 95 and 101 here: https://github.com/SpenceKonde/ATTinyCore/blob/a2387a8d5551272e6860fb830099c2473a6da22a/avr/cores/tinymodern/wiring_digital.c):

	 //Button Setup
 pinMode(POWER_BUTTON_PIN, INPUT);
 pinMode(RESET_BUTTON_PIN, INPUT_PULLUP); // don't leave this floating
 pinMode(NMI_BUTTON_PIN, INPUT);
	

If this were the problem and I'm reading the code correctly, I think it would show up as a floating pin so the attiny could think the button was still down even after being released. Alternatively, you could have a pullup on the motherboard and this isn't the problem at all. That's my best guess after 10 minutes of investigation ?. If that is the issue, the other two buttons probably need the same change.

If you do a digitalwrite to an input pin, it will activate the pullup resistor as well.  I had done that in my code originally, but I have proper pullup resistors on the rev 3 board as I recall, so I commented these out.

Any luck getting the PS2 working with the VIA's @ 8mhz ?

Suggestion: use an ESP32 or possibly ESP8266.

They're cheap, much more powerful than Arduino, there's already a working and well used Mouse/Keyboard/SDCard library for the ESP32 which has been flogged to death (partly by me, it does colour video as well !). You also have a Wifi system thrown in for good measure for later use. Should be possible to bit bang an SPI or I2C connection to transfer data reasonably quickly (not sure about SD Card may be too slow). Many boards can be powered of 5v even if they run at 3v3 and I don't think I2C cares.

You could go the whole hog and connect it to the sound chip as well (the library does sound as well ....) and use it as an auxiliary device.

Even better, dump the A/D audio system on Vera which doesn't have enough memory and use the memory in the ESP32 to store audio waveforms, and keep Vera for graphics.

Authenticity rules ok .....

Hi,

On Facebook there was a post answered by David that I read today, and that said that there is yet no solution to the PS/2 issue.

Unfortunately, I have no clear idea of how the 65C02 -> 65C22 -> ATTINY861 setup would work.

Some thoughts:

• 
  I suppose one possibility is that the ATTINY generates a NMI on the 65C02 when there is PS/2 data to be read.
  


• 
  A drawback of this design is that the NMI could occur at any time, possibly disturbing other time critical code running on the 65C02.
  


• 
  Another design option might be to let the ATTINY buffer PS/2 codes received, and to disable PS/2 communication if the buffer is full.
  


• 
  To support both keyboard and mouse, there could be one buffer for each
  


• 
  I suppose the ATTINY cannot handle both the keyboard and mouse simultaneously. Maybe there needs to be a priority, for instance so that on receiving PS/2 data from the keyboard the mouse PS/2 line is always disabled.
  


• 
  With this setup the Kernal code could try fetching one PS/2 scan code from the keyboard and mouse buffers on each VBLANK.
  

General question/concern; was it not the idea with this forum to get the announcements and communication from David & Co here first? 

 

 

On 12/29/2021 at 2:38 PM, martinot said:

General question/concern; was it not the idea with this forum to get the announcements and communication from David & Co here first? 

I'm not sure if first was one of the goals. Given the number of platforms out there one would hope this would be the primary one, as I feel its a better community than FB in terms of content and structure. I read the thread on FB and things seemed to turn ugly quickly.  ?

Given that announcement , it's good to get an update on the project even though it is stalled and will have chip supply issues too. 

PS - His last here visit according to the forum SW was Oct 24th, so perhaps this is appropriate:

 

David's never been an active participant in this forum. I think it is safe to say that this forum was started by other team members. I'm glad this forum exists, but I don't think we can fault David for not making this his primary venue for sharing with the community.

Continuing upon my last post here.

Currently the PS/2 data and clock lines of the keyboard (and mouse?) are connected directly to VIA#1 PA0-1 and PB0-1, while VIA#2 is unused as far as I can tell.

Thoughts on pin usage:

• 
  The ATTINY 861 has 14 GPIO pins, and 3 of them are used for power control. That leaves us with 11 pins to handle keyboard and mouse
  


• 
  Of these, 4 pins are needed to connect the keyboard and mouse PS/2 lines. Now we have 7 pins left
  


• 
  That is clearly not pins enough to transfer one byte at a time from the ATTINY to the 65C22. Maybe you could manage to transfer one nibble at a time. But even nibble transfer requires control lines, like chip enable, data transfer direction (read/write), read/write handshake, and keyboard/mouse select.
  


• 
  If byte or nibble transfers are not possible, we are stuck with serial transfer. It's very similar to connecting the keyboard directly to the VIA, however, with the benefit of having precise control over how the ATTINY sends the data it has buffered.
  

Returning to @Kevin Williams's initial question in this thread: In order to write keyboard and mouse controller software for the ATTINY, there first needs to be a hardware design.