Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 08/28/21 in all areas

  1. NO. Wrong, and wrong. It is universal, in that it's designed to handle nearly any type of peripheral. It was designed to replace nearly all of the ports on the back of the computer, aside from the video and network port, and it does a pretty good job of that. You can actually build a fully connected, modern PC with nothing but USB ports now, so it is absolutely "universal" in the sense it was intended - that it can replace all of the external interface ports - even video. I have a monitor, network, keyboard, and external hard drive connected to my laptop through a single USB C port... it doesn't get much more "universal" than that. As to being "serial"... Yes, it's serial. RS-232 is hardly the only serial format out there, and it's completely incorrect to say something is not "serial" just because it's not RS-232... when you count synchronous protocols and protocols like I2C and SPI, there are dozens of serial protocols available for specific types of connections.
    6 points
  2. Version 1.0.0

    30 downloads

    I just started assembly programming last week and this is my first project after about three days of work. I hope you enjoy it! The effect isn't quite complete yet but for now its all I'm able to get working.
    6 points
  3. 26 downloads

    As has been pointed out recently there is tooling for the X16, especially in terms of trackers. There have been a few great examples of music on the forums, either playing a Amiga\C64 mod, or via a X16 tracker. And these are great. That said, I did think maybe the community was missing a trick. If the goal is to make music for the X16 do we need to be able to run the tracker on it? Doesn't that make writing everything harder? If you have a modern machine, it would be easier and quicker to create a tracker on that. UIs are easy. MIDI keyboard integration is a mere nuget package away. Can hand edit json files if you want. IO is trivial. That's not to say writing a tracker for the X16 is wrong, it's just a different goal. So that's what I did. Apart from the emulation of the X16's PSG which took a while to get going, it wasn't so bad to do -- WPF aside. I've ended up with an application which lets me produce X16 music. It can export an .asm file which can be imported into ca65, making integration into a project really easy with just two calls. It only uses single digit worth of cpu lines and 32 bytes in the ZP, so is pretty lean. That said, it does not yet support PCM audio not commands. The music from file attached is sourced from part of a demo file that comes with FamiTracker. What did occur to me while doing this, is that VRC6 ( https://en.wikipedia.org/wiki/Memory_management_controller#VRC6 ) music is pretty damn good. In fact I'm sure a player for .ftm files could be written. (Given how long it took to get just the first 3rd of a demo file working, I might write a pattern importer myself..!) For me, the audio quality demonstrates that Vera's PSG and some form of PCM is all that's needed for audio on the X8/16. (Sharpen your pitchforks!) It just needs to be a bit louder! What next? Like all projects that have gone from 'Proof of Concept' to 'Production' in one step, has resulted in some of the code being a bit crap. Especially on the WPF side! If anyone is interested, I'll try to shore the code up and will post with an explanation of how it works soon. For now the display shows the four counters. Counters for Frame, Line, Pattern, and the Next Line. Source is the VRAM address (I use VERA to stream out the data for the patterns, as it makes life much easier. I can't understate how useful this feature is.) The bottom table is: VERA registers Address of the instrument data Instrument Position Command Note Number Instrument Repeat Command 2bytes Parameters
    5 points
  4. Integrated the newest Conerto into the tracker! Copy/paste still doesn't work But I did consolidate down to 16 synth channels (and 1 DPCM) for now. This makes each 64 row pattern a bit over 5k and allows for either perhaps adding more effects/channel down the road or allowing for up to 96 row patterns (for 6/8 timed songs as I tend to prefer using rows of 96 vs 48 for those). This means old songs won't load right. Given the fairly alpha state of CT I'm opting not to worry about that all that much at present. Of course I still want to get copy-pasta working but it's honestly not my favorite thing to do This, plus the timing of the X16 being a bit uncertain has me not in a crazy hurry. On that note though, since @The 8-Bit Guy is working on his tracker, I will be renaming mine since his definitely deserves the CommandTracker title assuming he wants it. To fit with Concerto and the starting-things-with-C idea, I'm thinking of alternatives such as Crescendo Tracker (which I think might already be taken?) or Contra Tracker. But I might do something entirely difference. Maybe Xtreme Tracker (to keep with the 'X" theme) - I dunno. The name is a minor thing. Anyways huge props to @kliepatsch's work on Concerto there. Well worth checking out as it does basically all the heavy lifting and really shows what you can do with the hybrid PSG + FM sound. Fantastic work!
    5 points
  5. I was browsing around and decided to revisit the Nintendo Gigaleak from last year. I had stopped following when a later release had come out including archives of Koji Kondo's original uncompressed samples used to make the music for classics Super Mario World, Zelda A Link To The Past, etc. Well, fast forward from there, and a guy "The Brickster" has released 'remastered' soundtracks of several games, made using the original uncompressed samples. Here's a link to the Zelda playlist - it's amazing to hear this Note, these videos have been posted for a little while, so it's not that this is "breaking news" but I thought that this would be interesting for anyone here who wasn't aware of such things' existence (like me)
    5 points
  6. To be honest, I've been following this project only casually since it started. When this thread got posted someone said something to the extent of "don't complain about hardware limitations for software you haven't even written" -put up or shut up basically. So I watched SlithyMatt's videos, compiled the emulator, and got started on a game engine. I've been having a blast putting it together, but the learning curve is steep and it's going to be a while yet before I have something worth posting. I imagine there's a lot of people right now having fun tinkering with the emulator but with nothing concrete finished to put in the downloads section.
    5 points
  7. I've uploaded a new version of X16 Edit (0.4.0) incorporating some improvements of the program I've been working on during the summer and this autumn. It's nothing major, mostly fixing small things in the user interface not working perfectly
    4 points
  8. Version 1.0.0

    18 downloads

    Got a day to kill with your X16? Run this BASIC program and generate this 256-color fractal plot. It's zoomed into a deep part of the Mandelbrot Set that is particularly pretty. This plot does up to 355 iterations and is within an area where all points require at least 100 iterations, so the whole 256-color palette is able to be represented, from white for 100 iterations to black for 355 iterations or more. For fastest results, run in "warp" mode with your emulator: x16emu -warp -bas x16-mandelbrot-vga-fancy.bas At 8Mhz, this will take literally all day, but if you have a beefy enough host for your emulator, it can be cranked out in a couple hours. Enjoy! From: https://github.com/SlithyMatt/multi-mandlebrot
    4 points
  9. Now it's time to see just how much power the X16 has:
    4 points
  10. As promised, here is a quite a big update to Concerto. The most notable changes are: Concerto is now licensed under the BSD-2-clause license: You can use it in your own open AND closed source projects! The YM2151 is now integrated into Concerto. Freely combine VERA-PSG and YM2151 to create your sounds! You can even modulate the pitch of the YM2151! Reduced number of PSG oscillators per timbre from 6 down to 4 for lighter memory usage. Load/Save named single timbres and banks (a bank is the entirety of all 32 timbres that can be loaded at the same time). Filename editing made possible by adapting code from the awesome VTUI library made by @JimmyDansbo Factory sounds are included (load bank "FACTORY" from SD card to view them). Internal optimizations, the PSG sound slightly changed compared to previous versions. Cleaned up UI from unused stuff I have NOT added support for the YM2151's internal LFO. For the time being, Concerto's own LFO can at least do vibrato, even though it doesn't sound as nice as the native LFO (I guess), but let's keep things simple for now. The last things I want to add before going v1.0 are automation of volume and vibrato (similar to the already implemented pitchbend). Unfortunately, I haven't gotten loading of FACTORY.COB (the sounds that come with concerto) in the "Try it now" section to work. It works flawlessly locally with an SD card image loaded. I have read that the filename extension must be whitelisted in order for it to work. I read that ".SEQ" and ".PRG" are okay. I have also seen ".BIN" being used successfully in the Web emulator. I have tried using ".BIN" earlier today, but with no success. I am using the Kernal routines to load and save. Maybe I am doing something wrong there? Do I need to set the secondary address to a specific value for it to work? If you have an SD card image loaded into your emulator, and the FACTORY.COB file is on there, you can enter the file name "FACTORY" in Concerto (no extension needed, Concerto adds that for you) and click "LOAD BANK". Then you can view all the sounds that I made so far.
    4 points
  11. The busy delay is incurred after each and every write to the YM data port, not just KeyON/OFF. I worked with @StephenHorn on the box16 emulator project while he was refactoring that emulator to use the new BSD-licensed YMFM core library. I've learned quite a bit about how this chip works. R38 has several inaccuracies in the YM implementation - the core it uses does not emulate the busy behavior at all. You can bang away on it all day long and it won't skip a beat. The library just handles it. Furthermore, I don't think the IRQ functionality is emulated, and I also think the timer behavior might not be implemented either - I'll go re-test this and let y'all know... Box16 has extended the YM support in several ways - it supports YM IRQs as well as busy flag behavior. Some of this has been a matter of the group's interpretation of other example code and/or the official YM2151 application manual. In other words, the current behavior in Box16 is our best guess as to the real behavior. Stephen has done an excellent job integrating this code and dealing with a colossal time synchronization nightmare, by the way. Kudos to his hard work! One of his decisions was to make these "enhancements" be disabled by default to maintain functional parity with the official emulator. They are activated by command-line arguments. Interestingly, when testing the accuracy improvements, one of my VGM playback routines went nuts and played an entire song back in less than 1.5 seconds. It turns out that the original VGM data stream contains commands that enable YM IRQs. My player just used WAI as a poor man's IRQ handler to wait for VSYNC. Thus it mistook these YM IRQs as VBLANK IRQs. The player was built to read the busy flag though, and even with strict enforcement of the busy state, the player doesn't drop any updates, so that seems to work properly. After removing the IRQ enable messages from the VGM, it plays back perfectly on Box16 even when it enforces busy flags. Real Hardware? The big question is how will this work on the real thing? As I said above, the behavior is currently our best guess based on other sources, none of which being real hardware. One thing I can say is that @SlithyMatt's Chase Vault game works on real HW, and the game's YM routine uses busy flag reads to ensure that it does not write to the chip when it's busy - so that's a good sign. Beyond that, I've sent a basic read test program to Kevin, as the YM reading functionality has never been subjected to testing on X16 hardware the way writing has been. So far, the "hello world" results are interesting. Kevin's only been able to test at 2 and 4MHz which the math says should work just fine on YM. 8MHz is the really important one, but as the system is currently experiencing other 8MHz-related problems, Kevin wasn't able to test at 8MHz. In short - the test program successfully read IRQ status flags w/o any errors at 2 and 4 MHz. Interestingly, the busy flag read test never observed the flag's having been set, but I think there might've been a bug in my code. I'm personally convinced that the write delay specification is actually a little bit different in reality than you might expect from reading the application manual. That is, I strongly suspect that the "64 YM clock delay" is not a minimum but a maximum. The data sheet definitely has other errata, and I'm convinced this is just another example. I have a real YM to test with, but don't have everything lined up enough to be able to put it on a breadboard and do real testing just yet. If I can get that done, I'm definitely going to poke around with the real chip's busy state flag to see what makes it tick. YM and write performance / overhead: As for writing performance with the YM, I'd like to point out that in my experience with generating byte streams of PCM writes and FM writes, the FM music data streams are much smaller than the PSG streams. This is completely to be expected. That's because the FM chip does so much of the modulation in hardware that you don't need to update it nearly as often to get decent-sounding music. PSGs must be constantly modified for every little thing, be it pulse width modulation, vibrato, etc - all of which is done in hardware on the FM chips. Consequently, you end up performing SIGNIFICANTLY fewer writes to an FM chip than you do a PSG over the course of a tune. Still, sitting around for ~144 clock cycles waiting on the chip to finish chewing the last bite is not ideal. I believe one way to handle YM writes may be to queue up the writes into a ring buffer, and have an IRQ that empties the ring buffer. You can set the YM's timers to run a little slower than the actual rate the YM could drain the buffer in order to cut down on the IRQ overhead. This would have the effect of spreading the load evenly throughout a frame if that's what you'd like to do. Kevin has confirmed that the YM2151's IRQ line is indeed connected to the system, so this should be doable on the real system.
    4 points
  12. I just saw one of these deksop racks on Amazon: And it looks exactly the right size to mount something like a Kaypro II style monitor and disk drives. Now while I'm not really big on floppy drives at this point, I could picture a 7" monitor mounted on the left side of the box and maybe a couple of slots on the right for USB drives or memory cards. Pack in a Raspberry Pi or a MiSTer in the back, with a custom cut panel with a fan, power, and data connections, and you could have quite a convincing retro computer.... I've actually been wanting to build a fake Kaypro II for a while. I almost bought an empty case a while back, but I felt like the seller was asking a bit much for just the metal enclosure. With the terminal program I'm (re)-writing, I feel like this would be a good fit for a CP/M/SX-64 retro emulation machine. What do you guys think? Does anyone have the resources to work with metal to cut out holes for the rack mount panels?
    4 points
  13. I think there's a lot more development going on than is visible in the downloads section. Personally, I have a number of little prototypes that I've been working on here and there, which I haven't posted in downloads because I don't think they're ready, and since there's no release date for the X16, there's no rush. (Here's one I've been poking at for about a week, along with the source code, if anyone's interested). Honestly, I think there's no rush in general! The development community around the X16 seems (to me, at least) to be alive and vibrant and going strong. Yeah, the project has taken a little longer than expected, but I don't think the community will evaporate if nothing is released soon (or even for another year or two). If anything the community will just continue to grow! I don't think the project leads should feel pressured to get something (like the X8) out the door, just for the sake of getting something out there.
    4 points
  14. You can: https://www.wasdkeyboards.com/commander16-by-the-8-bit-guy-87-key-custom-cherry-mx-keycap-set.html
    4 points
  15. Hello, my name is Lotts. I'm from sunny Scotland! About a year ago I fell in love with fixing up ZX spectrums I bought cheap from Ebay and from there the hobby has just kind of grown. I'm not a great ASM coder (or even basic for that matter) but I want to learn and have some fun along the way! when I heard about a new system being developed similar to the C64/VIC-20 with minimal FPGA I thought it sounded to good to be true and wanted to explore it further. Some of the demos people have already released are amazing and I look forward to seeing more, and hopefully one day make some of my own. I wasn't actually born when the C64 (or ZX) was released and my first experience of it was the 30 in 1 TV console that Jeri Ellsworth designed, and I got hooked playing Uridium. My first computer was an Amiga 500, but prefer playing about with 8-bit machines mainly because A) I'm a bit of a noob and I find them easier to understand, and B) If I do break a ZX spectrum or clone machine, its easier to troubleshoot what the issue could be and Amiga parts are expensive now! anyway, wasn't really sure what to put here so I hope this is sufficient!
    4 points
  16. I want a development system. Shut up and take my money. PM me as soon as you have one available to ship.
    4 points
  17. 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 20th 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 :).
    3 points
  18. 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
  19. Latest update - "final" VIC-II Kawari board is ready and Randy is looking for beta testers - Go check the video here. If you haven't, go look at the previous videos - I especially liked seeing a nice 80 column mode on a C64.
    3 points
  20. You're completely missing the point. The C&C hardware that makes PCBs today uses vector data files. There's no accepting of image files, because the systems don't support image files. The whole point of the Gerber file is that this is the format the hardware needs. That's not companies being "stubborn". That's simply the only way they can make a PCB. Honestly, if the guy can make a "no code computer", he can use KiCad. I don't get the stubbornness.
    3 points
  21. I went ahead and bought a C256/U Rev B. + the SID / Ethernet add-on. Despite the base having a Gideon SID built in, I'm a sucker for SID and will pry SIDs out of my unused SX-64 and 128 then code a multi-SID tracker using 3 'SIDS' as a first project. Took a very long time to get through the web site / options, Discord threads, Twitter feeds, and many (but not all) of her marathon videos dating back to the earlier products. Stefany is a one-person wrecking-ball with undeniable experience when it comes to HW design, knowing how to get fab done, sourcing parts, etc. She only cares about two things... everything Foenix ("being able to produce cool f'ing sh* that will inspire people") and being able to pay rent a distant 2nd. Commentary about not worrying about where she will be in x years is hilarious and she has a number of really talented people delivering incremental piece-parts code etc. Mostly, she seems to really have great instincts about what not-to-include and why not to go down a particular path, this sometimes paralizes group-think and design by committee efforts. Similar to @John Chow Seymour, I'm still watching what is going on here, but Foenix has already shipped and is going to ship the latest efforts in the next few weeks; it's just too appealing to pass up so if you haven't been there (understandably, it takes a fair amount of time/effort to read it all), have a look at the C256 or the A* if that platform appeals. Based on the experience I'll probably be signing up for the Gen X. also once it gets closer. The 68K and enough resources to code in C "for fun and for profit" will be very appealing down the line.
    3 points
  22. A ridiculous brainstorm: lead your videos with the headlines / bottom lines. The 15 minute "here's what happens". Then the 60 minute deep dive. One video, formatted for two levels of interest?
    3 points
  23. I'm honestly somewhat torn between what tower or desktop... While I like the look of slim sleek cases, I am also "under the hood" all the time on every build I have ever done, I don't see the X16 being any different. So I like cases with lots of room inside for mods. Also, it has to fit in my workspace. I have a feeling I will be going with an ATX full or mid-tower of some sort. Maybe even a glass side panel so I can see the hardware! Unless I find a desktop I really like. I have pretty much abandoned my original retro look idea, and will probably be going with something more modern where I can add "retro style" to it on my own. The search is still on! Edit: I was actually looking at a case I have built in before, and liked it. The Rosewill Zircon T: https://www.ebay.com/itm/293431402500?epid=3034551967 I want a plastic front panel with at least 1x 5.25 bay, and with enough room behind the front panel I can add my own connections, LEDs, and toggle switches, and other I/O, and that case fits the bill. The only downside is the HDD/SSD tray at the bottom is not removable, so I would have to grind down the rivets to get it out. Not a big deal, but I don't need or want the tray in there. Plus, it will easily fit in my workspace, right next to my desk where my server sits now.
    3 points
  24. Ahead of you, but ther more the merrier. https://github.com/paulscottrobson/6502-basic/blob/main/basic/sprites.bas
    3 points
  25. Hi, A while back, I created an overview of the 65c02's registers, the most important mnemonics and the relation between them. Now, this presentation is far from perfect, but it may help you as well. Enjoy! Register overview.pdf
    3 points
  26. Of course, self made licenses are legally binding. Remember that Copyright is "all rights reserved" by default, and a license grants permission. CC-BY isn't used for software, because software has separate expressions for source code and executable code. Since the binary distribution and source distribution are often licensed separately, different licenses are needed for each. Having said that.... If I read your intentions right, the BSD 3-clause license is basically what you want. In short: people can re-use, modify, and distribute your work, as long as they give you credit. For the most part, a Copyright notice needs to cover Who created a work How downstream users may use or distribute the work Whether modifications are allowed A disclaimer of warranty and liability. It's important to note who created the work, as I see a lot of FOSS programs out there without any way to contact the author. That makes it impossible to do certain things, and if the work has no Copyright notice attached, you can't even legally copy it. So at the very least, put in your name and a stable e-mail address. (I've had the same GMail address since 2005, so I consider that stable enough.) I think that covers everything I'd be worried about. I'm not a lawyer, so of course take this as the free suggestion that it is. Especially the "no liability" part. Here are some links to FOSS licenses that may also help: https://opensource.org/licenses/BSD-3-Clause https://www.apache.org/licenses/LICENSE-2.0 https://unlicense.org/ I'd at least look at the text of the Apache and BSD licenses, then decide whehter to simply use one
    3 points
  27. Super Castlevania 4 Tunnel Effect View File I just started assembly programming last week and this is my first project after about three days of work. I hope you enjoy it! The effect isn't quite complete yet but for now its all I'm able to get working. Submitter randomcardboardbox Submitted 09/07/21 Category Demos  
    3 points
  28. Stopping the channels before repeating a song is a good idea. I will change this in the next release together with the possibility to stop/pause the music. Indeed more effects have to be implemented as a lot of mods sounds ugly without them. I'm planning a code clean up and some documentation to put the code on Github so the community can help to improve the player.
    3 points
  29. I fully agree on this! The X8 then would be a X16 light... The effort to support both would be minimal. Actually all X8 software would run on the X16 unchanged - no recompile required. That should be the goal.
    3 points
  30. That part is true. The IIC sold for $1200 new. Regardless, Apple worked on building better computers, rather than racing to the bottom. And where Commodore eventually failed, by trying to build cheaper computers and compete with video game consoles, Apple and PC makers succeeded by making computers faster and more powerful. I think it's obvious what the winning strategy was, in the end, since out of Apple, IBM, and Commodore, only one of those companies no longer exists...
    3 points
  31. Yeah, but that's only going to be a small part of the user base for a system with millions sold. If the Z80 has been dropped in favor of the 65816, then it would need a new name, as it would no longer be CP/M Plus compatible. If it had 256KB base RAM and 64KB 80 column video RAM, it could be the Commodore 256. Or the Commodore 320. That would also make the geoRAM access of the extra RAM in legacy 6510/C64 mode 192KB, rather than a mere 64KB, so, eg, able to hold a 1541 disk's worth of data. It would be an even bigger selling point if as you mentioned the "C256" allowed the easy addition of extra internal memory modules, and those also could be accessed geoRAM style in C64 mode, so that someone with two 256KB internal RAM expansion modules would have the equivalent of a geoRAM 704KB expansion. There would have been a possibility of a virtuous loop of C64 programs taking advantage of geoRAM memory expansion, which would then help sell both more geoRAM cartridges and more C256 systems, which would increase the install base to run C64 programs that could take advantage of geoRAM. And the 65816 replacing the z80 with direct banked access to the extended RAM would have been a shorter learning curve for 6502 programmers used to programming for the C64 ... but then again, Jack Tramiel would never have gone for a CPU that he had to pay a license fee on for every unit sold. As he said, he got married once, he didn't intend to repeat that in the computer business. But I've seen the time travel movies ... if someone goes back and Ghost of Christmas Future's Commodore into phasing out the C128 in favor of the C256, and pushing the cheaper geoRAM memory expansions for the C64 over the more expensive (and more capable) REU's ... then that will change some detail of somebody's childhood in some way, and half of us disappear because of the nuclear war of 1998.
    3 points
  32. A computer case made out of rolled steel? But think of the children!
    3 points
  33. 3 points
  34. Some of what you're stipulating is impossible: you can't make a machine fully compatible with the C64 without the "special" mode. Otherwise, Herd would have done just that. The same goes for the 121 color palette. That was part of the TED chip, and incorporating that into the VIC chip might have been possible, but it would have further eroded compatibility. The problem with the 128 was that they were trying to make an 8 bit computer compete in a 16 bit world. Commodore really should have either fully embraced the Amiga or released the 128 as a 68K PC. Either way, I feel like the biggest mistake with the 128 was making yet another 8 bit computer. So what I would have done is not bought Amiga Inc and instead: Built a 68K based system with modern Centronics parallel port, 2 serial ports, and parallel IEEE support for external disk drives. High resolution video interface standard, with TV and composite as backup options. Put this in a PC sized case with multiple internal expansion slots. Hard drive option. From day one. As part of the standard boot sequence. Build a 64-on-a-card to allow backward compatibility with C64 software BIOS like system, instead of OS or GUI toolkit in ROM. Keep the 64 as the "cheap computer you hook up to a TV" and add the 128 as the "Commodore PC" that would have squarely taken on the Mac and PC as a productivity machine. I don't know that it would have saved Commodore, but it would have been a better machine than either the Amiga (which wasn't designed by Commodore at all) or the 128 that we actually got.
    3 points
  35. "I just checked the downloads section for a system that doesn't yet exist except as a few prototype boards and an emulator, and it didn't look like it was enough to sustain a platform." Man, I'm guessing you are a glass half empty type. A few thousands sold and what I take it is a few dozen hobbyists releasing software on an ongoing basis for a few years (since a few dozen releasing at least one application of some sort has already been passed) would not actually be "the whole thing kind of goes nowhere", it would be a nice little hobbyist system. This is the level of success where the worriers among us would be worried about fracturing the software ecosystem between the X8 and X16 families. Sure, the hope would be 10,000 or more sold. A hundred hobbyists or so releasing software on an ongoing basis for a few years while it is a thing, and a few dozen releasing software on a longer trajectory is more like what it would be aiming at, as that would be a level of success that would sustain repeated production of batches of the different systems in the product line. I don't really think the division of the ecosystem between the X8 and X16 is a serious problem at this level of success, because where it's practical to port between the two, there will be a lot of ports ... indeed at this level, the FOSS applications that are popular on one system and practical to port are going to get ported (though possibly not by the original developer). But the idea that the current selection in the downloads for a system that hasn't even started its crowdfunding campaign yet, let alone shipped, is representative of what it will be on delivery day seems like you needed to arrive at a "oh, this current system isn't going to work" conclusion as the launchpad for the proposal you wanted to make. It's hard to see how an app store can beat the download store at this site for ability to maintain both a FOSS ecosystem and a platform for Patreon/Indiegogo retro developers. The key thing is not just that everything is free to download, but most things can be tried in the browser before downloading. After all, what Patreon/Indiegogo retro developers are going to be putting up are their free teaser versions, and the lower the barrier to entry for trying out the teaser version, the greater the likelihood of attracting patreons or backers. Fracturing the software ecosystem with an app store for paid apps and the download store at this site for free try-before-you-buy downloads is recreating the very problem with the healthiness of software ecosystem that the download store is very well designed to prevent. As far as people building their resumes to become a consultant ... it seems unlikely that this is for that stage of the process. This is for earlier in the stage of getting your feet wet with putting your code into public for others to see and use, in a community that is supportive of newbies and forgiving of newbie mistakes. I reckon that if somebody after some successes with some weekend development projects in this space decides they want to pursue that path, they really would be ill-advised to stay in this space for their resume building. _______________ This is the key point. A free download site is the only system that can work as a central point of contact ... with paid options connecting into it via free teasers. In competition with that, an app store is going to have a relatively small share of total system owners participating, and it's highly unlikely to be viable. This app store idea seems like an effort to transport experience outside of the retro niche and bring it in, but between the development team and others whom David is in regular contact with, there was quite a bit of retro niche experience that stands behind the design of the download platform and the decision to do an early release of an emulator long before the design was even close to finalized. An app store has a comforting "what people are used to" feel to it, but beyond that it's not a great fit to this market niche.
    3 points
  36. By the way here is Perifractic's video on the subject.
    3 points
  37. I've had another thought that makes more sense to me personally. I just posted it on the YouTube video but wanted to bring it up here. Another idea: What if Commodore wanted to make a cost reduced console game system at some point. Maybe they'd call it the C64GS. Oh, that really happened? #haha Omission of a keyboard would certainly fit the bill, and replacing it with a keyboard free shell that could be painted or have a large sticker applied to it or some such would not be a bad idea. Having it retain the notches for all the ports would be simple if it were derived by modifying the keyboard half of the shell. Presto! Price reduced C64. The slots in the top of the shell could have been for potential future expansion (mating points for an optional keyboard) or an "expansion chassis that included a floppy drive, or just a place to put a monitor as has been demonstrated. After using it to do proof of concept work, they eventually went with the alternative case for the actual C64GS that was shipped. The fact that the top shell on the lower half happens to be usable as the bottom of a stock keyboard seems a "happy accident" that allowed prototypes to be used for some other purpose. The width of the slots at the back of the shell seem to correspond to earlier breadbin models that had different size tabs for the keyboard part of the shell. This would indicate it was an earlier experiment from closer to 1982 than the late 90s for a C64D. Given that the notch that fits above the joystick ports doesn't quite match with the bottom half, it would be interesting to take it and compare it to an earlier breadbin model and see if it was a closer fit to that case, as the different breadbins evolved slightly over time as shown in an 8 bit show and tell video.
    3 points
  38. It's not all that radical, since it's part the original plan. That is the "phase 3", also known as "X16e". The market for the X16p/X16c exists because of people who WANT the "authentic" ASIC parts. So the X16e is not "instead of" the X16p or X16c, but a lower cost alternative to those boards. Putting all of it except for a RAM chip inside an FPGA was the plan for the lowest cost member of the family. To do that, it has to be a larger FPGA than the one that is used for Vera in the X16p. AFAIU from the Foenix256 project, an FPGA core for the YM2151 exists, so it seems like it wouldn't be a serious issue including it. The point of the X8 is that it's not perfectly compatible with the CX16, but it fits in the same FPGA that Vera uses and doesn't need any external RAM, so it would be about half the price of the X16e. So if the X16e costs $90 for the board, the X8 would cost $45 for the board.
    3 points
  39. I'm thinking about something similar for the mATX board:
    3 points
  40. 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.
    3 points
  41. But you can see a progression, from early toy rockets, to the V2 to the Sputnik and similar through to manned space craft. The CPU is feasible. there are 2/3/4 chip bootable designs out there, but I find the idea of a cheap board from standard parts that's more powerful than Vera (128k RAM, multiple bitmap and character modes, 12 bit colour and umpteen scaled sprites) out of bog standard parts (presumably not things like the MSX2/2+ chips) a bit implausible. You can fake such more cheaply (so you can fake sprites using memory with palette tricks for example) Almost every video system seems to fall into one of two categories. The old hardware designs, which Vera is, albeit heavily upgraded, or those generated on the fly by a CPU (2600, RCA1861, ZX81, Galaiksja type machines). Classic hardware designs, so counters, timers, memory and so on tend to be expensive and complex to build, which is why the CX16 has Vera in the first place. I suspect that the team would have liked video to be generated using a 6845 RAM and TTL which was possible in those days, though none of the C64, VIC20 or 16/+4 did that, but rapidly realised that while technically possible it would be an enormous expensive to build circuit board. Even on something as simple as a ZX81 it when down from 20 chips to 4. I'm trying to think of a machine that had graphics beyond the basic (e.g. PET/TRS80/Ohio Scientific style character graphics which used a character ROM so didn't have complex RAM access requirements) that didn't use a proto ULA or a dedicated chip (6847 or 99x8 mostly) and struggling. Apple II perhaps with its eccentric colour scheme ? Spectrum, BBC, Oric all used ULA chips as well. The nearest I can think of OTOMH is the Jupiter Ace which had 32x24 character graphics that were redefinable, though not sure if this worked outside VBLANK and was monochrome. At 800x600 SVGA ?
    2 points
  42. As s continuation to the industrial use case scenario, not all industrial environments are dirty. In my case where we had done things like this is the past, the killer was moisture, not dirt. The Filler Room environments in many beverage production facilities are very cool wet areas. All electronic or computing equipment had to be sealed in an expensive stainless steel enclosure to survive, especially during the cleaning process. There were many instances where we had to run keyboards and/or mice/trackballs into the rooms from computers we setup outside the room for special runs, or as temporary solutions to a problem that popped up with the normal equipment. In some cases, we would put the computer in one of those stainless boxes even though it was not made for it, and run the HID devices out from there. In those situations, the computers were not in their original cases, we had taken all the internals out and mounted them inside the box to fit. We would make "adapters" and trays to attach the components to, often out of Lexan, so they could be mounted in the sealed stainless enclosures properly. As one last example of not all industrial environments are dirty, a friend of the family worked for a company called Jagemann Stamping, it's metal stamping. They make a lot of things there, including ammunition. Sounds like it would be a dirty environment, but the place is incredibly clean. Still, computers are isolated from some areas to minimize the chance of damage if there's an accident. It's a lot cheaper to replace a keyboard than an entire system.
    2 points
  43. Wow, so I downloaded their CAD program and created a simple face design. Honestly, the biggest obstacle for me was the idea of having to learn a compatible CAD program, but this program is super straightforward. It’s still a bit pricey, but a front panel with enough cutouts for 4 USB ports, a headphone jack, a power switch, and the display runs about $94.
    2 points
  44. Version 2.1; 1.0; 0.2

    14 downloads

    This is a single program listing that contains three different versions of the Proteus Demo from my thread in HOWTOs on converting and optimizing BASIC programs. Version .02 was from very early in the conversion/optimization process from that thread and, consequently, is quite slow. Its also got the original author's bad scaling coefficients, which make the output look a little gnarly. Version 1.0 was originally what I thought would be the 'fully optimized' version, with all sorts of things (documented in the thread) done to squeeze out better performance. And of course the scaling is fixed so the output looks better. This was supposed to be the end of the thread, except that... Version 2.0 takes advantage of something I noticed about the calculations, which led to the idea to have the program start off by precomputing a table that allows us to avoid having BASIC redundantly performing a bunch of the most expensive operations in the program. Even considering (and counting) the over minute-and-a-half it takes to initially compute the lookup table, the trick resulted in nearly halving the time to complete plotting the output compared to what was the previous fastest version. (Of course, I now wonder if some of the better math and coding gurus have been rolling their eyes all along, just wondering when, if ever, I might figure this part out...). Just RUN it and pick A, B or C from the menu. When its done plotting and puts up the elapsed time (its in HHMMSS format) you can press any key, and it will 'LIST' the program lines that correspond to the version that just completed plotting. I hope folks find it helpful having the three versions (and the howto thread) in terms of seeing how the thing evolved. You will notice that the more tweaking you do for speed, the more opaque and confusing the program becomes in terms of ever expecting someone with fresh eyes to try and see what the heck is going on. That 'early' version is included, in part, because its much easier to follow than the others. More info at the thread here:
    2 points
  45. Here's my attempt to make side-by-side comparisons of the Commander X16, C256 Foenix, and Mega65: Commander X16 C256 Foenix Mega65 CPU WDC 65C02@8.192Mhz WDC 65816 @14.28 Mhz, Choice of extra CPU Options (256 GEN-X and Above, not relevant to this comparison) Custom FPGA Core based on the MOS Technology 4510@40 Mhz System RAM 560K Standard (48K Low RAM, 512K High RAM), Maximum of 2 MB available by populating all RAM sockets. Memory Map presumably can address up to 2,112K Total Up to 64MB Standard (System can address no more than 8 MB on 65816 power alone), 2 to 4 MB on Foenix U/U+. 512K Standard, Maximum of 8MB available by populating all memory slots, CPU possesses 28-bit address bus, capable of addressing up to 256MB GPU VERA, Separately Addressed Video RAM, 128K (Memory resources shared with PSG and PCM audio subsystems) (*) VICKY II/III, Separately Addressed Video RAM (4MB VICKY II, 8 MB VICKY III) VIC IV, Video RAM Space within larger System RAM can be remapped up to 3 MB, but is mapped to 384K by default in Mega65 Mode Resolution 320x240 (256 Colors Tile, 1024 Colors Bitmap), 320x480, 640x240 (64 Colors Tile, 256 Colors, Bitmap), 640x480 (16 Colors) 320x240, 256 Colors (65536, VICKY III) 400x300, 256 Colors (65536 VICKY III) 512x384, 256 Colors (65536, VICKY III) 640x480, 256 Colors 800x600, 256 Colors 1024x768, 236 Colors (VICKY III Only) All resolutions from VIC-20 and Commodore 64, Plus 360x288 (1024 Colors 256 Color Sprite CLUT) 400x300 640x400 720x576 800x600 (@) Sprites Maximum of 128 4-bit pixel (16 color) or 64 8-bit pixel (256 color) sprites. Sprite size programmable up to 64x64 pixels. Maximum of 32 sprites per scanline (16 8-bit pixel) Maximum of 64 32x32 pixel sprites. No Scanline Limits, bit width per pixel unknown Maximum of 2048 4 bit-per pixel sprites at stock memory configuration in Mega65 Mode. Sprite size programmable up to 32x32 pixels, but defaults to the stock Commodore 64 12x23. Maximum of 32,768 sprites when all memory slots are full Fields Maximum of Two Tile Fields, or one tile and one bitmap. Bitmap field lacks scrolling registers and must be scrolled through CPU power alone, but is split into quadrants each with a separate CLUT Maximum of 4 Tile Fields and 2 Bitmap Fields Choice of one Tile or Bitmap Field through conventional means, but judicious use of the Raster Rewrite Buffer can permit an arbitrary number of apparent scrolling fields. Other Features VideoDMA with Blitter Functions, Enhanced functionality and bandwidth in VICKY III DMAgic Video DMA+ Raster Rewrite Buffer effectively produce two different extra blitter methods at the same time Master Palette 4096, four bits each of RGB 16,777,216, eight bits each of RGB 8,338,608, color generation scheme unknown Sound Chips Yamaha YM2151+YM3012 DAC, 8 Channels FM Synthesis, 4 operators, 4 possible waveforms, 16 Channels Geometry Synthesis, 4 possible waveforms 1 channel 16-bit PCM synthesis, 48 KH maximum sample rate, 4K audio buffer Yamaha YM2151+YM3012 DAC Yamaha YM2612, 6 Channels 4 operator FM Synthesis Yamaha YMF262 (Several different modes of FM Synthesis + available 5-piece percussion set), Texas Instruments SN76489 (3 Channels general Geometry synthesis, 1 channel sawtooth and white noise) X2 Gideon SID Core (6 channels total geometry synthesis, multiple filter options)+ socket space on the motherboard for two physical SID replacement chips, Red Box (CD Quality) CODEC X4 SID Softcores (12 Sound Channels total), two based on the original Commodore 64 version, and two based on the Commodore 128/Later 64 version, four available sockets on the motherboard for physical SID replacement chips. Yamaha YMF278 (FM Sound Channels from YMF262+24 PCM Channels with 16-bit sampling@44KHz, based on the Yamaha YMW258-F/Sega Multi-PCM, Successor to the SegaPCM chip used in several Sega arcade games, used in the Yamaha SoundEdge PC Sound Card and the MSX Moonsound expansion cartridge) I/O VGA Output, A/V Multi-out, PS/2 Keyboard and Mouse, X2 7-pin Super NES controller jacks with headers for 2 more on the motherboard for an expansion backplane, Commodore-styled User Port (electrical profile based “mainly” on the Commodore 64/128 version), SD Card Slot, X4 expansion card slots, based on the Apple II Standard Varies by form factor. Mid-Tower and Full Tower Backplanes have: VGA Output, A/V Multi-out, Single-Link DVI Output, PS/2 Keyboard and Mouse, X4 Each Atari CX-9, 7 Pin NES, and 7 Pin Super NES controller jacks, SD Card Slot, X4-6 expansion card slots, physical, electrical, and protocol set profile currently unknown VGA Output, A/V Multi-out, SCART out, X2 Atari CX-9 joystick Jacks with two extra headers on the motherboard for an expansion backplane. X2 USB 1.2 Ports, Commodore User Port (Electrical Profile based on Commodore 64/128), Commodore 64 Cartridge Slot, Commodore Floppy and Datasette ports, X1 3.5” Floppy Disc (&) Form Factor Horizontal Upright, Separate keyboard optional. Smaller form factor models projected in the future Choice of Bare Motherboard, Small Form Factor(roughly Intel NUC/Mac Mini sized), Keyboard Console, Mid Tower, and Full Tower Keyboard Console OS Kernal + Commodore DOS, GEOS GUI Unknown OS for 65816. Motorola 680X0 processor upgrades offered with choice of EmuTOS+FreeMINT or Microware OS/9. x86 processor upgrades offered with DOSBox+ReactOS, ARM upgrades offered with choice of some sort of Linux distribution or OpenRISC (%) Kernal + Commodore DOS, GEOS GUI Built-in Language Microsoft BASIC 2.0+additional reserved words and syntax revisions to take advantage of the hardware Unknown BASIC interpreter Based on Commodore BASIC 2.0 Commodore BASIC 10.0, Mega65 BASIC 11 for Mega65 Mode. Also not that I did not list prices, because all price quotes are currently preliminary. Notes: *: VERA's 128K of Video RAM is the FPGA's fabric cache. Video Memory cannot be increased. @: the VIC III 1280x200 and 1280x400 resolution modes of the Commodore 65 are not supported due to a lack of availability of Commodore 65-spec CRT monitors, and the rarity and expense of 2560x1600 5:8 aspect fixed pixel monitors. &: Two Atari CX-9 Commodore 64 Mouse protocol/USB dongles allegedly packed in % Full Compatibility with classic MS-DOS software stack and classic Ad-Lib and SoundBlaster support not guaranteed with x86 processor options. Full compatibility with Atari TOS/MINT software stack with 680X0 CPU option not guaranteed. Full Compatibility with classic Acorn Archimedes/RISC PC software stack not guaranteed with ARM CPU option.
    2 points
×
×
  • Create New...

Important Information

Please review our Terms of Use