Commander X16

The ATTINY861 is just like any other IC in the series.  I switched from the ATTINY84 mostly because it had the leg count I want. ?  I'm using the ATTINY (arduino) core with the small bootloader.  I have a really old original STK500 I'm using to program it, although any old Atmel ISP programmer will work fine.  This IC is focused on automotive applications, as I recall,  but I'm just using it as a general purpose controller with I2C being the only weirdness.  It also has a way to generate a 16MHz clock internally, but it may be less stable.  I figure 8MHz may well be enough, but I thought it was nice to have as an option.  A programmer like this will work fine: USB AVR Programmer w/ 6-Pin 10-Pin IDC ISP Connector For USBASP | eBay

I also saw these: ATtiny 861 or 167 Development Board (assembled) from Azduino by Spence Konde on Tindie 

I can't vouch for them, I would just buy the dip IC and use it on a breadboard myself, but it could make it easy if you want a quickie and pretty cheap dev board for it.  

So there really should be two forks here. 

The first is for the 65c22 approach, which honestly, the only real input I can offer is testing on the real HW at this point.  The code is here: commanderx16/x16-rom (github.com)  I believe it's more up to date than the current emulator build, including some code I've tested which did sort of work at 8MHz.  This means the emulator needs to be updated at some point to match the new code-base as well.  Michael Steil is really the guy to ask here, I'll see what I can do to loop him in.   Honestly, don't know if the mouse code even exists yet in the kernal.

As far as the microcontroller goes, we should be able to test this for now with a second arduino running as an I2C master, and reading the fake IRQ.  Not as ideal, but getting the kernal to process this data is also a whole other matter.  I'd like to be able to validate the idea externally first.  

I know David is reading through the thread right now.  I'm going to chat with him a little later today and get back to you guys,

Thanks so much for the offer of assistance!  It is greatly appreciated.

-Kevin

@Kevin Williams

I made a quick test introducing a wait of about 15 us after clock low transition before the data line is sampled. At least that was my intention, but I have no means of testing it. It still works in the emulator.

