Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 09/21/21 in Posts

  1. As one of the official team member I will say first. David has not thrown his hands up at all and if that’s how your are interpreted it, that means only that you concluded that first and are only hearing what you already believe and not what he said. Secondly David is really not that directly involved in the technical aspects of the project. Micheal who is handling the KERNAL development has been very busy. For example the PS/2 code issue. I’m not a code guy, but I was aware of the issue and a solution was proposed. But due to tight schedules, hardware changes, etc. the fixed code was never merged so the current KERNAL is using the incorrect code. The reason it doesn’t work with the faster CPU is because the timeout runs faster too and it reaches the timeout before the keyboard gets ready. The code needs to be updated to prevent that. As to other issues, we are dealing with supply chain issues which are not unique to us. You have cargo containers sitting on ships for weeks, you have factories halting production on all but a few lines, the global chip shortages, etc. And another point, for a project that as of now isn’t a crowdfunded project, how many are this transparent. We have ongoing tests with the existing boards are a trying to get enough parts to complete a few more boards. Fingers crossed if it goes well there will be only one more board revision and the project will advance to the preorder stage.
    10 points
  2. I will be uploading the demo files to the forums in just a few minutes...
    8 points
  3. The only portion of this music that is not currently supported is the PCM drum track. The way Sega Genesis PCM works is insane already (imagine VERA PCM but without a FIFO), and the way it's encoded in VGM is even more crazy to interpret and extract properly, so for now, pretend Sonic only gets drums whenever he's riding Yoshi. I fully intend to clean this importer up to more useful standards for sharing it with the community. As it stands now, it's full of special cases, etc - but it can import lots of types of VGMs to X16. It exports into my own music stream format which is also still not quite finalized. More to come!
    7 points
  4. Just adding my thoughts to the discussion about why the Commander X16 is worth the wait. I've spent all year so far working on a DirectX 12 project, with the goal of designing a 3D game for Windows desktop that's neither an FPS nor a flight sim. It's all being developed in Visual Studio/C++/HLSL, ie. not in Unity or any other game studio. My game framework so far successfully implements many features expected of a modern 3D game environment, including bump mapping, dynamic reflections, real-time shadows, a first-person camera, ability to pick geometry by mouse, and collision detection. It also supports post-processing effects such as HDR tonemapping, bloom and depth of field. However, after a recent month-long battle to get skeletal mesh animation working (which was finally solved), the burnout finally set in. What got me through each day of DirectX pain was turning to my favorite YouTube channels, namely 8-Bit Guy, LGR, RMC Cave, and Retro Recipes to name a few (see the pattern here?) Yes, despite being up to my neck fussing with modern PC graphics, I can't wait to wind down on YT with a classic DOS, C64 or Amiga game review, or a show-and-tell with a classic piece of computing hardware from days gone by. So naturally I did see all of David's episodes about the announcement and subsequent progress of the X16, but after sighing wistfully, it was mentally filed away and I thought if only I wasn't committed to modern-day 64-bit game programming for Windows... So there was a lot of internal conflict going on between what I really wanted to do deep down, and what I 'ought' to be doing. My justification for continuing with the current project was along the lines of, well, imagine if kids and developers had access to today's graphics hardware in the 80s? Wouldn't it be a dream come true? It's a reality today, so why not revel in it and take advantage of the latest technology instead of limiting ourselves to 8-bit era computing power? Well take it from me... I've found out the hard way that the latest and greatest GPUs and 3D APIs may be a boon for gamers and AAA game studios, but for the indie developer or hobby programmer it can be an absolute nightmare. Firstly, if you aren't able to cope with matrix math or pixel shader lighting equations then 3D programming isn't for you. Assuming you do grasp the math and physics of lighting, then there are the 3D APIs to wrangle. You absolutely MUST have experience with previous versions of Direct3D or OpenGL if you want to program with the latest generation APIs (DX12/Vulkan). Ok, assuming you have previous 3D experience. Sure, with a few tutorials you'll be able to render a few spinning cubes and even maybe a textured 3D model imported from a tool like Blender. But to populate a reasonably decent game world will take hundreds of hours at the very minimum. Building an animated 3D character and its associated textures and armature rigging alone may take weeks... and of course you'll want more than one game character. Then what about the game world itself, and physics, and AI? The crunch for me came when I realized my 'game' would never progress beyond the engine phase. There are just too many literal moving parts for an individual game designer/programmer to create and manage on one's own. And of course, when developing for Windows there will be change. We're on the cusp of Windows 11 right now, and that likely means an update to DirectX isn't far behind. In other words, be prepared to push that boulder all the way up to the top of the hill again. And then I remembered the X16 project and looked at Matt Heffernan's 65C02 assembly tutorials. Luckily I've got some x86 assembly behind me, so I dived right in and I haven't looked back! It's helped me break out of an unending loop and I'm certain I'll have something to show for it at the end. Programming for the X16/VERA graphics chip emulator has brought back the fun and anticipation that had been drained by trying to go it alone with a Windows game. That's why waiting a little longer for the final product (even in kit form) doesn't bother me. So that's why I'm a convert and I'm sure I'm not alone. As far as I'm concerned the X16 has already achieved its goal to make coding fun again. A bit long but... thanks for reading!
    5 points
  5. I would just like to address the comments about Mega65 trying to cash in on X16's void. They have had a very clear direction for many years (2014?). They're not trying to react to a market etc, or gauge what the community wants.. it's a very defined project that has attracted a community that finds the vision appealing. They wanted the devkits released last year, they made it happen. Then they've been pushing hard all year to make sure the final release and pre-order lines up with the 30th anniversary of commodore cancelling the c65 (1991). I can honestly say i have never seen any comments in the mega65 discord about trying to take community away from x16 (in fact the opposite, there has been talk about not porting the x16 core to the mega65 to not impact the x16 project, unless approached by Dave etc). There is no cashing in intent at all. Mega is not for profit organisation and Mega65 is a not for profit project. Both projects are very different from each other, with some overlap. There is plenty of room for both a closed design like x16 and open like mega65 in the world. As far as shipping and tariffs.. They shipped the devkits with dhl I believe and it was very quick arriving in Australia. But the best place for those sort of questions would be the mega65 forum or discord :). Hope that sheds some light on the thread for people not following the Mega65 project :).
    5 points
  6. Alrighty, I think I will back out of the X8 discussion, as it's clear that I understand neither the jargon nor the details of the device. I appreciate your efforts though! I just want to use the $50 8 bit computer David talked about nearly 3 years ago.
    4 points
  7. Buildings! Also I go over a very fast subroutine that multiplies a six bit number by26 and divides by another six bit number...in 100 cycles or less.
    4 points
  8. Extremely off topic ramblings which lead to moderate hostilities, because nerds will nerd. It's what we do. There were pages of off topic discussion, which I am sure a mod would have been happy to move to its own thread if the mod had more time to do that kind of thing; No one wants to shut down dialog, but it is important to organize and guide it to some degree. Please, stay on topic in this thread. Thank ye!
    4 points
  9. Lattice ICE40UP5K in the 48-pin QFN. https://www.latticesemi.com/en/Products/FPGAandCPLD/iCE40UltraPlus The datasheet: https://www.latticesemi.com/view_document?document_id=51968 Lattice's iCE40 family is a good place to start exploring FPGAs. They are a good deal simpler than most offerings from Xilinx and Intel.
    4 points
  10. after a long wait, Prog8 7.1 (beta version) has just been released. https://github.com/irmen/prog8/releases/tag/v7.1-beta Most of the changes this time are internal to improve code quality and testability. But several important bugfixes and enhancements have also been made. One thing to mention now is that the ``%target`` directive has been removed, the compilation target is set on the command line options. A full list of changes will be published on the 7.1 final release. In the meantime, here is the changes list since 7.0 https://github.com/irmen/prog8/compare/v7.0...master
    4 points
  11. There has been a lot of discussion in the past about the decision to use a 65C02 instead of a 65C816 in the CX16. I've read on the 6502.org site that dealing with the data/address pins can be difficult, even with the info provided in the data sheet. So it was interesting to run across a series of videos from a guy named Adrien Kohlbecker, who's attempting to design a basic system using it. I have no idea what his ultimate plans are, apart from the rev A specs in the introduction (Bank 0 RAM, some ROM and extended RAM, 6522 for peripherals, and a serial port). But those who like Ben Eater's videos will probably like what he's doing here. I especially appreciate how he's breaking down the timings, trying to visualize each problem that needs to be solved, updating the schematics, connecting everything on breadboards, testing, etc. Videos seem to be coming regularly, and so far he's handled the multiplexed bus, BE and RDY pins. He hasn't actually run the CPU in the design yet, but he's done basic tests of the latch/buffer for the data bus and bank address. The methodical approach he's taking is very promising, and it's been interesting to watch the progress. Apologies if this has already been posted. I tried searching for it and came up empty. Intro video is here:
    4 points
  12. Seems like there are better places for some of this discussion than this already too long thread. This thread is about what to do with the X8/X16 as they exist. It is not about philosophical discussions about how it should be done. At this point X8/X16 includes FPGA because a certain level of video capability and performance was desired, and that is the most cost effective way to realize the dream. Sometimes dreams evolve and plans change as new information and realities are realized. That's not a bad thing.
    4 points
  13. My point is that "David has expressed grave misgivings about the future of this project" is a massive misrepresentation of what David has said. (1) David has explained that one part of the previously laid out development path is cancelled, and has express uncertainty about whether or not to release the X8 system as already designed, and solicited community feedback to help inform the decision that the team makes. (2) David, in the original post, didn't express any misgivings about releasing the X16p when it is ready, but warned that it was not as close to being release ready as the X8 system was. Above, he reiterates and clarifies that the X16p is close to being ready, but it's not there yet. This is where "grave misgivings about the project" goes off the rails as a description of "It's close. It's not quite ready for release yet, but the X16p will definitely be released at some point." Now, as far as, "it's been TWO MONTHS AND NO CLEAR PLAN!!!!" as the foundation for a decision to panic ... the question becomes, is it certainly the case that two months without an announced clear plan is evidence of trouble? So the rest of this is much more speculative, but that's OK ... whether or not it is the actual situation, it presents one scenario where it would be unreasonable to expect an announced clear plan in a mere eight weeks or so ... so establishing that "two months and no clear plan yet" is by no means unambiguous evidence of trouble. (3) Objectively, when it was decided more recently that the X8 wasn't "close enough", that would seem to intersect with David's thinking that "most anything made for the X8 could be easily ported to the X16 later". That would seem likely to be true for any Basic program, but when it comes to assembly language programming, that becomes a bit fuzzier. (4) Information that it was decided that the X8 system as it had been designed was not going to be released ... and that Frank is going to work on a full X16e design ... doesn't pin down exactly what comes next. So, consider, that what MIGHT come next is flipping the Phase 1 through Phase 3 script, making a more completely upwardly compatible "smaller" FPGA that would more thoroughly support binary X8/X16 compatible assembly language programming, "HighRAM based" system programming, etc. But ... how would that compare in terms of price-point to a full fledged 512K or greater system RAM X16e? Would the price appeal of the "more compatible X8" starting point still work out? One way to answer a hardware question with so many unknowns is to do prototypes of the alternatives, and get a firmer idea of the bill of materials for actual system designs, rather than relying on guesswork. The development path there would be to prototype an X16e, then take that design and redesign it for relying on slimmed down X16 memory map for SPRAM and Block RAM resources hosted entirely on an FPGA in the same family, and evaluate what the price points look like at that stage. Now, that involves, (A) the team deciding that the X8 design as it stands is not as suitable for a "work on this now, upgrade to X16 later" approach as David was originally thinking ... that takes time ... (B) deciding to get a better idea of the opportunities for a more compatible approach ... (C) Frank laying out a prototype development path and the team agreeing to it ... (D) Frank developing the X16e prototype ... (E) Frank stripping it down to the "more compatible X8" prototype ... (F) decision ... (G) announcement. Now, would it really be unreasonable for that to have not yet reached (G) in two month's time? I would argue that a month to get to (C) would be reasonable and three months to get to (G) would not be at all surprising. So I'm not saying this is what is going on, but simply that, to my mind, it's far too early to be panicking because of no public declaration of the new development path two months after David solicited feedback on the strategy of going with the X8 first.
    4 points
  14. 1. If you want, you can already do that. BMC64 is an ARM "bare metal" version of VICE for the Pi products. The PET even runs on the $5 Pi Zero, even software upgraded to be a SuperPET. 2. Even the best software emulation has problems, such as input lag and incompatibility, where FPGA implementations do not. FPGA = the physical circuit schematic built into a single integrated circuit (IC) IC = a bunch of transistors in a single package rather than having fifty bajillion of them individually soldered to the board (plus other linear circuit components. Bottom line here folks is that an FPGA implementation is functionally identical to an IC + discreet component implementation, because the FPGA is literally the same circuity built into a different package.
    4 points
  15. Yeah, I tend to create a load of macros, as well. By the time I’m done, my programs are more macro than assembly. Essentially, what this means is I’m making up my own programming language. And I’m fine with that.
    4 points
  16. I've done some code cleaning the last couple of days. Very rewarding when the code becomes more compact, more readable, and more stringent. So far I've reduced the binary by almost 200 bytes. Some time ago, I watched a few lectures on Clean Code by "Uncle Bob". Very inspiring, even though not all paradigms may be used in assembly, if you want things to fly fast. A nice weekend to all of you!
    4 points
  17. TR50 refers to a specific packaging of the FPGA (50 part tape and reel). That packaging option has been discontinued. The iCE40UP5K-SG48I (which comes in the default 2,000 unit tape and reel) is still being produced and very popular. The reason for discontinuing the TR50 option is probably that they are simply making too many to cater to quantities that small. If you want less than 2,000 units, you go to Mouser or Digi-Key and they will cut a strip of them off the reel for you (for a fee, of course).
    4 points
  18. "To build the board, you have to find a provider that builds PCBs from Eagle .brd files. Currently no gerbers are provided." Too bad PNG wasn't used...
    4 points
  19. Certainly my comparison of volume product is the likes of ZX Spectrum Next, also a hobby platform. It is an example of a single coherent target platform I have in mind. It has a couple of models but all are compatible. On the other end of the spectrum are the likes of C256 Foenix that has many low-volume variants and little in terms of clear target platfrom yet. Personally I would prefer X16 project to resemble the Next in this regard: a single coherent target platform where possible model differences are details surrounding a shared, fully compatible core. On the Next there are even fully compatible clones of it, sanctioned, so it has a thriving software ecosystem. Even hobby developers like to target an audience and this type of platform would seem to maximize that. Just my two cents on what I would prefer personally.
    4 points
  20. Yes, I agree with you. The reason I left the MEGA65 discussion lists is because I knew I wouldn't be able to justify buying one. The X16 is more affordable, but it's the same issue: I pay a significant amount of money for something that's going to take up desk space that I don't have, and I'm not sure what I'd do with it really. The X8, on the other hand: I already want one. It hits my price point so easily. Worth it. Regardless of whether or not I get the X16.
    4 points
  21. This was it! The filename was buried in my code in RAM Bank 1, since it fixed data. I moved it to my data segment in main RAM and now the Save works just great. Thanks folks.
    4 points
  22. Hi all I'm glad that someone undertook a great project like this. I'm following your progress, and the videos you are posting are very good and informative, thank you. I'm excited about the project and will buy CommanderX16 when its available, for sure. Keep up the good work. Sincerely Charles Thivierge
    3 points
  23. I'm pretty open about my Raspberry Pi hobby and how much I love the platform, especially for retro emulation. However, a while back I decided to see if I could use a Pi 4 as a "budget" mini-portable PC, I wanted to see if it could act as alternative to my desktop when I am not at home. So, I got the 8GB Pi 4 B and started messing around with it. One thing I knew out of the gate was I didn't want to run an SD card as my primary drive, they are simply too slow and that would be a non-starter for me, especially when I am used to the snappiness of my vastly more powerful desktop PC, and I also didn't want a flash drive sticking out of the Pi to use instead of the SD card. So, I went looking to see what was out there... That's when I ran across the Argon ONE M.2, basically a Pi 4 case that lets you use a SATA M.2 SSD on your Pi 4 via one of the USB 3 ports, but all contained in a small and very convenient case. I piked up a cheap Silicon Power 128GB M.2 SATA SSD (originally tried a 64GB drive but got the 128GB cheaper on sale), popped it in the case, and dropped the Pi OS on there and ... wow ... I really did not appreciate how fast the Pi 4 actually is, or how much the SD cards were "bottlenecking" it. After a couple months of using this setup for a multitude of daily tasks, from retro emulation, web browsing, HD video playback, Arduino, PCB design, image editing, and even using Steam Link to connect to my desktop and stream games. I can say that this Argon M.2 case is amazing! At least it is for someone like me. The nice thing is you can still use the SD card slot as a "slow" storage drive to expand your storage capacity. All in a very small form factor that you can easily take with you anywhere. The overall speed of the Pi 4 is actually quite impressive when running on that M.2 SSD over USB3, while it's obviously still a bottleneck for the SSD, it's a massive speed boost over SD or USB flash drives. So much so that it actually works very well as a daily driver. So yeah, I just wanted to share in case anyone was ever in the market for such a thing, and wanted to cram as much performance out of a Pi 4 as the possibly could. On a side note, I overclocked the Pi 4 to just a smidge over 2.0GHz, and it's stable in this case, and stays much cooler than I anticipated. Overall, I am very impressed. https://www.amazon.com/gp/product/B08MJ3CSW7/
    3 points
  24. Sonic GHZ with raster lines and music View File This demo is made from original game assets and translating the VGM tune into YM2151 + VERA PSG. I made this demo because I think too many people forget just how great the graphics can be on the X16. I also think the FM music is vital to the 16-bit era of gaming, so this demo shows how the Commander X16 can deliver the goods if you like a 4th-gen experience. Submitter ZeroByte Submitted 10/18/21 Category Demos  
    3 points
  25. The options available in your poll are strange enough that I don't feel comfortable choosing any. What I can say is this... I learned how to solder 30 years go. I was terrible at it then and I am worse at it now. I wouldn't buy anything that required soldering anything more than a couple of power leads. I don't enjoy soldering, at all. Aside from the fact that I just don't want to solder a kit anything together... I don't have a properly ventilated location to work. I don't want to troubleshoot and repair complex circuitry. I don't have the electronics tools required to troubleshoot and repair complex circuitry. I don't want to buy (or own or use) all the equipment required to solder/de-solder properly. I don't want buy (or own or use) the electronics tools required to troubleshoot and repair complex circuitry. There was a time in the distant past where I would have answered this question differently, but people and circumstances change. I already have hobbies that require more time and attention than I have available, such as using already assembled devices to program.
    3 points
  26. Don't know. Of course, there's going to be some sticklers who would be all "not ALL of the chips in the X16p are DIP, not ALL of the chips in the X16c are surface mount, all three boards HAVE an FPGA". Iron Internet Law number 38 is "no naming satisfies everyone".
    3 points
  27. The X8 is really a different beast than the later stages of the CX16 roadmap, so the X8 debate won't be one with the FPGA or SMT versions of the CX16. With the X8, you're talking about a computer that's really very different: it will not have a full ROM. Instead, it will have a bootstrapped RAM operating system with a very small bootstrap ROM. This is how CP/M works: there's just enough ROM (a single page, in fact) to boot the BIOS from disk. Then the BIOS boots the command processor, and you have an operating system. From what I understand, the CX8 will work similarly: the bootstrap ROM will load a BASIC+KERNAL program from SD. This means that programs can be written to occupy all 63K of system memory (There is a small carve out for I/O space) without ever actually loading the KERNAL or BASIC. This is not something the CX16 is currently capable of (unless we get RAM in one of the ROM banks.) The other difference is that VERA is accessed via a single, 256 byte page, rather than the 32 I/O registers we have now. This dramatically changes the I/O process, since you have access to a full line of text or tiles directly, rather than the indirect method the CX16 uses. And we obviously have the 512K vs 128K issue to think about. Programs written for the CX8 will have to fit no more than 128K: 64K of main memory and 64K of video memory. On the other hand, the Commander X16 roadmap includes a Surface Mount (SMT) version and an FPGA version. Both of those will have the same I/O and memory structure as the CX16E (the version currently in the works), but with smaller circuit boards and fewer chips to do the same job. While the package may be smaller, the software will be the same: the same program will run, unmodified, on all 3 of the planned Commander X16 editions. Software that directly accesses video, sound, the User port, or the IEC bus will not run unmodified on a Commander X8. That's the difference. The X8 is a different computer, and while it shares some common parts, it's as different from the CX16 as the Commodore 64 was from the Plus 4.
    3 points
  28. I even made a conceptual PCB Front for the X8 hoping it would be released. just to be clear, I did this in MSPAINT.
    3 points
  29. Im not @Scott Robison but I think one perhaps unintended side effect of the X8 is the possibility that it can be programmed to run other 8bit/6502 Machines in FPGA alongside the VERA in FPGA for Video output. Granted that would probably require "erasing" the X8 ROM and assuming the ICE40UP5k could be programmed multiple times means that the X8 platform could be the basis for a truly inexpensive 8bit AIO FPGA machine.
    3 points
  30. One more time for the people in the back row, mind your language.
    3 points
  31. In other words, you have a fundamental philosophical disagreement with this particular project, which is being pursued by people who appreciated the stable development platforms represented by the 8bit systems like the Vic20 or C64 or Atari 800 and wanted to create a new system that would offer a similar stable development platform. The ongoing element in those systems was the ongoing exploration of what is possible within the constraints of that stable development platform. As far as projects which are not stable development platforms, but are, instead, always temporary way-stations before "screwing the whole page up and throwing it into the trash" ... there really are quite a lot of those. It seems as if there will continue to be, even if the choice of building a stable development platform is not outlawed in the name of pursuing hobbyist hardware development as an ephemeral art form. As far as the question in the OP in this thread, can we take it your view is you are against the X8 being released first, you are against the X16p being released first, and you are against them being released simultaneously, because you are fundamentally opposed to some of the goals of the project itself, and wish to edit those goals into goals more to your liking?
    3 points
  32. I think this thread has jumped the shark. Perhaps it needs to be locked, too.
    3 points
  33. So far, when I answer by saying "This call is being recorded for fraud prevention purposes, is that okay?" I get either (A) They immediately hang up. (B) "No sir, it's not being recorded." to which I reply "No no, I'm recording it to prevent fraud" after which they hang up. (C) [BY FAR the most common] the computer-controlled message-spewing system has no idea how to respond to that, and so it cavalierly proceeds to tell me I promised them a $35 donation six weeks ago. I usually respond by saying "It's taped to the back of a tortoise, he'll eventually wander your way."
    3 points
  34. So many red shirts, has Bezos never seen the original Trek? Unless your name is Montgomery Scott, you should be very ... very worried! haha
    3 points
  35. I've grown up in East Germany and at the end of the 80s I've managed to assemble a computer described in a magazine. A few years ago I've learned that the processor was an east german copy of the Zilog Z8. You needed to find the parts (some chips weren't easy to get at this time), draw and etch the circuit board and find one who can program the EPROM. While being electronics addicted since the 4th class, this made me become software addicted. The magazine not only described the hardware and some extensions, but also printed some smaller BASIC programs as well as the processor's details including the assembler language. I used this 8-bit machine to create my own operating system (later I was able to flash EPROMs myself using this machine), to create own games. Some of the games I've got from a pal who developed them own completely different hardware (with different processor and graphics) and provided me the assembler code. Later I've received an obsolete Commodore machine with floppy drives and in the last weeks I've recognized it could have been a PET. 5 years after I had enough money to get the hand on a used 286 PC and that was the end of my 8-bit career. I've sold my self-built machine for ~100 DM which I regretted later. When Arduino became popular >10 years ago I immediately liked it, but it wasn't the same. It was not much more than a bare processor without much hardware around it, most noticable it was not usable as an 8-bit computer to develop and run arbitrary software on it that was not on the flash already. But it also showed what a 8-bit dream-computer should have for me: it should be easy to program from a stock PC.
    3 points
  36. There is also the point that once you go fixed--silicon, that's it. So, it kind of makes sense it is the last step in a project like this – If it is to be done at all. Even if the feature-set would be fixed early on, the upgradeability of an FPGA can be very helpful in low-volume hobbyist projects. We do have some precedence for this though in the Commodore community: the hobbyist C-One (FPGA) evolved into the higher volume C64 Direct-to-TV (ASIC).
    3 points
  37. Here is an over-simplified but still useful way to visualize FPGAs. Imagine a huge Ben Eater style breadboard prepopulated with thousands of simple TTL gates and flip-flops, but no wires. By itself this logic does nothing, but by adding the right wires one could implement many possible useful circuits. Programming an FPGA is analogous to plugging wires into this breadboard.
    3 points
  38. When people focus on what David put in his first video, such as "no FPGA" and claim this is not in keeping with his dream, they seem to overlook the price aspect of that initial dream. We've all subsequently learned (for those who didn't know it previously) that some of those goals are mutually exclusive. You can either spend a lot more time, money, and other resources trying to build a discrete video subsystem that has all the bells and whistles that were desired (which completely destroys the cost) or you go FPGA (which is much more affordable) or you just throw up your hands and say "can't be done oh well". David showed X8 as being possible at an affordable price point but ultimately stated it wasn't enough like X16 on FB, so they're looking at something similar that will still get close to his originally desired price point. I big part of the motivation for this was "how can people get into retro computing at an affordable price". Here is a question for the community at large: What is better for the X16 ecosystem, a kit that only select people will be able to assemble, or a relatively inexpensive FPGA based solution that many more people can afford that won't involve assembly? While the former would be awesome to have (and I plan to buy it when it becomes available) there is far more potential buy in with the latter (which I also plan to buy when it is available). I think there is too much "what do I personally want" and not enough "what is best for adoption so there can be a vibrant community". There are still C64 games being sold today thanks to critical mass of adoption and not nearly as much if any software being released for the KIM. If one simply wants a retro computer to use on their own and aren't worried about a community, and a kit scratches that itch, fine. But if you want to be able to find software to run on it that you didn't write yourself, you're going to get a lot more options if the hardware is more accessible to a wider audience. In that respect, the kit is not unlike a KIM (inaccessible to all but the most hardcore fans) and the complete FPGA solution is the C64 (much more accessible and interesting to a much larger universe of potential users).
    3 points
  39. Well a lot of this is why David put out polls. See if people are expecting a fully assembled unit we don’t have the manpower or logistics. If we assemble them stateside we don’t have the manpower and if we have to assemble them in China there are logistics problems. But if it’s a DIY kit then that really helps. But not everyone is capable. I’m good at soldering and these take a while and it may be beyond a newbie. it seems the majority is fine with units minus cases and requiring users to assemble themselves. For full assembled units expect to pay a premium and have a long wait time. As for the X8 I’m warming up to the idea.
    3 points
  40. One thing this thread should make clear: people have become passionate about this machine. One way or another, it will happen.
    3 points
  41. You're in luck. Facebook has been down for at least three hours today.
    3 points
  42. This is why I dislike Facebook…. Unlike proper forum software, there’s no “catch up” system on Facebook groups, which shows you just the posts you’ve missed. I saw the post by Ian, but never saw Klaus’s reply, David’s reply to him, or Phil’s reply to David… IMO why Facebook groups should be used sparingly and for official announcements, leaving actual conversation to product forums like this one.
    3 points
  43. Continuing on the topic of clean code, even though its not X16 Edit specific, I have some thoughts on how to apply to assembly programming. In the lesson linked above, Uncle Bob is talking a lot about the design of functions: Names of functions (and variables) should be carefully chosen, so that reading code is like reading (good?) prose Function names should contain verbs, as they are doing something A function should do only one thing; the process of cleaning code entails breaking a function into the smaller and smaller parts, and you know you're done when no more functions can reasonably be extracted A function should be short (most often 5 lines) In a modern cross assembler, such as ca65, there's nothing stopping you from naming things properly. But what about functions doing only one thing, and functions being short like 5 lines? Any high level language examines functions at compile time, and decides wether the resulting machine code is inlined or made into an actual machine language subroutine. Even if you are writing a lot of really small functions in a high level language, the binary code will probably be efficient. In 6502 assembly, if you do a lot of subroutine calls with JSR+RTS, they will all stay in the final binary code making it inefficient. I have never seen 6502 assembly code trying to be clean code in the way Uncle Bob describes. Would it even be possible without loosing performance? I think it might be, if you use extensive use of macros for code that you want to break out into a separate "function" where the resulting machine code is inlined. A simple example. Is this a good idea? .macro goto_topleft stz VERA_L stz VERA_M lda #(2<<4) sta VERA_H .endmacro .macro clear_line ldx #80 lda #32 : sta VERA_D0 dex bne :- .endmacro .macro goto_nextline stz VERA_L inc VERA_M .endmacro .macro is_finished lda VERA_M cmp #60 .endmacro .proc clear_screen goto_topleft loop: clear_line goto_nextline is_finished bne loop rts .endproc VERA_L = $9f20 VERA_M = $9f21 VERA_H = $9f22 VERA_D0 = $9f23
    3 points
  44. Spurred to action by the Mini-PET. He uses a 65816 as the CPU, and a CPLD to do a lot of the dirty work on the board. https://github.com/fachat/MicroPET Commodore 3032 / 4032 / 8032 / 8296 with options menu to select at boot Boot-menu to select different PET versions to run 40 col character display 80 col character display 8296 memory map emulation IEEE488 interface (card edge) Tape connector (card edge) PET graphics keyboard, or alternatively a C64 keyboard Improved system design: 512k video RAM, 512k fast RAM accessible using banks on the W65816 CPU boot from an SPI Flash ROM up to 12.5 MHz mode (via configuration register) VGA b/w video output Write protection for the PET ROMs once copied to RAM lower 32k RAM mappable from all of the 512k fast RAM Improved Video output: Hires graphics mode (using a configuration register) modifyable character set 40/80 column display switchable 25/50 rows display switch multiple video pages mappable to $8000 video mem address
    3 points
  45. "Don't know if anyone reads here *and* the forums but a chap posted this on there today : "you mentioned that you guys already have an X16 implementation based on FPGA - wouldn’t it make sense at this point to go for that?" and David responded with: "Not exactly. We had the X8, but decided it wasn't quite compatible enough. So I think Frank was going to work on the full X16 implementation." Has a decision been made I wonder ?
    3 points
  46. The TR50 only refers to how the parts are packaged for pick and place machines. All SG48 components are 48 pin QFN. The "I" refers to industrial grade. This is covered in section 5.3 of the datasheet:
    3 points
  47. Not sure if it will be broadcast live (if not, probably post event) but Stefany is giving a ‘class’ on how to create a rudimentary video controller on FPGA at VCF East on Friday Oct. 8th. As you may be aware, she owns C256 Foenix and her VICKY II and III components are built on Altera Cyclone 10 (and now IV) FPGA. I expect the class/talk to start with the basics (problem statement) of needing to take text or image in memory and manipulate clocking and data sync to fit the SVGA spec as Ben Eater’s Worlds Worst Video card did, but instead, leverage rocket fuel to take this to the next level. VICKY has all of the bells and whistles (sprites, tiles, scrolling, dual head output and more) but this talk will probably just cover basics. Should be interesting. Between some maniac (Ben) throwing graphics from ROM to screen without a CPU to the MiniPet, which uses an Atmel to emulate the CBM PET video circuitry, to SIDs and VICKY / VERA, it’s an amazing thing we are witnessing. About 15 years ago, the company I worked for bought FPGA tech to process and route virtualized namespace storage network packets at [then] line rates and it was expensive as hell. Today, you can buy an FPGA Dev board on Amazon for about $150 or less and produce your own!
    3 points
  48. My advice is based on various business and computer science training and a little experience. I recommend producing and shipping an initial X8 system ASAP whether you offer DIY kit and/or preassembled. Think about more than just the numbers you also need to consider intangibles those things for which you cannot directly assign dollar values. For example people need to be able to get their hands on an actual system to stimulate them and keep up their morale so they will be willing to wait for an X16 system. Be clear about everything involved with regard to a DIY kit and recommend it only to those who have more than enthusiasm they must already have experience with assembling such things otherwise you will have a headache and discouraged customers. The emulator should be dropped right under their nose repeatedly so they are reassured that they can give the system a full go without handing over their wallet. I am willing to buy a 'baby' X8 system and I bet many other former hobbyists and people curious about computer science are willing to risk it. ******** Good Luck, Dan.
    3 points
  49. I signed up to place a vote here, but I figured it may be helpful to add some context. Honestly, I don't have a lot of money to spend on these kinds of things. I am still using my AMD FX-8320 based desktop that I built in 2013 and I intended to replace in 2018, because you know, kids, house, etc. Even this tool I use literally every day is way down there on the priority list, so I just can't justify spending more than $100 CAD on a nostalgic toy. Cost aside, realistically and ideally, I would actually prefer an all FPGA board that uses SD card storage, because... It won't suffer from the issues associated with software emulators. It will run software as it's intended to be run. It's perfectly fine for programming new software. It's small enough to mount inside a custom chassis I could build around a nostalgic-looking usb keyboard that I already own. I just can't see myself ever actually using any of the expansion features of the full sized X16, but if I did sometime in the distant future, I could always upgrade at that point. At this point in life, I am content to fart around with QBasic 1.1 in DOSBox, as far as my computer programming hobbies go. I do this because it's convenient, it's very nostalgic for me, and the limitations, flexibility, and static nature of the environment make it easy to break projects down into small pieces that don't over-utilize my time. Programming is to me as Sudoku is to others. That said, it would be nifty (and perhaps more motivating) if the stuff that I made might actually be used by another human being, so that's where my interest in the Commander X16 lies - moving to a platform that isn't hugely complex, isn't dead, and is its own neat thing. Being that I prefer programming in BASIC, I looked into getting a Colour Maximite II, but after import fees and what not it would have cost about $190 CAD for just the board. For some cost perspective, my Gen1 Lenovo 100e Winbook only cost us $260 CAD new and that included a Win10 Pro licence which retails for $180 CAD (not to mention the 4 core Intel CPU, 4GB DDR4 2133RAM, and 120GB EMMC storage). As crappy as said Winbook is, it can emulate everything up to a Pentium 75 just fine. Really, the selling points of the X16 for me are the top three points I listed above, because otherwise I already have plenty of old computers I can emulate and program with. I really like physically using the 100MB Zip drive and 3.5" floppy drive in my Compaq Deskpro 4000 (cost me a whole $25 back in 2002), for the sound and feeling, but in a practical sense I need that desk space for other stuff. So the Deskpro lives in the "underhouse", only to be used for occasionally testing software, and I just emulate everything else with my desktop (or my crummy, yet delightfully portable, laptop). In summary, Do I need an X16? No. Do I want to assemble one? No. Why don't I want to assemble one? First, I would have to buy a lot tools that I don't already have. Second, I have shaky hands that aren't well suited for soldering. I can solder, I have a Weller and a life time supply of rosin core solder, and I don't mind doing it, but I can't do well and I can't do it a lot and that means it's not something I enjoy doing. So why would I buy the cheaper FPGA version of the X16? Ultimately, to be part of something in a way that suits my capacity and my desires. I hope this helps. Maybe I am just one crazy old man, but perhaps there are others who feel similarly. Who knows! Take care and thanks, to all involved, for all of your hard work.
    3 points
×
×
  • Create New...

Important Information

Please review our Terms of Use