Jump to content

Scott Robison

Members
  • Posts

    740
  • Joined

  • Last visited

  • Days Won

    32

Everything posted by Scott Robison

  1. 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.
  2. I'm in the US, and many other people are, so Happy Thanksgiving to all of you. Canadians, please accept this as a Happy Belated Thanksgiving. Other countries can take this as Happy Thursday if there isn't a belated or early Thanksgiving in their timeline.
  3. That you for explaining the origin of your handle. I (apparently with most people) assumed Tatwi was feminine, but then you've posted on other topics in a manner that seemed to make it clear that you were a dude. However in this day and age, you never know who / what situation you are dealing with. I don't mean that to be a judgmental statement, my youngest child was born male and identifies as female now. I try to be supportive, though it's hard to flip a switch when you've interacted with someone for years as a male and suddenly have to make a mental transition (which I guess one could say "imagine how it feels for your child" and I guess that is true as well). But I don't mean for this to be a politcal / social commentary issue, just an observation that we have to be more careful than in the "Good Old Days(TM)" (which weren't always as good when we aren't wearing our rose colored glasses) when it comes to identifying people "properly". So thanks for making it easier for me by "outing" yourself.
  4. The school where I teach part time (Mountain West Montessori Academy) has Chromebooks in every classroom for the students to use. They seem to work relatively well, but I have not spent a lot of time with them directly, as I am issued a Windows laptop. My python class students use a platform called "skillstruck.com" (which I am less than impressed with) to login, read lessons, and do assignments and quizzes. Chromebooks are perfectly adequate for those tasks, and given how tough kids can be on electronics, there is much less financial risk to them using Chromebooks than many other options. Personally, I'd like to see Raspberry Pi systems (at least for a programming lab like this) that are not connected to a network, but they are not practical for any of the other classes who only use Chromebooks for a portion of their class work. I have to use them pretty much every day.
  5. You can copy from your text editor (I'm using Sublime Text on Windows) and paste it into a running emulator session, which will simply behave as though you are typing it very fast. I'd say with 0 errors, but it obviously won't correct any errors in your text editor, but it should make a perfect copy of your text into a tokenized ready to run BASIC program. Alternatively, the emulator has several useful command line options. Especially useful to answer this question are "-bas filename.txt" to load your BASIC program text into the emulator and "-run" to auto run the program after emulator startup and program load have finished. Yes, still 80 in Commander X16 BASIC. Nothing that come to mind, but others might have useful suggestions.
  6. I guess my question would be "how exact does an emulator have to be in order to be useful?" Compatibility with a platform covers a number of levels.
  7. $70 more than you or I would pay for a license. I'm sure Lenovo gets a much better price than we do.
  8. I appreciate this series on the basis of doing something computationally expensive but visually appealing. There are so many things out there that will do one or the other, or are designed to favor one machine over the other, but this one tries to present a level playing field.
  9. It occurs to me I gave you generic 6502 code. Did you make it 65C02? Could save a few more bytes...
  10. I called this project piMultIEC for lack of anything better. I'm open to suggestions for a better name, but I have been thinking of a few ideas: pi1542 because 42 is the answer to life, the universe, and everything. pi1599 because it is the ultimate number in the 1500s. pi15anything or pi15everything.
  11. I ordered two pi1541 hats tonight. One for pi zero, the other for a pi 3. I'm going to do something with this.
  12. VERA would need more address lines and data lines, and given what we've been told about it's limitation, I think the answer is no. But I Am Not An Expert(TM).
  13. I'm just hearing about this today: https://fujinet.online/ It seems to be a similar idea but for Atari machines, maybe more.
  14. Good points. I am thinking "simple" to be sure. The BMC64 project uses the circle bare metal library to good effect, and there are a lot of C++ classes (https://github.com/rsta2/circle/blob/master/doc/classes.txt) and add-on libraries (https://github.com/rsta2/circle/blob/master/addon/README) available. I think we can do both. Use the RPi with the pi1541 hat for built in things, plus an ability to pass through to other machines for when RPi isn't quite enough. But I'm not opposed to an Arduino solution either, I just worry that it won't be able to keep up with the IEC timing *and* go over yet another remote connection for some things (like loading a file, maybe). Computer <-> piMultIEC (with option for some hand off to a bigger system) is in general a shorter path than Computer <-> Arduino <-> ModernComputer (with option to do anything it dang well pleases at that point)
  15. 3D printer? Heck yeah! Whatever can be thought of is probably possible. Sure, it's not the C64 or C128 or {fill in the blank} doing the heavy lifting, but these computers are very senior citizens, of a sort. They deserve to be used and useful as much as possible. Attaching a piMultIEC (or whatever better name comes up) to a 8-bit computer is just giving them an assisted living senior community in which to enjoy their golden years. Edit: Oops, forgot to say I have nothing against Linux or BSD. I run BSD, I work on Linux at the office, I like Windows. None of them is perfect. But I also like RPi and Arduino and full "heavy" OSes and bare metal systems. They all have their place.
  16. That's not a bad idea at all. My main reason for focusing on the pi is that I can already acquire a serial IEC IO board for a pi, as used in pi1541. Then "all" I have to do is replace the software layer. Instead of cycle exact emulation of a 1541 or other drive, I only have to worry about timing that conforms to the IEC standard (slower for C64, faster for VIC20). And of course all the magic that exposes a mass storage device or printer or plotter or screen or networking or whatever your imagination can come up with. But perhaps such things already exist for Pi Pico or Arduino? Or maybe we just use some sort of jumpers to hand wire a connection between the two? Regardless, I think if it is possible to do it with the same hardware that already works for pi1541, then that is a strong proof of concept for other things. And it is something we could be developing now and testing with existent hardware, and it would likely be ready whenever X16 is available. Maybe I need to go create a repo and start putting some real design together instead of only talking about it here.
  17. One reason I like the idea is that I have a C16 but I only have a tape drive for it. I could use something like this on five computers before too long, in theory: C16 (have), C64 & C128 (will have next week again), MEGA65 (after December), and X16 (someday).
  18. Yes, we'll go with that. I'm exceptional. Just please don't qualify it. I have private messages from one party telling me in what ways I'm exceptional, but I really think there were some language issues involved as well.
  19. I concur. With a minimum of exceptions to the rule, everyone here is great to interact with. I may or may not be an exception.
  20. Right, there are other approaches that are "better" in multiple ways. The unique parts of this are repurposing the serial IEC bus for some tasks it's never been used for previously (as far as I know) and having a single smart device behave as multiple individual devices. I concur on the need for a bare metal system for this. Serial IEC timing is precise. But it could also implement something like burst mode or fast loaders for accelerated IO. Out of the metaphorical box it should Just Work(TM) with any system with a working serial IEC, allowing BASIC and the kernal to open channels, write, read, and close, load, verify, and save. Disk drive, printers, and plotter functionality could just emulate the command, control, and data interfaces so that it is immediately useful without a need for custom programming on each system. A networking interface could emulate RS232 at that same level. The system could also provide access to other devices. I've already discussed HDMI output. It could allow reading from a USB keyboard, or a camera at a low bandwidth, digital audio input via a mic. And it could have a meta device (sorry Zuckerberg) that allows for command and control of the overall puMultIEC. But being a bare metal system, it couldn't use all the good features of a general Raspberry Pi OS. It could provide it's own API for adding new modules to the system. It could work on a RPi zero, of course, and I'd want to make it work on a broad range of hardware, but my goal would be a multi core with all the typical RPi ports. Just add IEC ports and custom bare metal software for the most flexible smart device with multiple personalities even seen on a Commodore inspired 8 bit system. One core dedicated to IEC communication. The other cores handling more device specific stuff.
  21. The reason I was thinking IEC is that that is the common port on all the machines listed above. I think Commander X16 is supposed to have one, but no user port per se (though the hardware isn't 100% settled yet). C16 doesn't have a user port, and I happen to have a C16. MEGA65 doesn't have a user port either (though it does have other interesting ports in lieu of networking, like it's own ethernet). I know there are differences with the various user ports on some machines that do have them. David described in his last video the effort it took to get the SNES controllers working on Plus/4 because it wasn't compatible. In theory, an IEC device could work with all those computers, perhaps needing a little tweaking of the timing like the 1541 did vs 1540 when C64 was released. I agree that IEC would not be as fast as other solutions, but I expect it could be a very affordable option for people still hanging onto their old machines but maybe don't have the resources to pay for multiple bits of hardware to bring their retro computers into the 21st century.
  22. I was thinking a bare metal approach rather than a full OS, but otherwise I agree with the "everything is a file" approach. It could also support networking (slow but potentially really helpful on something like Commander X16 that would work with an existing CBM 8 bit standard. It could also provide a build server or other similar type of processing. Edit text on your 8-bit system, save it to the device, kicks off a script to assemble/compile/whatever, then you can load the generated PRG file.
  23. Next will be Doom on a teletypewriter which spits out XY coordinates and the color to paint that pixel with your handy "Doom Paint By Numbers" kit.
  24. 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?
×
×
  • Create New...

Important Information

Please review our Terms of Use