Enclosed is the changed source file (kernal/drivers/x16/ps2.s and the compiled rom image.

The changes in the source file is on line 69 and on lines 105 and forward.


ps2.s
rom.bin

If the first attempt is not successful, you may try this that prolongs the initial wait for the keyboard from about 108 us to over 400 us. This also works in the emulator.


ps2.s
rom.bin

I also looked briefly at the code that handles SD card communication (dos/fat32/sdcard.s).

It's a bit banged SPI solution that depends on proper timing.

The necessary timing delays are measured in processor cycles, calculated on the assumption that the X16 runs at 8 MHz.

It would be surprising if the code worked properly if you run the computer at 4 or 2 MHz.

Before any other troubleshooting, it would be interesting to know how well the SD card communication works at 8 MHz. To test this you may first need the keyboard to work at that speed ?

I also looked briefly at the code that handles SD card communication (dos/fat32/sdcard.s).
It's a bit banged SPI solution that depends on proper timing.
The necessary timing delays are measured in processor cycles, calculated on the assumption that the X16 runs at 8 MHz.
It would be surprising if the code worked properly if you run the computer at 4 or 2 MHz.
Before any other troubleshooting, it would be interesting to know how well the SD card communication works at 8 MHz. To test this you may first need the keyboard to work at that speed [emoji846]

SPI has no strict timing requirements. It should work regardless of system speed.


Sent from my iPhone using Tapatalk

2 hours ago, Stefan said:

I also looked briefly at the code that handles SD card communication (dos/fat32/sdcard.s).



It's a bit banged SPI solution that depends on proper timing.



The necessary timing delays are measured in processor cycles, calculated on the assumption that the X16 runs at 8 MHz.



It would be surprising if the code worked properly if you run the computer at 4 or 2 MHz.



Before any other troubleshooting, it would be interesting to know how well the SD card communication works at 8 MHz. To test this you may first need the keyboard to work at that speed ?

I don't think that's quite right, unless I am looking at the wrong branch:

spi_write:
    sta SPI_DATA
@1:    bit SPI_CTRL
    bmi @1
    rts

That writes a byte to the SPI data register and then waits for the busy bit to clear. That looks like a complete hardware implementation. It would be nice to get a better description of what the SD failure mode is. Nicer still to hookup my protocol analyzer to the SD slot and probe traffic to see if the problem is the wire protocol or the hardware state machine.

Regardless, since the X16 is acting as SPI master, it has control of SCK. As long as it isn't driven faster than 25MHz (the guaranteed minimum speed supported in the SD spec), that should be fine. I've written SPI bit bang drivers for bootstrap code with an effective clock speed around 0.1 MHz and did not see an issue on any card tested. The one problem I did see was un-branded cards that did not correctly implement SPI in their hardware, but this was roughly 10 years ago - I'd like to think all SD card manufacturers have figured that out by now.

Are you mixing SD and PS2? The keyboard is a PS2 interface.

2 hours ago, Wavicle said:

I don't think that's quite right, unless I am looking at the wrong branch:



 

spi_write:
    sta SPI_DATA
@1:    bit SPI_CTRL
    bmi @1
    rts

 

Even though there is no timing dependent code in those lines, there is in other places within the module, for instance:

• 
  wait_ready, begins at line 40 
  


• 
  sdcard_init, begins at line 236
  

I haven't gone into the details of the SD card protocol. I haven't analyzed if the changed timing when the clock rate is reduced would be OK. I only said that the Kernal code clearly is written on the assumption that the computer runs at 8 MHz, and that it would be interesting to know if the problem is still there when the computer is run at that speed.

EDIT: Let me be clear about that I have no practical experience interfacing SD cards. Reading about the protocol in datasheets, I understand that there is no minimum clock frequency during normal communication. But during card initialization, you may not go below 100 kHz. When X16 is run at 2 MHz, 100 kHz corresponds to 20 processor cycles. It so happens that the spi_read function that is called several times during card initialization is a little more than 20 cycles. As I said, it would be interesting to know how well SD card communication works at 8 MHz...

2 hours ago, Stefan said:

Even though there is no timing dependent code in those lines, there is in other places within the module, for instance:

• 
  wait_ready, begins at line 40 
  


• 
  sdcard_init, begins at line 236
  

I haven't gone into the details of the SD card protocol. I haven't analyzed if the changed timing when the clock rate is reduced would be OK. I only said that the Kernal code clearly is written on the assumption that the computer runs at 8 MHz, and that it would be interesting to know if the problem is still there when the computer is run at that speed.



EDIT: Let me be clear about that I have no practical experience interfacing SD cards. Reading about the protocol in datasheets, I understand that there is no minimum clock frequency during normal communication. But during card initialization, you may not go below 100 kHz. When X16 is run at 2 MHz, 100 kHz corresponds to 20 processor cycles. It so happens that the spi_read function that is called several times during card initialization is a little more than 20 cycles. As I said, it would be interesting to know how well SD card communication works at 8 MHz...

This would probably be best taken to a new thread to avoid cluttering this one with non-PS/2 related discussion. VERA drives SCLK so the CPU frequency should have no impact. The 100-400khz SPI clock requirement is only during transfers; the clock may stop between transfers. (See section 4.4 Clock Control of the SD Physical Layer Simplified Spec)

I made a separate thread about the SD card issues, should anyone want to continue this discussion.


 

I started prototyping an implementation using an ATTINY85 that I have. After I had a circuit assembled, test programs written, and everything tested (Arduino UNO as I2C master, ATTINY85 as I2C slave and PS/2 host) I started looking to integrate it into the sketch attached here and noticed that the only thing done is initialization of the Wire library. (By funny coincidence, we selected the same I2C address - we may have read the same books in the 80s or something.) It doesn't look like there is any I2C receive/request handlers implemented. Is this correct? (Is this the current state of the sketch, or is this maybe an older version of the sketch?)