Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by TomXP411

  1. Actually, I can see a use case for keeping the RAM available in the upper part of the 65F02's RAM cache. On the Commodore 64, we can actually write to the RAM that is covered by ROM in the default bank configuration, then turn off the ROM in order to use the RAM underneath. This is how you'd load a custom operating system or a game that uses the top 16K for its own purposes. I could see doing the same thing here with the 65F02. By selectively enabling the 65F02's cache above $A000, you could use it for a custom operating system, hosted fully inside the 65F02's memory. This actually sounds like a fantastic upgrade part for the Commander, if it's possible to work with the 65F02's maker to coordinate a reserved address for bank control.
  2. Thanks. I know I remembered some conversation about that, but it might have been one of those passing "this is what we're thinking of doing" things.
  3. I can… I just don’t want to. I built my PiDP-11, which took two evenings, and that came out very well. However, that’s really just an LED and switch panel, and there’s not much that can go wrong there. With a computer as complex as the DIP version of the CX16, I just don’t want to make a mistake while building the kit and find out it doesn’t work… then spend days trying to find a flaw that may even be out of my control to fix. So while I’m interested in an assembled computer, or even a motherboard sans case, I’m not interested in a kit computer at all. It’s the biggest reason I don’t already have an RC2014 computer.
  4. Good, working ones are uncommon, especially in the US. There's also a problem you may not be aware of: there are at least 4 generations of Amiga, which are very different. The Amiga 1000, 2000, 3000, and 4000 were all different internally, and the differences in architecture made software partially incompatible between generations. Software that worked well on the 1000 might not work on the 2000, and a bunch of games written in the 2000 days would not work on the 3000 or 4000. So people had to buy accelerator cards, memory cards, or just buy multiple computers to run their favorite software. We have a similar issue today: a modern, Windows 10 computer will not run software made for Windows 3 or DOS software. So we use emulation and virtualization to run old versions of an OS inside of the modern systems. The difference is that even a 68040 Amiga 4000 isn't really fast enough or powerful enough to fully emulate an A1000 or A2000. So if you bought a vintage Amiga, you have to pick the one to fit the software you plan to run on it. This is why emulation is particularly well suited to the Amiga platform: you can switch out graphics systems, chipsets, and CPUs with the click of a button. I can set up a WinUAE machine to be a 68000 A500 one minute and a 68040 A4000 with 24-bit graphic card the next. It's just a matter of loading a different configuration in the emulator. More than any other popular computer of the 80s, the Amiga is actually a better experience on emulation (FPGA or software) than on real hardware.
  5. The X8 is really a different beast than the later stages of the CX16 roadmap, so the X8 debate won't be one with the FPGA or SMT versions of the CX16. With the X8, you're talking about a computer that's really very different: it will not have a full ROM. Instead, it will have a bootstrapped RAM operating system with a very small bootstrap ROM. This is how CP/M works: there's just enough ROM (a single page, in fact) to boot the BIOS from disk. Then the BIOS boots the command processor, and you have an operating system. From what I understand, the CX8 will work similarly: the bootstrap ROM will load a BASIC+KERNAL program from SD. This means that programs can be written to occupy all 63K of system memory (There is a small carve out for I/O space) without ever actually loading the KERNAL or BASIC. This is not something the CX16 is currently capable of (unless we get RAM in one of the ROM banks.) The other difference is that VERA is accessed via a single, 256 byte page, rather than the 32 I/O registers we have now. This dramatically changes the I/O process, since you have access to a full line of text or tiles directly, rather than the indirect method the CX16 uses. And we obviously have the 512K vs 128K issue to think about. Programs written for the CX8 will have to fit no more than 128K: 64K of main memory and 64K of video memory. On the other hand, the Commander X16 roadmap includes a Surface Mount (SMT) version and an FPGA version. Both of those will have the same I/O and memory structure as the CX16E (the version currently in the works), but with smaller circuit boards and fewer chips to do the same job. While the package may be smaller, the software will be the same: the same program will run, unmodified, on all 3 of the planned Commander X16 editions. Software that directly accesses video, sound, the User port, or the IEC bus will not run unmodified on a Commander X8. That's the difference. The X8 is a different computer, and while it shares some common parts, it's as different from the CX16 as the Commodore 64 was from the Plus 4.
  6. I've got one of those, too. I love it. I'm also considering getting the DAC case to build a music player. These things are super convenient, and this form factor is much more pleasant to use than the standard Pi cases, since all the important bits come out the back, rather than 2 different sides.
  7. We've already talked about the ROM in other threads. Short version, there's no need to license Commodore's ROM. There are several 6502 BASICs out there, and there's more than enough brains in this community to crowdsource a kernel - even without relying on something like the open KERNAL started by the MEGA 65 crowd.
  8. There are several ways to launch a suborbital spacecraft that don't use as much energy and fuel, but they require more infrastructure than anyone is willing to invest in right now. I'm sure we can also eventually do a better job with liquid hyrdogen fuel - which can be made 100% carbon neutral. And that doesn't even get into the possibilities for efficiency improvements, like what we've seen with automobiles. Cars today use maybe 1/4 of the fuel of cars made in the 40s and 50s. Part of that is engine design, but a big part is also due to the design of the cars themselves. Fuel economy closely related to mass, and so making lighter cars makes for more efficient cars. With spacecraft, the same is true. Something 90% of a spacecraft's mass is fuel, and much of that fuel is spent lifting other fuel. So 1 pound of reduced orbiter mass means 10lbs less fuel is used. So materials design plays a big factor. Likewise, making engines more efficient can massively reduce the fuel cost. If we can improve engine performance by 25%, that might eliminate half of the fuel needed for launch, just due to the exponential nature of the fuel equation.
  9. Yes, it went up back in August. The name was wrong, though, so it was the "AS500." At the time, I was thinking, I didn't know IBM had released a follow-up to their popular AS400 mainframe..
  10. You can always grab a D64 of the game and run it in your choice of modes. The TheC64 is capable of running in NTSC or PAL speed, regardless of the HDMI frame rate you're running. I don't remember the exact process, but you can use filename shortcuts or generate a configuration file for your game.
  11. Yes, there would be no reason the FPGA version can't be upgraded down the road. It would also be possible to run this on other multi-system FPGA computers. There are several popular ones out there, including MiST, MiSTer, and Turbo Chameleon, I believe the ZX Next and MEGA 65 hardware will also be able to load alternate cores, so it's possible that the Commander X16 could be widely distributed as a software core, in addition to being hardware only. I'd happily contribute to a Patreon to develop FPGA cores for these systems, especially if the chip shortage is going to make it difficult or impossible to get the kit version out in 2022.
  12. If I recall, the system clock is also driven by VERA. In that case, there would be firmware changes needed for VERA to live on an 8080 style system. Either VERA would need to generate the clock, or you'd have to drive the I/O side independently from the GPU side of the core. In either event, you might as well modify the bus sequencing to account for 8080 style I/O while you're at it.
  13. I think the same thing. More than that would mean a lesson in 65x logic design, which could be a thread all of its own.
  14. That's amazing. I'm amazed at what people keep coming up with in the 8-bit space.
  15. Thanks. That gives me a place to start.
  16. I know this has been answered somewhere else, but the information has been buried beneath a mountain of other comments. @Frank van den Hoef Can you talk about the FPGA that's actually being used for VERA? All this talk about FPGAs and what can and can't be done has got me itching to know more - and possibly to do a deep dive into the technology, myself.
  17. To think... there was a time when William Shatner was doing Star Trek conventions just to earn a living. And now he's got the cachet to make a trip to space. It just goes to show how anyone's fortunes can change, with the right circumstances.
  18. See, this is not quite correct...an FPGA can do none of these things by itself. If you simply feed power to an FPGA, it will sit there. It requires programming and peripherals to perform even a simple operation. It's most appropriate to say that an FPGA is part of a computer, just like the Broadcom BCM2837B0 is part of a computer. Context and programming matter, and we don't think of cash registers, arcade games, or air conditioning thermostats as computers - even though they may contain a microprocessor and perform fairly complex tasks. Clearly a smart thermostat has all of the requisite properties, but we're never going to confuse a Nest thermostat with a desktop PC. Context matters, and while a complex FPGA can be one component of a computer, it's not "a computer" any more than the Broadcom SOC. It's just one piece of a system that may or may not itself be a general purpose computer.
  19. Yeah, I can't stand Tapatalk and don't want the prompt every time I visit. I woudn't mind a one-time prompt, but every time? No thanks.
  20. You're not compiling assembly code. You're assembling it. Compilers and assemblers are different things. Anyway, the !BYTE, !PET, and !SCR are assembler directives for raw data. You're correct that the DB directive is the replacement on other assemblers (including other 6502 assemblers.) The thing to remember is that non-Commodore computers don't have PETSCII, and everything else you're likely to encounter uses ASCII. (There were some non-ASCII mainframes, such as IBM EBCDIC, but we're not going to talk about that.) So the !SCR and !PET commands are there to convert ASCII text to the PETSCII or the screen code equivalent. Since an "A" is 65 in ASCII, 96 in upper/lower case PETSCII, and 1 in screen code PETSCII, you have to tell the assembler which code to use for "A". But the Spectrum only talks ASCII, so you don't need to re-encode text. This means you don't have or need any of the cross-platform encoding directives like !PET. Just use the DB directive to encode the ASCII values to binary, or check your assembler manual to see what it uses for text encoding. Since every assembler is a little different, you definitely need to read the manual. And yes - there are equivalents to CPX and CPY: all the various "ld" instructions, such as LD A,B or LD B,C. The equivalent to indexed instructions is anything using (HL), so something like LD (HL), A copies data from the Accumulator to the address pointed to by the HL register pair. There are also no indirect operations, so nothing like LDA ($20). Instead, you have to LD HL,20h and then LD A,(HL). You'll find that the Z80 has a different way of doing things, and it's actually easier to code for in the long run... the problem is that in the short run, you want to do things like zero page addressing or indexed indirect addressing and can't... but once you translate the concepts to Intel's simpler paradigm, it's actually easier. You have 7 registers to work with, and 16 bit math only takes one instruction. So a lot of things we need to do the hard way just take one operation on Z80.
  21. It’s really not quite the same. David did a review of the TheC64 where he shows the audio and video lag of using software emulators. It’s one reason I prefer my Ultimate 64 or my MiSTer over VICE when playing Commodore games. And that’s aside from the fact that a small ARM SOC just can’t run the Commander emulation at full speed. It struggles to do 4MHz on a Raspberry Pi 4, and that’s more powerful than most of these little ARM SOCs.
  22. Intel claimed a Copyright on the mnemonics, which meant no one was allowed to use their names for their instructions. So even though the Z80 is 99% compatible with the 8080, Zilog had to make up their own names for the instructions. Eventually, the courts ruled that re-implementing instruction set mnemonics and software APIs are fair use - ie, you can't sue someone for using the same mnemonics as you. In other words, Zilog didn't need to go to the trouble.
  23. The X16 Assembly Environment isn't really an assembler. It's a replacement for the machine monitor. Just like you wouldn't write code with Supermon, you shouldn't be using the Assembly environment to write code: you might use it to enter already-written code, or to debug, but if you're writing a non-trivial piece of software, you need to be using a traditional assembler, not the X16AE.
  24. I have written an 8080 assembler in c#... so I know I can write a simple assembler in c. The issue is, as you said, I've only got so many hours a day. Right now, I'm learning a new musical instrument, starting to arrange songs for a brass band, and working 50 hours a week... so I don't have a huge amount of free time either. Still, I might see how hard it is to do... maybe the solution is to port over something like Turbo Assembler, which already runs on the Commodore 64.
  • Create New...

Important Information

Please review our Terms of Use