Jump to content

Kevin Williams

  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Kevin Williams

  1. 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.
  2. 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
  3. 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
  4. Hello everyone, I wanted to discuss an issue we have been struggling with, and that is PS/2 keyboard and mouse support. This is probably not a secret to anyone watching the videos on the X16 as most of the time we are running at 4MHz or 2MHz. This is completely due to PS/2 timing issues. I've spoken with Michael Steil about this issue many times and he has taken several approaches to get it to working stably. After adding the microcontroller to control the ATX power supply, I proposed the idea of adding a few more pins to also control the PS/2 ports. Like many in the community, he would perfer to get it working as it stands, so I proposed adding jumpers to select between the microcontroller, or the 65c22. So, I did just that on the third prototype. With tiny revisions, this will become our development board so it will give folks the option to try either approach. I initially thought about writing the code for the Arduino myself. I've messed around with Atmel microcontrollers going on 20 years now, but the truth is, I'm probably not the best one for this task. The code I wrote for the ATX power control is working, but I can't seem to get my reboot function to work for some reason.... Anyway, I digress, I guess the real reason I'm making this post is to ask for some help from the community! We are not committed to one approach or the other necessarily. IE, we are still planning to work on the 65c22 'bit-bang' approach (heck, we maybe could use some help here too), but alternately I wanted to start working on the microcontroller code to at least evaluate it before the final version of the board. If you're interested, here are some details wrt to how I have the HW setup on the current prototype. The attached pic shows U18, which is the ATTINY861 microcontroller. I really wanted to stick with no more than a 20 pin IC if possible, to make it look like it matches the board. This chip can run at 8 or 16MHz without an external crystal, but I gather the 16MHz mode may not be as stable. Not sure if this will be an issue later, but I wanted to mention it. I sort of just guessed the chip would be fast enough to handle both the mouse and the keyboard. There are certainly plenty of keyboard libraries out there, and at least one mouse library I'm aware of, but I'm not sure if they have ever been combined. I am running the microcontroller as an I2C device with the 6522 acting as the host to this IC. Right now, it is only listening for commands to power-off the system, reboot, reset, NMI & HDD LED control. I also hooked a line up to the 65C02 IRQ, so it could be polled. (Just as an FYI, the real-time clock is U10, which is read via I2C. J16 is the external I2C header to drive other devices if desired. J16 will also work as a 6-pin ISP header to program the ATTINY861. J6-J9 toggles the clock/data line for each PS/2 port from 65c22 to the ATTINY861.) In a nutshell, I'd like it to maintain the existing functions which should be taking next to nothing in terms of CPU, except maybe the I2C library. Integrate IRQ driven PS/2 mouse and keyboard routines and make the code as clean as possible for easy editing. If we do wind up going this route, your work could be part of the open-source library at the end of the rainbow for the system. Clearly, there will need to be some interaction on the kernal-side to process the data from these interrupts. This will take some coordination too, but I suspect the Arduino-side could be tested with another Arduino reading the data for the time being. Keep in mind, we could also wind up not using it too, just fair warning. Keep the responses on this thread for the time-being. I know this is a big ask, but I really want to make sure we have a nice solid library, so I decided it would be better to get a rock-star developer out there. Assembly is fine too, if you want to do it the hard way , but I suspect C will be fine. I also attached the code which is running on the proto for now. Please let me know if you have any questions, I'm looking forward to testing this out! Thanks! -Kevin X16_Power-current.zip
  5. Yes, that's how it's setup. I also have a seperate 2-pin header for NMI. The way I have the code in the microcontroller at the moment uses the reset pins on the header for both reset & NMI. Short push for NMI & long for reset. It works great, but takes a little getting used too, but I feel like if you're trying to hit NMI and reset instead by accident it would be worse. The screen blanks when you've pushed long enough for reset to happen, so it feels somewhat natural this way.
  6. 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
  7. While this is true, the reality is it's not working correctly. I'm not 100% sure why, but the VERA is not initializing correctly with the current kernal. Michael Steil is not a fan of the 816, so I'm guessing it won't be high on his priority list.
  8. The bus pins may be a little misleading as some of them have the 65C816 names labeled. I am debating on exactly how to label the board, or whether or not I should at all. Even though the system is designed to be a 65C02 based machine, I designed it such that a 65C816 will work electrically in the board. The Kernal isn't a fan of the 816, so it would have to be running a different OS, but we wanted to make sure people had the option to do what they wanted with the system. When I moved to the 60 pin slot, I had enough room to move nearly all of the CPU lines over. So long story short, I should probably label the board based on the 02 names, but I've been focused on making sure you can still plug in a 816 with no HW mods needed other than swapping the chip, and the code of course. The Audio lines are inputs which are sent to the audio mixer, left & right channel. I know it's unlikely there will be a need for more sound chips with the VERA and the YM2151, but I thought someone might want to add a SID, or maybe put the SAA1099 back on later, etc. It will just allow you to pump audio in from an expansion card. I moved the pins to line up with the actual layout of the CPU to simplify routing. It's the beauty of nothing being carved in-stone.... Yet.
  9. Hey Everyone, Sorry for the delay on an update. It's been a hectic year once again and there never seem to be enough hours in the day. I'm not a huge FB fan either, but the reality is with our business, it's pretty key I keep on top of FB & the even more dreaded Twitter. I meant to post the same day, but for the brief second I tried, the site wouldn't let me login, and I just forgot to come back. However, I just posted a video of Attack of the Petscii robots on the X16. It's still the second proto, but I have it wired as the third board is designed. I did this for testing the new design before running it of-course, and David just wanted to make sure the game was still running ok. I am catching up on the thread and I will answer some questions here in a second. For the moment, the PCBs are 100% complete and should be shipping tomorrow. This means probably Friday or Monday they will be here and I should have all of the parts in-hand too. We're still not done with the Kernal, so this is not the end of the story by any stretch, but it should be pretty close to the end of the HW specs. Attack of the PETSCII Robots on the Commander X16 Prototype 3 - YouTube Thanks, -Kevin
  10. Hey Everyone, I just made a new video showing some updates on the Commander X16 second Prototype. I've been working on a few modifications, and getting them incorporated into a daughter-board. The board was updated, and sent over to Michael Steil to work on the kernal. At this point, he should have what will be pretty close to the final HW. I cover a few topics, so please take a look if you have a second and thanks for taking the time. Take care, -Kevin https://youtu.be/T5vjnBYGp2w
  11. It will cost more, but the vision of the first step is through-hole and easy to understand. Later versions will be surface mount and cost reduced.
  12. Hi Everyone, If you happened to see David's video on the Color Maximite 2, then you probably noticed that the new Commander X16 PCBs have arrived! David @The 8-Bit Guy just happened to swing by my house the day they arrived, and he picked them up before I was even able to get all of the parts in. I am still waiting on a few things, so I haven't been able to complete assembly yet. The VERA is also not complete for this reason, but I had to mock it up for the pics! Bear in mind, this is not the correct case, this is from an old tower ATX case I had sitting around. It's a nice platform to mount the board and make sure I have the placement of screws, slots & of course the rear ATX panel aligned correctly. I will likely make a few placement tweaks but overall I am quite happy with the physical layout so I just had to post some photos! So far, it's working but my ATX soft-start circuit is a bit squirrelly. Not only that, I kinda wired it wrong and didn't catch it before the run. Worked great on the breadboard, but I will have to revamp that before the final. There are also a few other little things discovered since this proto was run, but the real tests will be coming when @Michael Steil is able to get the Kernal up and running. (I would write some test code, but one part I'm missing is the ZIF socket for the ROM. Should be here in a day or two.) @Perifractic is also sending me the X16 case, so I should be able to install the board in there later this week. Happy Sunday, and Take Care Everyone! -Kevin Williams https://TexElec.com
  13. Hi again! I've been working for quite awhile to get the new layout complete, and I think we are just about ready to run the second prototype! There are quite a number of changes to this board over the previous version, so I do expect a few, ahem, challenges perhaps? That said, a lot of time has been spent testing on breadboards and optimizing so I think we should be close to the final specs on this system. As mentioned, there are code breaking changes with the system. I will post more for the devs out there in a post below. The VERA has also changed quite a bit. Namely, it now has 32 registers, but I'll let @Frank van den Hoef talk more about that when he is ready to post some updates. Also, I made two proto boards to test the bus and get the alignment right for the final design. Progress is being made, thanks for everyone's patience and have a great day!
  14. Hello Everyone! I know it's been awhile since there has been an update, so here goes: Earlier this year I had mostly completed the "Proto #2" motherboard. It was a mad dash to get the PCB made before we met in New Jersey at VCF. Right at the end, @Frank van den Hoef made a pretty substantial change to the VERA, which required a bit of reworking. April came, the trip was cancelled and life went sideways for a bit for the world. As such, I decided I needed to focus on a few things for TexElec, and took a bit of time off from the project. Last month I picked up where I left off and planned to make minor changes for the VERA and get the PCB made. However, the team had some time to think and oversights and optimizations became apparent. One change led to another, and let's just say, we're gonna break some code. Sorry. I do believe the changes made will not disappoint. I'm not going to reveal them just yet. I am still laying out the PCB and would like to do some testing to make sure it's going to work as designed. I am trying not to release too much of the schematic until the end, as anything is subject to change at this point. The pic below is how I have the expansion bus pinned out. I may well move some the pins around to simplify layout, so again, not in stone yet, but I do think this is pretty close to what pins will be present. This post is majorly TLDR already, so I'll add a comment below with more info on the pins, and the idea behind some of it. Take care!
  • Create New...

Important Information

Please review our Terms of Use