Jump to content

Scott Robison

Moderators
  • Posts

    829
  • Joined

  • Last visited

  • Days Won

    37

Everything posted by Scott Robison

  1. Good thoughts. One of the things that has was true from the beginning of the microcomputer revolution was that the hardware was the important part, and software followed. CP/M was arguably the first software that became popular enough to drive what hardware would be released, but there was still a lot of room for companies to create consumer level microcomputers that would each be custom little systems (like game consoles especially today). Had IBM kept their platform proprietary, and kept their OS rather than "giving it" to Microsoft, many things could have been different. But once that genie was out of the bottle, it provided all the incentive in the world for companies to start cloning IBM compatible hardware. Had it not been MS-DOS, it could have been custom CP/M systems. Or ultimately unix / posix systems. Commodore had a hardware empire and software was a necessary evil that didn't make them money. As long as they made their money from selling new hardware to the same people every few years, without a focus on backward compatibility, I think their demise was inevitable (though as you say, 20/20 hindsight and all that).
  2. In checking out Vice for C=64, the screen and keyboard are not "open" per se. You can open their device numbers directly, but they are the default stdin stdout devices apparently. So still 10 logical files can be open at once, but the number per device is device dependent.
  3. When I say "possible" I mean "possible to do without needing to swap to disk". In other words, floppy disks are just very slow RAM. Hard disks are slightly faster RAM. CD / DVD / bluray is slow ROM (ignoring the possibility of -RW or -RAM versions). Printers are WOM. Further, by "possible" I do not mean "feature parity with an x64 native edition of the same compiler".
  4. The only reason C or C++ might be possible on X16 would be the 512K to 2048K of banked RAM. All those floppies were compensating for the lack of RAM (or so is generally my experience).
  5. Interesting (to me) aside: I got the job working on PCBoard in part because I had written my own BBS for my C=64 in the mid 80s. It wasn't *great* but it demonstrated I had experience in the "market" (though I only wrote it for myself and never actually marketed it).
  6. Microsoft's first C++ was apparently also released in 1990, though I have no idea how well it worked. I was working for Clark Development Company between 1992 & 1995, and I used Borland C++ for the PCBoard Programming Language which was very well received. We were already using Borland Turbo C & Turbo Assembler for PCBoard, and I convinced them to allow me to use C++ for the scripting language we added to PCBoard v15. I saw that code recently and it is not pretty (I was much younger and less experienced) but it predated Visual C++ v1 in 1993. https://en.wikipedia.org/wiki/PCBoard#History for a brief history of PCBoard / PPL (though it doesn't discuss the fact that it was C++) for those who are interested.
  7. The first DOS C++ compiler as far as I know (at least the first I used) was Turbo C++ which I think was released in 1990. But that is pre-standard C++, much less modern C++17 / C++20. The current language definition has so much optimization opportunity with const, constexpr, templates and lambda functions (only const was supported in 1990) that it might as well be a different language. You simply can't compare 1990 era C++ with 2020 era C++. In many ways it is the difference between a simple machine language monitor that only recognizes mnemonics, addressing modes, and hex numbers, and a fully featured macro assembler that allows you to build your own assembler syntax with relocatable segments ala ca65 / ld65 or comparable systems. The video linked above basically gives you a freestanding implementation of "modern C++" that can be used to generate 6502 family assembly, though with more tools in the toolchain to jump through. Getting an LLVM supported way that doesn't require translation from 32-bit x86 to 8-bit 6502 is just a little more neat of a process *if* it generates the equivalent of hand rolled assembly language. Certainly I'm not trying to tell the world they should use C++ instead of assembly on a X16. I'm saying I'd like a good optimizing compiler for C++ that would support the X16. In that case, you can have functions that are evaluated at compile time and have zero stack parameter passing overhead, because the compiler is smart enough to see that all the information to inline the function is available at compile time. Sorry for the tautological statement...
  8. Not trying to be condescending, but since many people don't know the difference between freestanding and hosted, https://en.cppreference.com/w/cpp/freestanding might prove useful.
  9. Note that I'm not necessarily talking about using the entire standard C++ library (though for some app types that would be fine as well). More than anything what I really want is efficient expression of template based code (including templates in the standard library). There are freestanding and hosted expectations. I don't necessarily need hosted. I would love freestanding.
  10. I've not looked at your project to know how possible this would be, but are the differences so onerous that you really can't do #3? Or even #4: Have the runtime select v38 or v39 based on the ROM version at runtime? I know, it's really easy to say "why not" when you have no idea what the code looks like.
  11. I'd love it if I could use C++ to target 6502.
  12. 640K is enough for anyone, so 512K + 64K + 128K = 704K is more than enough!
  13. 10 files is also a kernal limitation, after reading a bit further. Note that this is 10 files spread across all devices. From what I was reading, you might not be able to open all 10 files on a single device, so the limit might be lower, though given the X16 implementation, I suspect {knock on wood} that you should be able to open 10 at once via sdcard.
  14. Commodore 64 BASIC allowed 10 open files. That may also be a kernal limitation, I'm not sure. Regardless, given that is the basis of X16 firmware, I think that should be adequate for most purposes.
  15. Addition: I also found an old 1200 bps modem that I used with my C=128. Not commodore branded.
  16. What type of tablet / case / keyboard did you find / use?
  17. I just saw the post at @Perifractic's channel about the VIC-42 being a SoC/uC/what-have-you used in a 1520. I lost a lot of my 8-bit gear in a move decades ago, but recently came across a box that had a few things in it. I had thought there was a 1520 in it, so I went to look to see for myself how the chip was labelled. Alas, no 1520 in that box. A part of the device (plastic cover over the paper roll) but not the plotter itself. However, I discovered that I have a C=16 and joystick, a 1541, a 1581, I think an 803 printer, a 1750 clone (1764 updated for C=128), and my old C=128DCR keyboard. I think discovering that I have the keyboard is perhaps the most exciting part of the find, as I have the potential to interface it with something...
  18. I've never heard of that machine until today. What information I can find about it online suggests it was hugely expensive, only sold about 1% of the number you quote, and was only available in Japan. I'd be interested in more information about it though, as two pages, one of them being Wikipedia, do not necessarily paint an entire picture. Wikipedia claims about 150,000 were sold, as contracted with almost 5 million Amigas. Creating computers (and software for that matter) is a balancing act. There is always more you can do if resources are no object. But since resources are finite (time, money, silicon, elctricity, etc), it takes judgement to come up with a reasonable set of features that people are willing to pay a reasonable amount of money for.
  19. After reading about the 832 proposal, I agree with WDC never finishing it. Sure, it would be nice to have something that could internally deal with 32 bit numbers, but the 8 bit bus was just too limiting at the point it was being considered. I'm with you about GUIs. I like *using* a *good* GUI (though there are many GUIs that are not good). I did like OS/2 Warp and worked for a company that released OS/2 software. Windows 2000 Pro was my favorite flavor of Windows until Win 7 was released. I don't care for writing GUI software.
  20. Commodore had no interest in the 816 much less the never produced 832. Prior to buying the Amiga IP, they were very much a "Only Invented Here" shop (for the most part) in that they wouldn't make things with other people's IP. Once Jack was gone, they seemed to go the opposite direction betting on Motorola which would have ultimately been a dead end for them had they not died first.
  21. As do I. Again, just something I was thinking about. With as many C=64 reimplementation as exist these days, it was something I wanted to play with. Really what I'd like to do is be able to buy a modern PC compatible board that would allow me to replace the BIOS to create a "single board computer" (not necessarily RPi sized, but with all the stuff on the mainboard without needing cards). But all modern boards for "PC compatible hardware" expect all you'll use it for is to boot a file based OS.
  22. I'm not @rje and I haven't talked to him about it. I didn't *laugh* at your specs, but they seem overly optimistic to me for the technology that was available in the day for "consumer hardware" or effectively a game console. Don't get me wrong, I loved my C=64 & C=128DCR back in the day. Wish I still had them. That's what appeals to me about the CX16. But I don't see any 8-bit being a realistic path forward for much past the C=128. I think they could have created upgraded C=128s that had more RAM and perhaps had a few more sales (I mean, 5.7 million C=128s were sold, that's not bad, it's only bad in comparison to how many C=64s were sold over the years in combination with the profit margin of the more expensive hardware). But the world was moving away from all in one computers other than for game consoles. By all in one I don't mean the modern definition, I mean "you get this one video chip and this one sound chip". The world was demanding expandable / upgradable hardware. That's why I think they had to focus more on 16 bit / 32 bit platforms. They just didn't know how to market anything that wasn't a toy, more or less.
  23. I was specifically thinking of a IBM 5150 compatible board with all the things you would have found on that in my specific example, my idea being that I could then play with ROM creation in a simple environment. It's mainly a thought exercise.
  24. I can't believe I have been unable to find a "modern retro" PC mainboard. I would love something like that to play with, even if it is all FPGA. I guess I could go the MiSTer route...
×
×
  • Create New...

Important Information

Please review our Terms of Use