Commander X16

But I think what @StinkerB06 meant was to ask whether anything has changed regarding how you communicate with VERA… (any registers moved / changed, etc)

1 hour ago, ZeroByte said:

But I think what @StinkerB06 meant was to ask whether anything has changed regarding how you communicate with VERA… (any registers moved / changed, etc)

That, as well as additional features and changes to existing features, of the VERA architecture.

2 hours ago, StinkerB06 said:

That, as well as additional features and changes to existing features, of the VERA architecture.

Everyone of the team members (i.e., those in the position to know) I've seen posting to threads on that topic have been adamant (for months) that the feature set and architecture of VERA has been set in stone.    I'd say its unlikely there will be changes such as 'additional features and changes to existing features" for the VERA from the perspective of the end user, programmer, etc., on the X16.     

I think the most likely thing is that the hardware differences Kevin is referring to are likely something that will make the the existing announced architecture and specifications work better; or perhaps easier to implement on the hardware side; or maybe more robust or flexible -- all things that are 'under the hood' as they say.   That's my take.  

 

and there was much rejoicing! https://www.youtube.com/watch?v=yciX2meIkXI

Such a nice, clean looking board! Nice to see progress being made - I know the team has been hard at work, even when things aren't visible!

To be straight to the point, just tell me where and when to point my money and i would love to have a go at one of these beautiful machines!

David made an interesting update on Youtube today.

Apparently there is some kind of timing issue when reading the keyboard. It works reliably only when the board is operating av 2 MHz. David said it was probably "software" related, i.e. the Kernal's PS/2 driver.

AFAIA, the Kernal holds the PS/2 clock and data lines inactive most of the time.

When it's ready to receive data from the keyboard, the lines are released, and (I suppose) pulled high by a pull-up on the VIA pins. The Kernal then polls the state of the PS/2 lines for about 100 us. If the keyboard has not begun sending data within that period of time, the Kernal pulls the clock and data lines to the inactive state again, and continues with other chores.

The PS/2 protocol gives devices some leeway when it comes to timing. I haven't found any specification on how fast a device must start sending data after the clock and data lines are released by the host. It is only said that communication may not start before 50 us after the lines were released.

It is possible to let the Kernal wait longer for the keyboard to start sending data. The drawback is, of coarse, that this holds up the whole system. The current waiting period of about 100 us is 0.6 % of the vertical blank at 60 Hz. Multiplying the waiting time by four (corresponding to the transition from 8 MHz to 2 MHz) would make it 2.4 % of the vertical blank. That is still OK. To test if this actually solves the problem, you would only need to change the value "10" on line 56 in the file x16-rom/kernal/drivers/x16/ps2.s (Github master branch).

I look forward to follow the crew solving these last gremlins.

He also cited an intermittent issue with SD card access; also deemed a software issue.

These (timing) types of issues are dreadful to troubleshoot when the SW and HW ‘teams’ are not collocated.

 

Ugh.    Before they crack open the kernal (especially something that universally drags down timing of interrupts which can affect sprites, sound, etc) I hope they can get a 'Beneater' or "Curiousmarc" type to put it on an oscilloscope and conclusively eliminate any hardware issues.   

I'm trying to see how how, without doing so, one could  troubleshoot something like that unpredictably intermittent SD card thing they found and say as definitively as 8bitguy does that its for sure a software issue.   Wish I could see what the signals look like on a scope.   I wonder if its possible there's a little reflection somewhere such that the higher CPU speeds are impacting things.     I don't remember whether they've stated previously whether the keyboard would not work at full speed or not on a prior prototype, but that would be interesting to know.   Anyone recollect?  

Seems like a 16bit shift register that gets hooked to each PS/2 port long enough to shift in 11 bits would be useful… I know, no more silicon.