Jump to content

Leaderboard

Popular Content

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

  1. About 7 years ago, a friend of mine started building his own giant collection of arcade machines focused on vector graphics games and pinball. I was into retro gaming/computing a bit at that point, but getting to spend so much time with those machines really gave me the bug bad. I didn't have the money or space to get into arcade machines. I've been a programmer for 20 years and I knew there were still at least a few people out there doing programming for old consoles, so I decided to pickup a 2600, my first childhood console, to learn how it worked and how to program for it. Every 2600 tutorial starts out with a brief history of the 6502, that's where I learned just how big a part of my childhood entertainment that little processor was. It was in basically every console I loved and a bunch of the arcade/pinball machines I liked. Then I learned just how big of a community there still was around, not just retro computing, but even specifically 6502 based machines. Knowing that what I learn for programming the 2600 could be somewhat transferable to so many different machines was really appealing. I learned a ton over the next few years but, eventually, my interest in building anything fun or useful myself waned quite a bit. Now I appreciate what others have built so much more and I love playing the homebrew games. IMO, the retro communities are the best ones to be a part of on the internet these days, and they are what have really kept my interest so high for this long.
    3 points
  2. We know that it is possible to emulate a 1541 with a Raspberry Pi, and that's an awesome project. Emulation is being worked on for 1571 & 1581 as well (or is already available, I can't tell for sure). It may support other formats, and that's great. But I have an idea... What about a device that doesn't try to emulate exact pieces of hardware, but just provides mass storage on some device number, not unlike CMD or other brand of Commodore hard drive. Say it is device 11. It can load, save, do all the normal things you'd expect to be able to do with a disk drive, along with useful extensions to seek into files, and even create a sort of REL file that would be backed by a SQLite database instead of being traditional block based. It could provide typical REL compatibility and some sort of extended functionality to do more, like access records by a magic file name that could be loaded and saved. In fact, that's how I'd imagine "plain old PRG/SEQ/etc" files would be stored in the system. And what if that device also responded on device 4 to provide access to a printer connected on that Raspberry Pi? Device 6 I believe was the number used by the 1520 plotter. Maybe one could access a plotter the same way (not that I see a lot of people with plotters). Alternatively, it could emulate the plotter and render it to the printer. Device 5 is typically another printer as far as I know. What if that device gave you access to the Raspberry Pi's HDMI display via IEC? It would not be *fast* but could be useful for text debug output. It doesn't have to send full 1920 x 1080 bitmaps, though I suppose it could. It'd be slow, but possible. Control codes could be used to define a virtual size of text mode or bitmap mode. Device 7 could be the same as device 5, but it would use the HDMI display for rendering vector graphics. Effectively a video plotter. I believe the Raspberry Pi would have more than enough power to do all these things if it wasn't trying to spend all its time being a cycle exact 1541. Being serial IEC based, it could be used with a VIC 20, C64, C16, Plus/4, C128, or even the upcoming MEGA65 and of course Commander X16. It would not be blazing fast, but it's intended to provide access to slow memory constrained devices anyway, so I don't see that as a huge deficit in most scenarios. How crazy is this? What should be discarded as stupid? What didn't I think of in the list above?
    1 point
  3. pi-IEC sounds reasonable. Especially on things like the X16, compatibility only needs to be at the IEC level, rather than being a 1541 etc.
    1 point
  4. Some consider you exceptional, but I don't know what noun they'd pair with that adjective. I guess making that comment makes me a retro grammar geek.
    1 point
  5. You're basically just re-hashing the User Port device I've been looking into. My system would have provided UARTs, network connectivity, and even a second screen for the Commander. I put it on the back burner for now, but it's certainly possible to do the same thing through the IEC port, rather than the User port. After all, they're both basically the same thing: just pins connected to the VIAs. The only difference is that the IEC port only has 3 data lines connected straight through to the VIA, where the User port has something like 12. I don't see any reason not to build something this... the only catch is you'd need to run under a bare metal OS to drive the GPIO pins reliably enough and fast enough to be useful.
    1 point
  6. The build server is a neat idea. Program on the retro machine in a retro IDE, but pass off the compilation work to the "mainframe". Funny how that workflow is still in use today, yet it is decidedly retro nonetheless. Internet pass through over IEC might be slow, but there's nothing stopping you from using the userport like other networking cards for C64/128. Maybe it would make sense as to build the whole thing as a funky, huge userport cartridge. That would have the benefit of allowing one to use the cartridge slot for normal cart software or something like the Final Cartridge III or the like, unlike the Ultimate II cart. It would also look awesome, like a Neo Geo arcade cart with ports.
    1 point
  7. Recently my sister unearthed a small savings bond that our mother purchased for me literally 20 years ago, so I decided it was time to put my old 20" Samsung LCD to rest. I had already taken pity upon my children and given them my own 24" Benq GW2470 1080p monitor a couple of months ago. It was just so sad to see my youngest hunched over, leaning in to see while playing My Time in Portia. So, I had myself, like any good dad would, gone back to hunching over and leaning in to see anything on that old work horse of a monitor. Heck being from 2008, that o'l Samsung is probably retro now too! Fun, but my old eyes... So I purchased a 24" Asus ProArt PA248QV monitor that was on sale, because I wanted an IPS screen with decent colour accuracy and I thought the 1920x1200 resolution would be nifty for desktop and art stuff. The colour accuracy is actually kind of important. If you look at the sprite sheet I made for RocketTux, much of it over-saturated, likely due to me over compensating for the dull colours on the o'l Samsung TN panel (don't get me wrong, it still is a nice display). The BenQ has a VA panel and good colour accuracy, though it's bright as bloody hell when set to full sRGB mode (unlike the Asus, which is closer to the rooms ambient lighting when in sRGB mode). Well guess what, fellow retro computing folks, it turns out that this new monitor is actually perfect for using QBasic in DOSBox (in Windows 10)! When running QBasic in full screen on my 1080p monitor there were black bars on the left and right of the screen and the fake scan lines didn't look right. Not so on my new monitor, as it fills the whole screen and the scan lines work perfectly. So now when I do my retro programming, it's like I have some crazy large wide screen flat CRT and a "futuristic" red back-lit keyboard/mouse combo that givesoff Terminator vibes. For a "modern" desktop (my CPU is from 2012...), it sure can feel quite nostalgic. Should plug my WinXP box into it too... hmmm.... Anyway, a 16:10 ratio screen is great for programming with DOSBox! The rambling story was a bonus. Ps. Canada Savings Bonds don't make a lot of sense to me. It took 10 years for that $100 bond to earn a whole $20. One could earn that much in a little over a year just by bumming a nickel once a day. Work two extra hours a year? BAM 10x more earnings! Maybe they make sense if you're buying thousands of them, I don't know!
    1 point
  8. I propose that we replace the YM2151 with the YM21280. How hard could it be to work with?
    1 point
  9. It's actually not a bad idea. Really, it would be a perfect job for the new Pi Zero 2, which is plenty powerful enough to achieve this functionality using Raspberry Pi OS Lite and some shell scripts. If you made a simple circuit board to plug the Pi02 into then you could have it fit into one of those standard hobby boxes with circuit board front/back panels (like the Colour Maximite 2). Stick an IEC port for the input from a Commodore machine and then outputs for USB, Parallel Port (whatever type(s) for vintage and current dot matrix printers), and perhaps an SD card slot on the front using one of those ribbon cable extender things, and a power switch. Functionally, I think it might be faster to have all of the input from the C= machine be written directly to files and then make use of listener scripts on the Pi that act upon the discovery of new files. For instance, "printing" to device 5 would put the new.pdf file in /var/c5/ and the script would automatically copy it to /var/c5/[DATE]-###.pdf and then display it on the HDMI screen. Printing to device 8 would do the same, but then send it to the configured printer rather than the screen (though it could be set up to email it, view it, upload it to a web server, whatever). Lots of possibilities there and none of it would require much processing power. Could probably do it with an original Pi Zero.
    1 point
  10. I had a look at a bit of your code on github. I think you might be trying to make the X16 do a little too much of the work going from the abstract ADSR envelope to the volume of a channel at any given moment. Just how granular does your ADSR envelope need to be? Is 1/60th of a second enough, or does it need to be modulating the volume on a shorter time scale than that? Because if your interrupt routine is relying on the VSYNC interrupt, that's all you've got for resolution. And just how long would the total envelope last? surely not more than four seconds, right? The point I'm getting at is maybe look at getting some C++ program to generate a table of values for an ADSR envelope, some volume between 0 and 63 for each 1/60 of a second of the envelope. Then you only need to increment a pointer into a lookup table at the VSYNC interrupt to find the volume for that channel. Multiple channels could be using the same ADSR lookup tables at different points, each having their own indices incremented every interrupt; perhaps mark the last byte of the sound with an FF or 00 in the lookup table. An envelope that lasts half a second would just be a 30+1 byte string of data. A 256 byte table would be an envelope over 4 seconds long. So, for each channel you'd have two bytes for the starting point of the table, another offset byte incremented every VSYNC, and that's it. You'd just define those envelopes externally and turn them into some sort of ADSR.DAT file. Actually, you could have separate tables for Attack, Decay, and Release, and just a regular counter for Sustain. Then the envelope is just pointers to Attack, Decay, a counter for Sustain, and a pointer for Release. The code is a little more involved than just a single ADSR table, but it could give a bit more flexibility in the sounds.
    1 point
×
×
  • Create New...

Important Information

Please review our Terms of Use