Jump to content

Prototype #3 - Parts have arrived and the first one has been built!


Recommended Posts

Hello Everyone!

  I received the parts for the third Prototype on Tuesday evening and spent a good chunk of that night and a bit of yesterday morning getting it worked out.  I had to get my code moved over to the ATTiny861 before the board would even power on.    This turned out to be pretty easy now that the I2C header will also work as an Atmel ISP programming header.  Of course, I'm pretty much going to make a mistake somewhere on a board of this size, and this time is no exception!  Fortunately, they were easy to spot and the actual logic is working as it should.  Or at least as I designed it. 🙂  Two of my mistakes are visible in the pic, see if you can find them.  One is just cosmetic, and the other is a bodge job on a chip which I will admit, is next to impossible to see in this photo. 
  The less easy to spot issue is that I used the stand-by power to power the microcontroller, but I put pull-up resistors on the I2C lines (and SPI programming lines) to the system voltage and not the VSB.  I did this on purpose as I didn't want to pull these lines high while programming the microcontroller, but need to pull them high for I2C.  The net result is that leakage was happening backwards through these resistors when the data/clock lines were high.  Enough to power on the LED on the motherboard with no other ICs plugged in.  Took me a minute to figure that one out, but I think I will just throw a few more diodes in to protect this from happening.  I suspect issues like this are sometimes why you may see a lone crusty resistor on an old PCB after years of use. 

Easy fixes all around!  One last issue is that the parts sourcing scourge which has been affecting the world is also affecting TexElec!  Yes, we can't get parts in for some of our products, and as time goes on, it seems like it may get worse before it gets better.  And now, it has hit the X16 project!  I am unable to get the FPGA and the DAC for the new Version 4 VERA, so we're still running V3.  The main difference has to do with hardware deadlocks on the SD card, so functionally, it's fine.  However, the lead times are a bit concerning.  I'm looking into some other suppliers now, and hoping for the best.

For now, here's a pic of the new machine, with no wires all over it!

Take care!
-Kevin

X16- Proto 3.jpg

  • Like 31
  • Thanks 4
Link to comment
Share on other sites

THANK YOU Kevin for the update!   Even when there's not much to say, updates are a heartbeat, you know? 

And then there's these BIG updates which are just plain interesting, and as ZeroByte said, exciting even.

 

The hardware shortage "only getting worse" sounds ominous... but I suppose that ought to simply be taken and used as an opportunity to examine the system as it is and think about it.

 

  • Like 1
Link to comment
Share on other sites

Awesome!    Kevin, I'd say not to hesitate to lean on the community too:    If you have a particular list of things you need (FPGA etc) to get proto stuff done, post a list and let folks see what they've got (or can leverage connections to get).   Obviously it won't be the endgame supply chain, but if you need something (e.g., to get VERA4 onboard and rocking) it could be the hive mind might be in a position to help.    

As for myself, er... well, I've got a big bag of blue LEDs somewhere around here.    🤪        

In all seriousness, thanks to you and everyone on the team for plowing through all the things with COVID, the global supply chain weirdness and the online bikeshed factory to get things so this far.   Can't wait for the next steps!

  • Like 2
Link to comment
Share on other sites

Wow. I get more excited every time I see one of Kevin’s posts.

The parts availability thing has me worried, though. I know it will only be a matter of time before suppliers catch up on the FPGA and other parts that are in short supply, but it’s frustrating to see this happening right now and being unable to do anything about it. (Of course, I can’t buy an NVidia RTX 3080 for love or money, either, so….)

 

 

  • Like 1
Link to comment
Share on other sites

2 hours ago, TomXP411 said:

Wow. I get more excited every time I see one of Kevin’s posts.

The parts availability thing has me worried, though. I know it will only be a matter of time before suppliers catch up on the FPGA and other parts that are in short supply, but it’s frustrating to see this happening right now and being unable to do anything about it. (Of course, I can’t buy an NVidia RTX 3080 for love or money, either, so….)

I work for a government contractor. I'm a software guy, but we do plenty of specialized hardware in relatively low volume. Just chiming in with "hardware shortages in the supply chain are real" ... I think I can safely say that much without getting in trouble.

Link to comment
Share on other sites

Quote

Is the specification of the V4 VERA the same as before?

 

Yeah.  The only apparent reason for a different FPGA for VERA is for more RAM cache in the fabric for more VIDEO RAM and more colors in high resolution modes, and possibly scrolling registers on the bitmap.

Edited by Kalvan
Add Quote
Link to comment
Share on other sites

59 minutes ago, Kalvan said:

