Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 11/30/21 in all areas

  1. I think David crowdfunded another project (one of the PlanetX ?) and didn't rate the experience highly
    2 points
  2. You could find this topic debated hotly in that closed thread. Here were the reasons to not do crowdfunding as I recall: 1. The primary issue right now appears to be logistics, not money. Taking people's money wouldn't speed that up. Nor will increasing the the visibility of it through advertising. 2. Crowdfunding creates an obligation (at the very least, in David's view) to reach specific targets, and right now there is too much uncertainty to make any promises about the final product. The case they designed not free to the public. You are free to design your own, of course, and 3D print that for personal use.
    2 points
  3. Version 7.4.1 has been released https://github.com/irmen/prog8/releases/tag/v7.4.1 Documentation as always here https://prog8.readthedocs.io Even more improvements in generated code efficiency, resulting in smaller code that runs faster. improved code generation. optimizer is now smarter about accesses to memory mapped IO that shouldn't be optimized away performance improvements in the compiler itself, updated to Kotlin 1.6 fixed some illegal instructions in the conv module on c64 target other bugfixes documentation improvements
    1 point
  4. I think Commodore lost its vision and went nuts. Tramiel at least had a vision (and almost by definition a vision is an official business direction that other people will disagree with). Tramiel's vision again was the C16 to be that Sinclair competitor. It seems to me though that the C64 was already a Sinclair "suppressor" by the latter 80s. The C64 was the right system at the right time to "clean up" the 80s: to wipe out early competition and then mop up on the cheap computer market later. We all know the future wasn't eight bit. Even the market knew it in the 80s.
    1 point
  5. Consider working through the older Commodore Vic 20 or C64 user guide as an introduction to BASIC. Most of the simple programs should run unmodified as they are the same version of BASIC that the X16 uses. There will be some differences that will need to be considered when dealing with the hardware differences, such as screen size and video/sound memory locations. By the time you hit those you'll probably have a good grasp of the language. If you get stuck, there are people in this community who will answer your questions. Happy computing!
    1 point
  6. Definitely. If you're new to FM synthesis, I too would recommend getting access to some FM synthesizer other than using assembly or C on the CX16. I haven't tried Deflemask, but from what I have seen in Matt's video, it seems to be a good fit for that.
    1 point
  7. @svenvandevelde: If you want to play with patches, I recommend using the instrument editor in Deflemask (I'm pretty sure they still offer the freeware version). FM instrument design is definitely something that's better done by getting an intuition and feel for it more than a left-brained understanding. The technical part can definitely guide your hand, but to me, it's one of those things that you're better off just playing with knobs and seeing what comes out. You can save instruments in Deflemask to its custom FM instrument format DMP. I've made a script to convert DMP into raw register byte writes for X16. All you have to do to use them is poke them into the YM in the proper order using a very simple algorithm: (pseudocode) ym_write(addr,data) { // ensure YM is not busy, then: poke $9FE0,addr // $9F40 for R39 poke $9FE1,data // $9F41 for R39 } patch_data[26] = x,x,x,x,x,x,x,x,x,x,.... // (the 26 bytes of patch data) addr = 0x20 + voiceID // voiceID = 0-7 i.e. which voice you're patching ym_write(addr,patch_data[0]) addr = 0x30 + voiceID for (i=1..25) { addr += 8 ym_write(addr,patch_data[i]) } Assuming voice 0, the bytes of the patch should be written to YM registers: 0x20, 0x38, 0x40, 0x48, 0x50, 0x58 ... 0xF0, 0xF8 I call this format "YMP" for YM Patch. One thing I've omitted from YMP that may or may not be an issue is the operator mask to use when keying notes for a patch. OPM format also records this information (DMP files do not) - not sure how often one may come across patches in the wild that don't use all 4 operators.... Let me know if you'd like me to post that conversion script - it's a tool in the suite I'm working on called zsound, which currently has a defined music data file format (ZSM), and includes an assembly-based playback library, and an import script to convert from VGM into ZSM. (It can convert OPN chip tunes as well as AY-3 and TI SN7xxxx PSG chips as well as YM2151). Once I get more of the intended core functionality done, I'm going to release the whole thing for the community's use, but for now, I'll post the patch conversion tool if you're interested. I believe that instrument creation represents the bulk of the complexity of the YM2151. If you start with patches that sound like what you want, then playing music on the YM can be much simpler than even on the PSG, as it's really nothing more than just spooling a sequence of note pitch values and keyUP/keyDN events.
    1 point
  8. The FM synthesis on the YM2151 works pretty much the same way it works in the Yamaha DX7. The biggest difference is that the DX7 has 6 operators whereas the YM2151 has only 4. But 4 operators is still plenty of material to work with. Both modulators and carriers are "operators", and both can either modulate or output sound. In "connection" 7, all operators output sound directly, in "connection" 0, only the operator 4 outputs sound, whereas the other three are modulators. I disagree with how the YM2151's manual calls the operators modulator or carrier regardless of what they are actually doing (which depends on the "connection", or "algorithm" in terms of DX7 language). I learned FM synthesis by simply seeing examples of what can be done with FM synths and how it is done, and then trying them out by myself. And a lot of messing around and trying stuff out (making educated guesses). You could start with these two tutorials, and then search other DX7 tutorials. The YM2151 does not have all the features of a DX7, but most things can be applied to the YM2151 as well. I should mention one pitfall that has confused me when I started working with the YM2151: the total level (TL) in the YM2151 is attenuation! TL=0 means max level. TL=127 means no output. The same goes for the decay level IIRC (D1L). If you want to hear something, the attack rate (AR) should be non-zero. Maybe set it to 10 or so. Higher values make it faster, low values slower. I am sure things will change slightly. The envelopes are indeed slightly slower with 3.5 MHz clock. But I am not worrying about that right now. Any patches can be adapted as soon as the official emulator moves on.
    1 point
  9. Just a note to let you all know that i'm still working on this. It is a lot of fun actually to play with the bits and the banking. I'll need to contact Jesper to optimize is cx16 compiler, but i plan to make a similar implementation for the CC65. I'll support both compilers.
    1 point
  10. Yes - I think pricing may be a factor, according to the wikipedia article - https://en.wikipedia.org/wiki/Motorola_6809 I had the pleasure of using a SuperPet in the 80's and all the Waterloo languages - they had dual CPUs of a 6502 and the 6809.
    1 point
  11. As many companies have proven over time, you don't have to have the best product to gain the most traction and take control of the marketplace.
    1 point
  12. It was always such a shame that the 6809 got paired so much with the 6847 which makes games look like the colour was vomited onto the screen (I presume there was some technical reason for those colours because no sane person would choose them voluntarilY). An 8Mhz 6809 (in FPGA) and Vera would be an awesome machine. Also it's enjoyable writing for that sort of CPU. Writing 6502 assembler you always feel you are fighting it.
    1 point
×
×
  • Create New...

Important Information

Please review our Terms of Use