Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 04/26/20 in all areas

  1. 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
    35 points
  2. I spent some time the last few days converting Petscii Robots over to the X16. It's now more or less fully functional. Well, you can play the game from beginning to end, anyway.. But it still lacks sound, and it is using the default font, which I hope to change soon to the PET font, which will make it look nicer. It also lacks a lot of effects like screen-shake, EMP flash, etc. I'll be working to add those in over the next few days. Also, since the game is designed for 40x25 screen, there is some black area at the bottom. That being said, once I get this version completed, I'll slowly begin the transition to a custom graphic version for the X16 as originally promised, which should fill the whole screen.
    32 points
  3. The current "master" branches of the x16-rom, x16-emulator and x16-docs repositories now correspond to the "Proto #2" hardware, which is incompatible with the "Proto #1". banking is now done though zero page addresses 0 and 1 instead of VIA GPIOs the I/O area at $9F00-$9FFF has changed in layout (except VERA) the layout of the VIA GPIOs has changed 4 SNES controllers are supported there is now a real-time-clock – but it is not yet supported by the emulator or ROM If you have software that does manual banking or accesses I/O devices (other than VERA) manually, you will need to update it in order to be compatible with the next emulator/ROM release (r39) as well as real hardware. The Programmer's Reference Guide should have all the necessary information. Please file bugs on GitHub if you find any issues. Thanks!
    29 points
  4. Just a little tease for all you loyal Commandos of how the machine is looking in the user guide illustrations:
    28 points
  5. 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
    27 points
  6. So, I'm just going to answer a few more concerns about the X8. One person said I was clearly in favor of this, or something to that effect. Well, I made that clear at the beginning. I wanted to release it 6 months ago. I haven't tried to cover that up. Several people seemed concerned about how much money I was going to make from this project and how the X8 might reduce that. I know I have said this before, but I'll say it again. This project was NEVER about money for me. In fact, I've made it clear many times that I never intended to profit from this project at all. All profits made from the X16 would be split between Kevin, Frank, Michael, Perifractic, and a few other people. I have told the entire time many times I didn't want anything. I'd rather my "profit" be sacrificed to help reduce the cost of the system. My main goal was to have my dream computer, and that other people would have it too. Now, if it ends up selling millions of units, ok, we'll re-visit that conversation. But that's not likely. I haven't released the emulator for the obvious reason that if this product is to be buried and never see the light of day, I'd rather the emulator just not be out there. So we'll release that if it is decided to go forward with it. I suppose I could find some time next week to port Petscii Robots to the X8 for demonstration, since some people were asking about that. It shouldn't take long. Petscii Robots doesn't use any banked RAM. After all, it was originally designed for a computer with 32K. However, I was going to be using banked RAM for the new soundtrack eventually. But at the same time, having access to the SD card can compensate for that. I could load each song in as needed, for example, rather than storing them all in RAM at once. Some people seem confused on why I'm in favor of releasing this. So I'm going to open up and totally lay it out here. This is my honest opinion on that matter: The X16 has taken much longer to bring to market that I thought. There were many times where development was halted for 6 months or more because of unsolvable bugs. And even though we are close to being able to release a kit fo the X16, it's going to still take more time to get this out the door and the people wanting fully assembled systems will be waiting extra time. The X16 is definitely happening. The X8 is not meant as a replacement for it. But, I felt like the X8 with it's super-low price-tag and easy manufacturing could help keep interest in the project much like "The C64 Mini" did, even though everyone was wanting a full-sized machine. This would keep development on-going, and most anything made for the X8 could easily be ported to the X16 later. I do not believe X8 sales will cannibalize X16p sales. And sales of the X8 could even help to fund more development on the X16 surface-mount version and eventual X8-FPGA version. And for those people that don't want an X8, it seems like the solution is simple. Just don't buy one. Buy the X16p instead. Or wait for phase-2, or whatever.
    22 points
  7. Please enjoy this mini update from @Kevin Williams about the second prototype. A fuller update will follow from David on YouTube soon (when we have a working prototype #3). Happy new year Commandos!
    22 points
  8. Hello Commandos! Here’s an update video all about the latest visual design aspects of the Commander X16. Regulars here will know some of this already but I hope you still enjoy it Your friend in retro, Perifractic
    21 points
  9. Very small update for you guys. First prototype PS/2 mini keyboard is in. Note: This is not representative of our colour scheme or keycap artwork. They used a default artwork but we'll be able to get more specific once the crowdfunding starts. But the goal of this prototype is to test the new more ergonomic raised up keycaps and overall feel and design. You may remember our early prototype keys were flatter, more laptop like, and less nice to type on. This feels REALLY good to type on, especially for a good value non-microswitch keyboard. Can't wait for you guys to be able to hold it in your hands. Well... under your fingers... You know what I mean. (And of course the deluxe microswitch keyboard made and sold by WASD remains an option for the most selective of keyboard connoisseurs: http://commanderx16.com/deluxekeyboard ) More updates soon! Your friend in retro, Perifractic
    20 points
  10. I work with a bespoke SFF case manufacturer. There's no minimum order, the cases are manufactured ad-hoc. The case could be designed from scratch around the X16 and supplied in kit form or fully assembled. Right at the start, before you announced the official case, we were looking at offering our own product to go with the X16. I'd love to work with you and produce an official case, or if you don't want the hassle of managing a new case project maybe we could just produce our own complimentary product? Hope this post doesn't get lost in the noise, please drop me a PM.
    19 points
  11. Why we’re renaming the X16: Perifractic, X16 Visual Designer
    19 points
  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
    18 points
  13. I figured it’s been a while since the last update. So I’m just letting you know where things are at. Kevin has sent me one of the prototype boards in the hopes that we can figure out why certain parts are not working. Timing on the ROM and RAM is stable, the two VIA chips are also stable. There is some odd behavior on the banking latches, and the audio and video are not working. We are certain it’s a timing issue and we will let you all know when that issue is resolved. By sending me a proto board the hope is that we have a second set of eyes since trying to debug it over email and phone calls isn’t very productive.
    18 points
  14. Hi all, I started developing a game for the X16 last September - coming up on a year ago now! I come from same the 1980s 8-bit BASIC programming vintage as Director-in-Chief Murray and probably most of you lot too, but I've never developed a whole game before. The X16 project has inspired me to learn assembly, with the goal of writing this game. More than a whiff of nostalgia about it all too - fond memories of passing POKEs to schoolmates to get infinite lives in Manic Miner and Jet Set Willy. Loosely, my game is a turn-based strategy/resource management thing with a passing resemblance to the hex-based board game settlers of catan. But the resemblance is only skin deep - this game has a strong story-based adventuring/survival/exploration leaning, all mixed together and served up with a hearty dose of good old fashioned text adventure. Blimey, I'll tell you what - it's been a steep curve. Simultaneously learning assembly; learning the vera / X16 hardware whilst developing how the game is going to work: combat systems - resource / asset / fatigue management - display; writing the code ; creating the graphics; writing the prose. It turns out taking on a game (even an 8-bit style game) single-handedly is a HUGE undertaking. I doff my hat to @SlithyMatt - you sir are a legend I've no idea how you churn out the code with such amazing regularity!! But the great thing about the X16 is - IT CAN BE DONE. It might take ages, but if I can do it, anyone can! It's been a long time coming, but I've got to the stage now where I've finalised the gameplay, memory management, and the overarching story of the game. I've also battered my head against my assembly inadequacies sufficiently (with lots of help from proper programmers - again, hat tip to @SlithyMatt , @StephenHorn, @Greg King , @togster510 and others - sorry if I've missed you out!) such that the code for the main game loop is now (pretty much!) in place. Things I've learned so far: 1. Planning everything out on paper before starting to code ABSOLUTELY VITAL! I was keen to get into the 'interesting stuff' straight away (drawing the graphics, putting things on screen) but in the long run, having the whole game pretty much drawn out in principle on paper first meant I've avoided a number of unpleasantries in the coding thereof. How are you going to address the screen - one layer? two layers? What is going onto each layer? How many bpp will you need for each layer? How many sprites will you need? How many frames of animation? How much vram will all that take? How are you going to encode the various aspects of gameplay? Which memory banks are you going to put them in? Which leads me onto - 2. Plan out your memory management. The X16 only has 40k of low memory + 64 x 8k memory banks to play with (in the base model) plus 128kB of video memory, so you can't just splurge on huge 256 colour graphics all over the place - the limitations of the system require some thought on how much you're going to fit in, and how you're going to fit it in. I've used up three memory banks just storing the hex tiles for the whole game board (64 x 64 hexes in total, although not all visible on screen at once) - made up of 32 different types of hex terrain, each with its own individual replenishing resources, roads, rivers and bridges. 3. Assembly is HARD but not IMPOSSIBLE. I've lost count the number of times my eyes have glazed over whilst looking at what I've lda'd and what I've sta'd wondering why the hell it doesn't do what I've CLEARLY just told it to do... persevere, and post questions on the software support forum. There are kind people out there who will help you (me included, if it's within my power to do so!!) 4. You will probably end up writing programs that help you write your program. This one was a bit of a surprise for me - but I've done it twice so far already. For example, I wrote a bitmap converter that loads up 16x16 pixel .bmp graphic files I've drawn in photoshop, and it spews them into memory as four sequential 8x8 tiles for storing in the vram tile map (my graphics are 16x16 but they need to be placed on an 8x8 tile grid because of how the hexes work). It took me an afternoon to write but it would have been immensely complicated and taken a LOT longer to hand-convert every terrain and item graphic in a hex-editor! 5. Things change. Roll with the punches. If the gameplay has to change slightly to fit within the limitations, so be it. The people playing the finished game aren't bothered about what you thought the game was going to be like. Deciding on the layout of the main screen was a hassle for me - there's more stuff I wanted to show than there was room for, and I tried various ways of cramming it all in, whilst still getting it to look attractive. Eventually I decided I couldn't do it, so I've split the information across two screens that can be toggled between. The main screen now shows a bar that fills up as the amount of stuff you're carrying increases. A handful of grain fills up one backpack 'slot'; an apple fills up 3, and one load of stone fills 16 slots etc. so you have to be careful about choosing what to carry around with you. But you can toggle to the backpack screen that itemises all the resources and equipment you're carrying so you know for example how many apples you've got and how much stone you're carrying etc. I should add this game is a bit of a nod towards the now legendary Planet X2 - if you've got half an hour spare, David's 'making of' video https://www.youtube.com/watch?v=NB_VBl7ut9Y is really helpful and has some great tips particularly about memory management - it's aimed specifically at the C64, but a lot of it is pertinent to the X16 too. I hope this is of some help for others considering embarking on a similar coding journey. At the very least, I'm writing all this down now in the hope that you lovely X16 people will hold me to account and spur me on to actually finish writing this blasted game..! The hexes await... in the meantime, have a peek at the notes in the photos below, it'll give you a flavour of what kind of things are included in the game. Also a screenshot of how the game currently looks. Ta ta for now!
    18 points
  15. Version 1.0.0

    2397 downloads

    This is a shareware version of Petscii Robots. It only includes 2 maps. It also lacks SNES controls and the cheat-code. It is also only presented in "color PETSCII" mode, as there hasn't been a version made yet with custom graphics and sound. The music routine is a direct port from the PET, which only uses 1 square-wave voice. PETFONT.PRG
    17 points
  16. We're not posting an official update until we have something more conclusive but just to put rest to this conversation and any speculation here, we have had some fantastic successes very recently and the machine is all but fully working. Just a few little tweaks to fix. So things are looking really great and will have a full update for you very very soon. [emoji4]
    17 points
  17. Just some further updates. I have finished the assembly of the board along with the patches that Kevin has documented. It’s not working yet, and my schedule has been very full this week. I’ve ordered some parts I need to build a test rig, and I have a logic analyzer that I just got. So not much to report yet. But just in summary my test rig lets me get to the very basics and monitor and control many parts of the system. Sent from my iPhone using Tapatalk
    17 points
  18. For me, the Commander X16 has always been about education. You can look at it and see how it works. The parts are not abstract concepts implemented inside an FPGA. They are physical chips with datasheets connected by higher level block and circuit diagrams. I want the Commander X16 to be my 6 year old daughter's first computer. I've never given her a tablet or a video game console. I want her to understand what a computer is. I want her to see a computer with all its parts exposed. A kit will give her this. An FPGA will not.
    16 points
  19. David has finished the port and here it is running on the X16 prototype! Perifractic, X16 Visual Designer http://youtube.com/perifractic
    16 points
  20. Hi all, I've spent that much time rummaging through documentation for vera trying to find how to set things up and which blasted $9f!*'@! did what, I thought I'd make myself a crib sheet with all the info on a single page (well, most of it!). I've attached a .png and a .pdf here for anyone to download and use if you want. I'm working exclusively in tile mode at the moment, so this crib sheet only covers that - I might do another one for bitmap mode when I start trying that. Hope it's useful to someone else! vera register info sheet.pdf
    16 points
  21. 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!
    16 points
  22. Hello all, My name is Frank van den Hoef and I am responsible for the design of the VERA module (the audio, video and storage hardware module), which is part of the Commander X16.
    15 points
  23. Hello fellow Commandos! In my exciting new role as a fan and forum member I've seen many requests directed at @The 8-Bit Guy asking for info about the Phase 1, X16P case, which he has decided to retire so as to simplify the project. Firstly although I was a fan of the case (pun intended) I respect David's decision. The X16 has always been his baby and we're just along for the ride. To be clear, he has stated the Phase 1 official case is now in the past. Having chatted with David about the questions about the case we agreed it's a good idea for me to present this thread as an unofficial FAQ of sorts, to answer those questions, so the community has access to the same info I had. I'd never want to feel I was withholding useful info as I continue my step back. So in no particular order: Will there be a "vendor badge" sticker / stick-on badge available? I shared all assets with the team as part of my handover, so everything is available to them including logos and badge designs. I think it would be wise to give the team at least a few days (or weeks) to adjust to the team member changes. I think if you can be patient, some well formed options will come to light. For any badges I recommend Marco van de Meulenhof aka BadgeMan. Can we have the case designs to 3D print? Sadly not, mainly as I don't have them. As stated from the start, the case was a modified existing design and I chose this path to cut the end user cost by a total of about $100,000 compared to designing and tooling our own case & keyboard. This means the X16 project does not have full ownership of the design which partly belongs to Sohoo. Standard copyright law applies. Also the X16 project signed a standard confidentiality agreement with them. They own the design starting point and will not license iterations. They also never released their own design files to us. The renders you’ve seen like the above were made by Mat Recardo & I, and are visuals only based on my own changes (see below). There's no internal structure for mounting and it's not exact size. Refining that for 3D printing would be a huge task, and that’s if the project had the rights to do so, which it does not. If providing 3D print plans for the case were an easy possibility I would have made sure that was done for you guys a few days ago. I thought long and hard about the options. Unfortunately I had to conclude that it’s a bit of a minefield. Well give us the model number and we'll model it for 3D printing anyway! The model number is public knowledge, available on Google, and this is the link to the manufacturer's case info page. However, again, the X16 project cannot legally condone or encourage recreating or cloning another party's intellectual property. To do so may jeopardise the X16 project. Other important points to keep in mind: Any price you see quoted on Chinese websites will always increase hugely, and excludes the PSU and modifications. The last unmodified single unit I ordered from the manufacturer as a testing sample cost me $139.75 landed - paid by wire only (keep in mind the factory have no PayPal, no store, etc.) despite what you may see online. Some of my mods included the plastic colour, plastic texture, steel texture, removing DVD tray, removing eject button, screen printing 8-Bit logo, butterfly logo badge engraving, 2nd badge creation, button changes, and more. Structural changes inside also. Oh and team autographs were to be embossed inside. Perifractic I actually replaced the front panel with a whole new design. The reason is the standard one is designed for modern vertical use and has a big hole (release handle) on one edge. You cannot remove holes in injection moulds, you can only add holes. The hole is largely hidden at the bottom in the vertical photos but looks ghastly on the left side when laid horizontally to suit retro aesthetics. You can see the wires and columns through it. I'd never have wanted to release a product like that. It’s only fair I warn you about that hole in the Sohoo case (don't fall into it!). But yes, the above linked case was the starting point 2 years ago. New front panel design: Perifractic To help with realistic expectations, if acquiring one unmodified unit at $140, the photo below is about best one could get it to appear without colour and texture mods, and all the other changes. Obviously the retail product would've looked hugely better: Would it be possible to get the case later as separate purchase? No. The only real way to get that case as depicted is for the team to follow the normal practice and order 1000 units at a price I negotiated down to about $32/unit inc. PSU & box, and I had to fight hard to stop that going up to 2000 units minimum with COVID. My plan was for that to be achieved via crowdfunding at this website. But again I certainly understand the appeal of simplifying the project in light of other complications and concerns re parts and order assembly etc. and fully respect the change of direction, as should we all. I believe this case is no longer an option. What about a different 3D printed case design? In my experience the case is too large for 3D printers and would need to be printed in 2 or 4 sections then clipped/glued together. A line could be factored into the design to make that less unattractive. David has said 3D printing of that size is cost prohibitive so I'm guessing it's unlikely that would be offered directly by the team as an option. How about making a case design available at Protocase or similar? This would be up to the team and community. I had liaised with similar companies before and they actually rejected the project due to some of its specific needs, which always surprised me. Anyone is free to upload their designs anywhere and make them available. What is the form factor? The case is a standard Micro ATX "Slim" model, and can house a Micro ATX or Mini ITX motherboard. At the time of writing the X16P motherboard is Micro ATX, and at the time of writing should fit in any Micro ATX case. The team will hopefully update this should that change (unlikely). What about cases for the other phases? The modified case designs for these are all on file with the team and they have my permission to use them. The same basic copyright situation applies as above re the manufacturer base designs. Rotate__[000-150].mp4 X16C/Mat Recardo/Perifractic X16E/X8/Arne/Perifractic As I conclude my one week handover, I truly hope this extra info and clarity is useful to the community going forward! Your friend in retro, Perifractic http://youtube.com/perifractic | http://patreon.com/perifractic
    15 points
  24. I want a development system. Shut up and take my money. PM me as soon as you have one available to ship.
    15 points
  25. Latest video from the 8-Bit Guy includes a small X16 update and demonstration at the end.
    15 points
  26. In this recent video I showed a first prototype of the X16's mini keyboard. As we edge closer to crowdfunding later this year, today we ordered final keyboard prototype samples with the PETSCII layout and X16 logo on. Can't wait to try them out and show you guys more!
    15 points
  27. Attack of the Petscii Robots (Shareware) View File This is a shareware version of Petscii Robots. It only includes 2 maps. It also lacks SNES controls and the cheat-code. It is also only presented in "color PETSCII" mode, as there hasn't been a version made yet with custom graphics and sound. The music routine is a direct port from the PET, which only uses 1 square-wave voice. PETFONT.PRG Submitter The 8-Bit Guy Submitted 03/04/21 Category Games  
    15 points
  28. The X8 is a somewhat cut-down X16 that exists entirely in FPGA. It has much less RAM. It does use the VERA, albeit with reduced VRAM. I have one of the few prototypes in existence on my desk. It is a concept we have toyed with and may or may not release at some point after the X16 launches. The core team is somewhat divided over whether or not it is a good idea as it does somewhat compete with "stage 3" of the X16.
    15 points
  29. I’m not posting this as an official update announcement as it’s not finished but wanted to whet your appetites. Also big shoutout to @Michael Steil and @Frank van den Hoef. Frank wrote the main driver which was way faster and more complete than the old one and Micheal extended its functionality. The next emulator release has major improvements to the DOS for the SD card filesystem. The main ones are: A lot of progress has been made with the X16 DOS. It's almost feature complete, and almost has feature parity with CMD floppy and hard drives. • Long filename support • You can open files for reading (OPEN2,8,2,"FILE") or for writing (OPEN2,8,2,"FILE,P,W"), read and write data, have four of them open at the same time, etc. etc. • Overwriting files is done with "@:". • You can copy files (DOS"C:BACKUP=ORIGINAL"), concatenate files (DOS"C:ALL=FILE*"), all with wildcards. • You can rename files (DOS"C:NEW=OLD"). • You can delete files (DOS"S:R*,Q*"). • You can lock/unlock files (DOS"L:R*" or DOS"F-L:R*"/DOS"F-U:R*"). • Like on CMD devices, create directories (DOS"MD:DIR), delete them (DOS"RD:DIR), change them (DOS"CD:DIR). • You can use paths everywhere (DOS"C//BACKUP/:FILE.TXT=FILE.TXT", DOS"$//BACKUP/:A*") • All commands and paths support drive/media numbers (DOS"$1:*"), but only 0 (current) and 1 (only supported partition) work. • You can get partitioning info (DOS"GP"+CHR$(1)) like on CMD hard disks. • You can even read/write DOS memory and execute code in a DOS context (M-R, M-W, M-E). Yeah, not that useful. • All error messages on the status channel (just type "DOS") are consistent with 1541/1571/CMD drives, e.g. 01, FILES SCRATCHED,05,00 etc. What's missing: • Open file for appending (,P,A). • Show/change disk name. • mkfs (N) • fsck (`V') • timestamp support What's missing that I'm not sure should be added: • REL files • block read/write API Sent from my iPhone using Tapatalk
    15 points
  30. I just wanted to chime in about the costs and confusion on the X8. First and foremost, it is really hard to narrow down a cost structure with the crazy chip market at the moment. Hopefully that is a temporary problem. So let me tell you where we would be if the chip market were the same as two years ago. The X8 could be available immediately and be well under $50. I'm not sure how far under $50. I'd say as low as $25 and as high as $50. The Phase 1 system sold as a DYI kit could be well under $300. Maybe under $250. Add another $100 to $150 for a pre-assembled kit. Again, you can't hold me to these numbers because so many things are unknown right now with the cost of chips. But that hopefully puts things in a ballpark for people trying to figure this out. For those trying to figure out what the advantage would be of an X8 versus what is envisioned for the X16 Phase-3 (known as the X16e). Well, the X8 would still be half the price. For example, the X8 might be $35 and the X16e would be like $70. There is simply no way to ever produce an FPGA based X16 as cheaply as the X8 can be produced. And the X8 brings with it most of the functionality and personality of the X16. And it's not an emulator. So, there's that. And there's another more depressing matter to consider. If the X16 doesn't sell well enough to recoup some of the costs we've plunged into it, the X16e will never see the light of day. Where as the X8 could start sales very quickly and actually help fund the entire project. So there's that too.
    14 points
  31. I think your worries about the X8 diluting interest in the X16 are valid. I'd rather development be focused more on one product (the X16) rather than two. It would probably save you a bit of sanity anyways since money and time is tight.
    14 points
  32. Version 1.3.0

    253 downloads

    Raycaster demo (written in c and assembly) This version is a big improvement in performance: it now runs at 10+ fps! I am quite happy with the speed. The demo plays quite nicely now. See below description of version 1.3.0 for details. --- This is a raycaster demo written in c and assembly for the Commander x16. I've been trying out the x16 and thought it would be a cool idea to start working on a raycaster. Ultimately it would be great if "Wolfenstein 3D" can somehow be ported to the x16. That would be a BIG challenge though! This is how it looks now: Speed improvements in 1.3.0: Now running at 10+ fps! - Using zero page addresses for pretty much all my variables - Using fast multipliers that use "square" tables: https://codebase64.org/doku.php?id=base:seriously_fast_multiplication - Inlined the fast multipliers, so less copying of values, no jsr and rts - Re-using the somewhat "static" parts of the multiplications, so it won't be re-loaded/calculate each ray (this was harder than it sounds, quite of bit of refactoring done) - Cosine and Sine fractions are player-related, and even though they are negated sometimes, they (that is their squares) could be reused for (almost) each ray - The (square of the) fraction of the tile the player is standing in -to be used for calculating the initial x/y interception for each ray- could be reused - Cleaned up the main loop and several other parts - Replaced the 16-bit slow divider with a 512-entry table: distance2height (major improvement!!) New in this version 1.2.0: - draw functions have been ported to assembly. Much faster! - dda casting functions have been ported to assembly. Much faster! - drawing textures! - automatic generation of routine to draw ceiling and floor (only 4 cycles per plain pixel) - automatic generation of around 512 routines for drawing textures (only 8 cycles per textures pixel) - using joystick controls (you can use arrow keys and alt to control, you can hold down keys) - a few textures from Wolfenstein 3D (shareware version) have been added (loaded at startup) - changed the map to look like the first level in Wolfenstein 3D - added a border around the render area, just like Wolfenstein 3D Usage Unpack the zip. Make sure you have the .BIN files in the same folder as the source files. To compile: (this assumes cc65 is installed) cl65 -t cx16 -o RAY.PRG ray.c ray_asm.asm -O3 To run: x16emu.exe -prg RAY.PRG -run To play: up - move forwards down - move backwards left - turn left right - turn right alt-left - strafe left alt-right - strafe right To debug: p - turn on log screen o - turn off log screen t - turn on test ray l - rotate test ray left j - rotate test ray right Known issues (1.2.0) - Sometimes there is a corner of a wall not drawn correctly - Since there is no real V-sync you get "shearing" in the screen (requires double buffering) Next up: - Lots of speed improvements - Lots of cleanup of code (its messy now) - Add a time-per-frame indicator (using a vsync interrupt counter) - Mooaarr wall-textures! - Double buffer to prevent shearing - Show a map on the screen - Bigger map (limit is now 16x16) - Opening doors - Add (scaled) "sprites" - Lamps (scaled) hanging from ceiling - Stats in lower part, gun visible - AI, enemies Having fun! Jeffrey
    14 points
  33. Hi everyone, while The 8-Bit guys needs no introduction, we thought the rest of the team should properly introduce themselves! I'll start the ball rolling... I'm a husband & father of 3 (furbabies), & actor-writer with a love of retrogaming. You might have seen or heard me at Perifractic’s Retro Recipes on YouTube, and I've been making retro music since before it was retro! For the fantastic Commander X16 project I'm proud to be spearheading the launch of the design and branding, among other things. Here's what falls under that department, with the help of some other very talented folks: This website's creation and hosting Case design & manufacture Keyboard design & manufacture X16 Butterfly Logo design & implementation Licensing Commodore BASIC & Kernel "Just the BASICs" user guide Packaging design & manufacture BASIC screen visual design/logo... I'm super excited as David's vision of his dream computer comes closer to fruition and am proud to be a small part of launching things to help that dream come true. I look forward to chatting with you all here! Your friend in retro, Perifractic
    14 points
  34. I wrote a series of blog posts/articles on Commander X16 architecture and coding. I have started with focus on beginners and then slowly moved to more advanced topics and techniques. First I tackle smaller chunks and use simple examples to show the topic in practice. After enough new knowledge is covered I write a complete game to utilize several of the techniques to illustrate how it all comes together so each new complete project is more complex than the one before. I do cover only Commander X16 specific so I recommend reading Commodore C64 BASIC tutorials and guides. Please note that the games and most examples are written with a goal to be as clearly readable and understandable so there is very little source code optimizations. Snake Game This game is written in very clean BASIC with very little trickery so not much special Commander X16 knowledge is required. We do VPOKE directly into video memory so only understanding of fundamentals is required. Recommended reading VERA Overview Topics Covered in Game Analyzing the game itself is a great way to learn basics like: How to structure source code (outer loops, game loop) What is Game loop Use of Data structure like multiple Arrays How to read Joystick, Keyboard How to use VPOKE to “talk to” VERA Video RAM organization and using colors Writing to certain location on the screen Using PETSCII control characters to display messages and title screen GOTO Crazy Snake Tutorial GOTO Download Tetris Clone This game introduces some more advanced features of Commander X16 and we have to take a bit more care of how to use data structures and optimize some parts of the game to make it playable. Recommended reading VERA Overview Tiles in Basic I - Video Modes 0 and 1 Colors and Palettes Topics Covered in Game Tetris clone requires us to improve on pretty much all parts of the snake game structure: We have additional loops outside and inside game loop Advanced game collisions based on screen state Pre-calculate relative positions of four segments of each tetromino Customize color palette Customize tiles (characters) Speed increase per level Adding sound to the game GOTO Crazy Tetrominoes Tutorial GOTO Download Boulder Dash style game With this game we are using most of the Commander X16 hardware capabilities and we are getting close to squeezing most out of it for BASIC games. We have to pay close attention to timings, synchronizing scrolling and animation, take care of different types of collisions, etc. Recommended reading VERA Overview Tiles in Basic I - Video Modes 0 and 1 Sprites in Basic I - Setup Sprites in Basic II - Animation Scrolling and Layers in BASIC Colors and Palettes Simplest Sound Effects Library for BASIC Font Library for Commander X16 Topics Covered in Game This game is taking advantage of hardware features of Commander X16 to the level it almost looks like 16bit game or something written in Assembly for 8 bit computer like: Two phase approach to development Full color mode Full screen scrolling Two layer graphics Scrollable playfield Static HUD Animated full color sprites 256 color title screen in graphics mode Advanced physics and game mechanics Loading assets to memory from binary files for: Tileset Sprite Sheet Fonts Sound effects library Title screen GOTO Crazy Boulders Tutorial GOTO Download
    14 points
  35. I've been noodling this game idea in my head for several years, and finally decided to do it on the Commander X-16. This isn't in a playable format yet; I spent several months just generating the lookup tables for it, and this is the first time I've had anything at all to show. I'm gong to use this thread to post updates and releases as progress happens. Asteroid Commander will be a game sort of like SimCity, in space, with a storyline. There's no sound in this video. The asteroid is procedurally generated, and the image is raytraced - for certain very limited definitions of raytracing. The shadows are very rough right now and I can see I have a bit of work to do on the ray maps, but the toughest part of the game engine is basically done.
    13 points
  36. Hi! First time posting here. So basically I have a game project coming that targets a retro machine with quite capable graphics and sound. Which I found this system to be a good start. However, the current x16-docs hardware reference is quite hard to navigate and lacking in some details. Inspired by hardware references I usually use for Gameboy and SNES programming, I decided to spend few weeks and write my own X16 hardware reference. Which is now available in both (printable) HTML and plain text here: https://ayce.dev/emptyx16.html https://ayce.dev/emptyx16.txt Note that this will be updated once I can confirm more details and a hardware itself is finalized (no, please don't reply about that leak here). So please look forward to it. The document's source is also available here and everyone is welcome to contribute.
    13 points
  37. During my conversion of Petscii Robots over to the X16, it was relatively smooth until I added sound support. So, I thought I'd talk about the one big issue I ran into, which I wasn't expecting due to my previous experience coding for Commodore machines. Because the Vera has it's own video RAM, you have to set the VERA_L, VERA_M, and VERA_H every time you are about to write something to video RAM. It's a little more cumbersome than the way things are done on other Commodore computers, but not terribly so. In fact, in about 25% of cases, I found it easier to use this than the C64, depending on what I was trying to modify on the screen. So, In my sound/music routine, I'm using the VERA's built-in PSG. Which means my sound routine is changing VERA_L, VERA_M, and VERA_H every time the IRQ routine runs. And the IRQ can run right in the middle of your writes to VRAM. And unless you want to add an SEI and CLI before and after every routine that writes data to VRAM, you'll need to backup the VERA address registers in your IRQ routine. So, I did this: LDA VERA_H PHA LDA VERA_M PHA LDA VERA_L PHA ***insert IRQ code here *** PLA STA VERA_L PLA STA VERA_M PLA STA VERA_H Now, while this may sound obvious to some people, I wasn't accustomed to dealing with this sort of thing when writing to sound registers in the SID or VIC-20 or whatever, since they were their own separate registers. Anyway, hopefully this piece of advice will help somebody else not pull their hair out in the future.
    13 points
  38. David has posted a video defending his actions and why the IBM thing was not "really dumb" as you put it. A vast majority of electronics engineers agree. Please watch your language and remember the group rules you agreed to when joining.
    13 points
  39. I wanted to address the recent departure of Perifractic and talk about some of the change in direction. This could be a long one, so settle in. The absolute first thing I want to clear up just in case anyone is thinking this, Christian (Perifractic) and I are not mad at each other, we didn't have a fight or a falling out or anything like that. We are still friends. This was a mutual decision and it is really mostly to do with his personal issues as he has already stated. That being said, Perifractic and I often disagreed over certain aspects of this project. And because I respect his opinion and experience, I often gave in to his advice on matters. There were two issues specifically that we disagreed on, which was the inclusion of a case on phase-1 systems, and whether or not the Commander X8 should ever see the light of day. So, now that he's stepped back from the project, I want to talk about both of these issues and a general change in direction for the entire project. Dropping the case, moving to kit sales. One huge issue that Kevin and I have been dealing with (mostly Kevin) is trying to figure out how we can get this manufactured. In order to get the cases we needed a minimum order of 1,000 units. And that in an of itself isn't a problem, but assembling 1,000+ motherboards would be. As I've shown in some recent videos with kit computers, it can take an entire day just to solder one together. So, 1,000 units (or more) means 1,000 days of work. So, the obvious answer would be to have them commercial built and wave-soldered. PCB-Way even offers this. But, this becomes more of a nightmare than most people can possibly imagine. I'm not going to go into the nitty gritty details. It wasn't until Kevin spent hours discussing the issues to me, that I was able to comprehend the enormity of that challenge myself. Here are just a few of the issues involved. Getting them the parts. They have to be shipped to China. Tens of thousands of dollars worth of parts. And they have to get through customs and actually arrive at the factory. If even one piece is missing, then the whole project stalls. Shipping to China is often a crapshoot with packages mysteriously disappearing. Many of the parts are custom or rare parts that cannot be sourced easily in China. And of course, factories like this require parts to be in reels and various forms designed for their machines to do. When you actually look at the BOM on the X16 and realize how many parts we're talking about, it becomes a nightmare to find all of the right parts in the right form factor for their machines, and get them those parts. And everything has to be right the first time. Every single part. And then there's the issue of where to store 1000+ cases, keyboards, and motherboards while it is all being assembled. We'd probably have to rent a space to do that. Somebody has to pay for that. And then somebody has to actually assemble all of this into a box. Thousands of boxes. Incredible amounts of labor here. And to top things off, there is a chip supply shortage right now. Some of the chips we need aren't even available at the moment. And those that are have gone up in price by 50%. This is hopefully a temporary problem. Then of course, we had a sample case from the manufacturer. When Kevin mounted the X16 board inside the power supply died after about 10 minutes. And our board is only pulling somewhere like 10% of the max load of that power supply. So, it was definitely a bad power supply. This made us very concerned about buying 1,000 of these cases and potentially having a bunch of dead power supplies. That was sort of the straw that broke the camel's back. And one last thing I'd like to mention. All of us on the X16 team have spent uncountable number of hours developing this product. And many of us have also invested quite a bit of money. In fact, most anytime an expense comes along, all eyes and fingers point to me. I know Perifractic has already invested a 4-digit number of Dollars towards this project. Myself, that number is 5 digits. And up to this point, none of us have made a dime back. Moving forward with the original plans of full case and fancy packaging was going to require another large infusion of cash (most likely from me) that I just don't have. I have no desire to mortgage my house to fund this project. The risk is just too high, and despite what some people think, YouTubers like me are not millionaires. So, bottom line is we're in over our heads. So, unless there is some wealthy benefactor out there that would be willing to finance this project and take on the high risk, things needed to change. So, after much discussion, Kevin and I decided the fastest and easiest way to bring this system to market would be to take a new approach. As you all know, we had always planned a stage-2 and stage-3 of this product. I always knew those would be the mass market versions because they would be cheaper. But I wanted to have the "real thing" with DIP style chips as the basis for the design. And I wanted it to be available along side the phase 2/3 products for those that wanted it. And we have that now. So, what we'd like to do is just start selling the product we have in two ways. One option is a kit that you solder together yourself. It would include no warranty and no tech support, other than community support here on this forum or facebook. Obviously, we'd be able to supply individual replacement parts if somebody fries or somehow destroys some part in the process of assembly. We just won't be able to help every Tom, Dick, and Harry to troubleshoot why their kit isn't working after they assembled it. The second option would be to build-to-order. So you place the order, we build the computer and add a substantial mark up for the 8-hours of labor to assemble it. But you get a fully working and tested board, which would come with some minimal warranty. I don't have specific numbers for cost. But I'd imagine a fully assembled kit would have a markup somewhere in ballpark of $100 to $200 over the kit version. I know that sounds like a lot, but when you see how much time is involved, it only makes sense. Also both the kit and pre-built machine will come with the custom keyboard. I've already paid 50% down for the PS/2 keyboards, so it makes sense for me to pay the rest and have those included with the computer. So, the bad news is, you don't get a case with phase-1. But on the bright side, this change means the kits could be available relatively soon. However, as you saw in the last video there are still some Kernal bugs that need fixing and our primary Kernal developer has taken a small hiatus due to some other large project that is consuming his time. We're not sure at this point when these bugs would be fixed. However, we could start shipping limited number of "development" systems to people who are already writing code. And hopefully all we'd need is a ROM update to fix these boards when the kernal bugs are addressed. Phase 2, Phase 3, and the Commander X8 So, once phase-1 gets underway, we will consider a few future options based on demand and popular opinion. Phase 2 would be an all surface-mount product. It would still have discrete CPU, RAM, ROM, etc. But it may drop some logic chips in favor of a CPLD to reduce size, complexity, and cost. It should be substantially cheaper. Because it is surface mount, assembly actually becomes MUCH easier on a mass-production scale. In fact, Kevin said he could possibly even assemble them at his own place of business (TexElec) which would simplify the situation a lot. This product could be sold as a board or possibly include a custom case, unlike Phase-1. But, we could potentially skip Phase-2 all together if it seems like people would be more interested in Phase 3. Phase 3 would be a small board like a raspberry Pi where the entire system is basically in an FPGA. I suppose if there were enough demand (like tens of thousands of units) we could maybe get a custom ASIC produced. The Commander X8 - Believe it or not, this product already exists. I've had one sitting on my desk the last 6 months. This is entirely designed by Frank. It's a 100% FPGA implementation. It is sort of a subset of the Commander X16. It has mostly the same architecture, but it has minor differences. There is also already an emulator for it. It's about the size of a Raspberry Pi. So what is the deal with the X8? Frank and I were in favor of bringing this product out 6 months ago due to the delays of the X16. But some team members didn't like the concept, saying it would dilute the image of the X16. And they made some good points. So, we decided not to release it at that time. But now that things are changing, I thought at minimum I should explain what it is and see what kind of interest people have in it. On the bright side, it is a product basically ready to be released. But does fall short of some of the cool things on the X16. So let me explain how it differs. Most of these concessions and incompatibilities boil down to using a smaller, cheaper FPGA design. It has 64K of base RAM and 64K of VRAM. It does not have any banked RAM beyond that. BASIC works essentially the same and should be compatible with most X16 programs that are coded in BASIC. VRAM access is fundamentally different. There is a 256 byte window into the VRAM which is mapped to a section of base RAM. You can move the window around. This is actually more efficient than what we do with the X16 and is only possible because it is all inside an FPGA. This does mean software written in assembly language will need to be tweaked to be compatible. The Vera is more or less the same. All of the same registers. Same PSG sound features too. But, programs that use more than 64K VRAM would need to be modified. There is no Yamaha sound chip. However, as we've seen already. The 8-voice sound system in the Vera is pretty darned capable! Uses a USB keyboard instead of PS/2. and USB for controllers (so, no SNES ports) Runs at 12 Mhz instead of 8. So, the big question is, if we were to release the X8, would that essentially replace Phase-3 of the X16? How would this product live along side the X16? Would it have an effect that people would simply code software for the X8, thus making the X16 be sort of like the Commodore 128 or the Plus/4, where all of the software is written for the lowest compatible system and therefor never taking advantage of the full system? So, to explore that, I would counter and remind people of what features the X16 has that the X8 would never have and see if that is enough to justify writing software for it? X16 has a TON more RAM X16 has twice the video RAM X16 has 4 expansion slots X16 has a Yamaha sound chip X16 has an IEC disk drive port (although admittedly that is not implemented in the kernel yet, but should be working at some point) X16 is infinitely more "hackable" X16 has SNES ports. So this product is "really close" to what I envisioned the X16 phase 3 to be like, but not quite. But on the bright side, it could literally be available almost immediately (pending getting a batch produced) if people are interested in this. So, at this point I'm looking for feedback on the future. Should we continue as planned to phase-2, then phase-3? Or should we drop phase-2 and move straight to phase-3? Again, phase-1 would still be available concurrently, and indefinitely for those that want it. In other words, Phase 3 doesn't replace Phase-1. Or, should we scrap phase-2 and phase-3 and release the already finished Commander X8? Or, should we do some other combination of things?
    12 points
  40. Version 0.5

    61 downloads

    I had been lurking on the forums for a few months when I found Prog8 and though this looked interesting. I.e. I could learn a new language and test out the emulator. I recently saw some good demos using C64 emulator but just based on PETSCII graphics and I though this looked surprisingly cool. Then I remembered the old Galaga game on the C64, the one using just (a few) petscii chars. I thought making something similar would be a nice challenge. The game is continuing to move toward what I consider a complete (but short) game. There are now 12 levels at which point the game will end in victory (bonus points for lives remaning). I am currently inclined to thinking that it's ok to end up with a fairly short and "completable" game. I still need to add some sort of simple high score handling. And there are always places that could use a bit of extra polishing but perhaps it would be better to spend that effort on another game.
    12 points
  41. 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!
    12 points
  42. Version 1.0.1

    49 downloads

    This is a simple voxel demo written in 65c02 assembly. It has been tested in the r38 emulator. Press W A S D to move around. Press SPACE to quit.
    12 points
  43. STNICCC Commander X16 Demo Remake View File This is the release of a STNICCC Demo Remake for the Commander X16! I have been (silently) working on this for the last couple of weeks/months. It is time to release it :). Let's just say: the Commander X16 is far more powerful than I had thought! Here is a video of it running: Enjoy! Regards, Jeffrey --- PS. There was an earlier attempt to remake this demo on the X16 (done by Oziphanto on youtube). Oziphanto did a very nice comparison video of the X16 with several other machines of the 8-bit and 16-era: He also re-created this demo, but (in my opinion) did not do such a good job extracting everything out of the X16: his demo ran in 2:32. The remake I made does it in 1:39! His benchmark comparison should therefore be updated: Keep in mind the Commander X16 only has: - An 8-bit 6502 cpu (8MHz) - No DMA - No Blitter Yet it keeps up with 16-bit machines like the Amiga! (actually its even faster right now) --- Extra notes: - This only works on the x16 emulator with 2MB of RAM - It uses the original data (but its split into 8kb blocks, so it can fit into banked ram) - Waaaayyy to much time is spend on the core-loop to make it perform *this* fast! - My estimate is that it can be improved by another 10-15 seconds (I have a design ready, but it requires a re-write of the core-loop) - It uses a "stream" of audio-file data and produces 24Khz mono sound (this will not work on the real x16, since loading the files that fast is a feature of the emulator only) Here is a version without audio (so this should run on a real x16): And it runs even faster (1:36:90) Submitter Jeffrey Submitted 05/21/21 Category Demos  
    12 points
  44. Here is Adrian's video about the troubleshooting:
    12 points
  45. Right, as I think David said, the only people who get nothing wrong are the people who do nothing. Whilst I can see the perspective of some people about some of the things, with nearly a million people having lost their lives from this terrible pandemic, abusing somebody because of an old metal screw is frankly preposterous. Some people need a reality check.
    12 points
  46. Version 0.7.1

    736 downloads

    This is a space invaders inspired game. Use the mouse or joystick to control the player ship. The shield segments can take 2 hits each. If enemies get too close you retreat back to the last level. You lose when all your lives are gone or you fall back to earth level again. Now with 7 playable levels Requires emulator R38! Roadmap: more diverse enemy formations enemy attack raids over the sides power ups (shields, double cannon, disruptors etc.) boss enemy joystick control done music done Different enemy sprites. done Sprite animations. done for player sprite and enemies fade in/out of palettes and backgrounds. done more levels with more backgrounds (all planets of the solar system), done sound effects basics done title screen How to use with the local emulator: Unpack ZIP file into the same directory as the emulator. Start the emulator, then enter LOAD"INVADERZ.PRG" RUN
    11 points
  47. 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
    11 points
  48. I must admit the only product I ever actually wanted was the phase 1 product and would be ok if phase 2 and 3 were never released. The DIP dev board would be a dream come true and opens a world of possibilities. The idea of a market for expansions cards and other products is incredibly exciting. I was also never interested in the case, however, the keyboards are nice. I don't see the value in the x8 and would recommend sticking to the x16 line for now to build one consistent ecosystem and then diversify later as you learn more on where the ecosystem goes. I can't wait to buy one! Great work guys despite the challenges. Thanks!
    11 points
  49. This is an unnecessarily critical and inaccurate comment, and isn’t the first time. It is not the tone we want for our forums. Please moderate your future comments before posting. I and others work extremely hard to keep the FAQ up to date and strongly dispute that “obsolete info is the norm around here”. In fact I do not believe there is one piece of obsolete info in the FAQ. And the FAQ is the single point that we send everyone to for the latest info. We are consistent about that. We cannot control somebody outside the core team mentioning to you something that they saw in a video by Kevin, and that person you chatted to labelling it an official announcement. Criticising a team who are working for free for not copying every thing that is said in a video into the already extensive FAQ is unreasonable. Michael is also not done with the new emulator version or the GitHub. You need to be more patient. The physical prototype will always be ahead of the GitHub. You also cite a wiki but as I have mentioned before, and as is clearly stated in the wiki itself, it is not official and we do not run the wiki. Would you prefer we have the fans who do run it take it down permanently if it does not meet your requirements? Finally please remember that this product has not even been released yet, nor have we taken a penny from anybody for it. We are offering unprecedented behind-the-scenes access to the development, which I don’t think has ever been done to this extent before even crowdfunding commences. Criticising us because we do not meet your high (and erroneous) standards will not be tolerated further. This thread has also run its course, with some unfriendly moments before today, so I hope everybody can just take a breath and perhaps move onto a different topic. Thank you for your understating.
    11 points
  50. The Assembly Environment (V0.8) is released, you can get the beta here: https://sites.google.com/view/x16asmenv/home I've also got a video about this release: https://youtu.be/adohtDGGPbE This release is now the first to be considered "beta", since I believe it to be feature complete (based on original plans). From here on out I'll be fixing bugs and making it rom enabled. Comments and bugs welcome!
    11 points
×
×
  • Create New...

Important Information

Please review our Terms of Use