The only apparent reason for a different FPGA for VERA is for more RAM cache in the fabric for more VIDEO RAM and more colors in high resolution modes, and possibly scrolling registers on the bitmap.

... or pricing concerns, or electronic concerns with how it works on the PCB, or with the clock, or one of a dozen other things. I'm sure it's not because they're going to crank it up to being a Neo Geo.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.  

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?  

Link to comment
Share on other sites

Not only was the PS/2 ports in the PS/2 computer read and written to by a microcontroller, the IBM-AT predecessor to the PS/2 was. My inclination would be to go truly retro and access the ports the way they were originally accessed back in the 80s.

Now, AFAIU, the Intel part that they used back then is no longer in production, but 8bit microcontrollers that can do the task are, so go with that.

I am NOT saying this JUST to free up more GPIO pins in the VIAs ... oh no! But if it DOES free up more GPIO, that would be cool too.

Edited by BruceMcF
  • Like 2
Link to comment
Share on other sites

28 minutes ago, BruceMcF said:

Not only was the PS/2 ports in the PS/2 computer read and written to by a microcontroller, the IBM-AT predecessor to the PS/2 was. My inclination would be to go truly retro and access the ports the way they were originally accessed back in the 80s.

Now, AFAIU, the Intel part that they used back then is no longer in production, but 8bit microcontrollers that can do the task are, so go with that.

I am NOT saying this JUST to free up more GPIO pins in the VIAs ... oh no! But if it DOES free up more GPIO, that would be cool too.

Yeah, if we already have an MCU working the power circuit, maybe a larger chip with more GPIO pins could be used to read the keyboard and mouse. 

I'm a little worried about the "the keyboard only works at 2MHz" thing going on right now. Designing the I/O subsystems so that they are clock speed dependent is a bad idea...

 

  • Like 1
Link to comment
Share on other sites

I remember @Lorin Millsap said some months ago, that the current Kernal function for reading the keyboard would not be the one to be used in the final product.

On Github, there is the "ps2-nmi" branch last updated at the end of April. I haven't analyzed the code, but it seems to be an interrupt based solution instead of the polling method used in the current master branch.

 

Link to comment
Share on other sites

I remember [mention=28]Lorin Millsap[/mention] said some months ago, that the current Kernal function for reading the keyboard would not be the one to be used in the final product.
On Github, there is the "ps2-nmi" branch last updated at the end of April. I haven't analyzed the code, but it seems to be an interrupt based solution instead of the polling method used in the current master branch.
 

I’m certainly not an expert on the code. But what seems to be happening is the PS/2 code that was used was written in a poll type interface. PS/2 was meant to be interrupt driven. Because the code is Polk based it inhibits keyboard communication except when it wants to. On a CPU cycle limited system like a VIC20 or C64 where you need to read things within a narrow window of time that works fine. And on our system this is still somewhat the case, except it needs to to be implemented differently. Holding the click line to inhibit communication is not the problem. The problem is the code essentially hits a timeout, and if the keyboard hasn’t started transmitting by the time the code times out, then it misses the data. When it’s run at lower speeds this works fine, but when the CPU speed gets increased then it times out faster. I thought Frank wrote some new code that worked better, but apparently it never got merged in.


Sent from my iPhone using Tapatalk
Link to comment
Share on other sites

Thanks @Lorin Millsap!

I looked at and calculated the wait loop on lines 55-60 in the file x16-rom/kernal/drivers/x16/ps2.s (Github master branch) once more.

AFAIU:

  • The loop setup on lines 55-56 is 4 cycles. The loop counter (Y) is set to 80.
  • Each loop (lines 57-60) takes 11 cycles. The test for a start condition happens 4 cycles into the loop.
  • The loop will check for a start condition 79 times
  • The last check will happen 4 + 78*11 + 4 = 866 cycles after the I2C lines were released
  • 866 cycles @ 8 MHz processor speed is about 108 us. @ 2 MHz it's about 433 us. If the keyboard hasn't started to transfer data within that time, the PS/2 lines are made inactive again.
  • As far as I can see, there are no other parts of the Kernal PS/2 code that has a similar timeout. If receiving a start condition, the code will wait (indefinitely) for the keyboard to finish transmission.
  • Instead of lowering the processor speed, you could increase the value of the loop counter on line 56. If the counter is set to it's maximum value of 255, the timeout will happen after 349 us.
  • If that's not enough, you could add one ore more NOPs to the loop for testing purposes. One NOP at the beginning of the loop would increase the wait to about 414 us if the loop counter is set to 255.
  • Like 3
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use