Jump to content

SlithyMatt

Members
  • Posts

    891
  • Joined

  • Last visited

  • Days Won

    66

SlithyMatt last won the day on June 7

SlithyMatt had the most liked content!

Recent Profile Visitors

2131 profile views

SlithyMatt's Achievements

  1. That's using pointers in a specific way, but pointers in general don't "kill efficiency" - it's a foundational part of the C language. Compiled languages are always going to be less efficient than hand-coded assembly for 8-Bit, but I think blaming that on pointers is not accurate. A pointer, this context, is just a 16-bit address stored in memory. And (zp,x) indexing is not very useful, even in assembly, and there are plenty of opcodes that use (zp),y indexing, and that's what most pointer indexing in C would compile to, anyway.
  2. Another cost consideration is the move to a single FPGA design. Quadrupling the RAM would likely be much more than a 10% increase in cost. And even with discrete through-hole RAM chips, as we have seen, the market for chips like this has gone whackadoo (I apologize for using such a technical term), with demand outstripping supply by an order of magnitude (or more!), as chip fabs put their limited resources to producing high-quantity, high-profit components for modern systems. Prices for the kinds of chips used in the X16 have doubled in the last couple years, if not tripled or worse! And supplies being how they are, there may simply not be enough RAM chips available to put more than 512k in every unit. We could even be looking at a lottery situation for completed X16 units at first.
  3. That's news to me, and I've been a C developer for almost 30 years. What do you base this statement on?
  4. It's extremely minor, and easily overcome. 512k is still an embarrassment of riches for an 8-bit computer, and it means that it can act as a baseline for compatibility, and pretty much any game or application that will work within 2MB can work in some form at 512k. A program can detect the number of banks and load extra data into the higher banks for quicker access. This can make having more RAM act as a cache to mass storage to cut down on load lag. Or extra RAM can enable things like more music and sound effects, so the user experience is enhanced. If a program absolutely needs 2MB to be functional, that would definitely hamper its adoption, and chances are it could have been more intelligently designed to make it work in some form in 512k.
  5. I think a lot of those differences were intentional to avoid intellectual property issues.
  6. Assuming that only sprites are going to move relative to your tilemaps, it's quite easy. You just have to adjust the sprites X level based on its foot position. You would have two tile layers, one that is strictly background that the sprites are always above, and then another that the sprites can be behind or in front of, depending on context. While it's not isometric, my RPG map engine does something like this:
  7. Really, the web emulator just needs to be brought up to date, and we need to deprecate earlier releases. R38 was around for a long time, but it's time to move past it.
  8. If you get the first version of the board, the ROM will be socketed, and you can freely replace it with the ROM of your choosing. The ROM is also open source, and you can try your hand at replacing the BASIC ROM right now. Of course, that means you won't be able to run any of the many BASIC programs that the community has already shared, and like Bruce says, you can always load a Forth interpreter from the initial BASIC prompt and not lose any functionality. But if you really want a Forth-first machine, you will have to support loading machine-language code as well, assuming you want to use anything out there, including games. They all expect BASIC to be there to at least launch it, but you could have a Forth ROM that just looks at the tokenized BASIC launch code at the beginning and jumps to the machine language program start. But still, some machine language apps expect the BASIC ROM to be there, and make use of some of the data and subroutines. If you want to be a single man on a Forth-only island, have at it, but just know that you are likely to be alone and only have your own programs to run.
  9. The other important factor is that Amiga was acquired by Commodore. The 68000 was chosen before it ever came in-house, and switching to a 65816 would have been completely off the table.
  10. No, it's quite different. The Mega65, like the original Commodore 65 design, banks out the entire 64k memory space. Bank 0 is like a regular C64, and provides backward compatibility. Other banks have additional RAM and ROM. The C65 had another 64k of RAM in bank 1, then 128k of ROM across banks 2 and 3. The Mega65 has all this, but it also has the option to make that ROM into RAM (which it actually is, just merely made write-protected while in C65 compatibility mode). The remaining 12 banks are all RAM, if you have it populated. So, you can have up to 1MB of RAM, or more that apparently can be swapped out.
  11. That success was more technical than commercial. The Archimedes was never as successful as their 8-bit computers, which themselves were also-rans to the competition from Sinclair and Commodore, outside of the education market. The real success of ARM came later as it was licensed for embedded use, which evolved into being the architecture of choice for mobile devices, and by then ARM has become its own spin-off company and Acorn eventually died off.
  12. You need to remember that the 65816 was "not invented here" at Commodore/MOS. It was created by Bill Mensch after he left the company and started WDC. Using the 65816 would be an admission that MOS no longer was at the forefront of their own processor family, like Intel selling PCs with AMD CPUs.
  13. Before COVID, I had all the Marriott points I could ever want, and that was my plan. Since my business travel has completely stopped, I used up all my points for personal use. What definitely helps is that I moved from a place with frequent power outages (easily one every two weeks) to one with very few (just one very brief -- less than 2 minutes --- outage over the last 8 months).
  14. If you really wanted to put the Computer back into "Family Computer", you really only have two options, as the RAM issue needs to be addressed: 1. Modify the board to enable more RAM. The standard board has that 2kB from $0000 to $07FF, and then mirrors that three more times. You hook up a daughter board with another 6k of RAM and bodge that in, and you could even implement some banking. This is still a ridiculously small amount of contiguous RAM, and you have to violate the integrity of the board. At that point, you might as well just design a new board around the PPU and APU chips to have a computer that looks and sounds like an NES, and could effectively emulate one. 2. Do it all in the cartridge. You have a lot more wiggle room in the "ROM" section of the memory map, nearly 48k. You could probably take 8-16k of that to make a simple development system, like an in-memory assembler and tile editor. You'd have the rest of the "ROM" and actually make it RAM. You could even make it banked so that you could build program and graphics data at the scale of latter-day NES games, which could be much bigger than 48k, thanks to banked ROMs. Either way, you then need the ability to connect a keyboard and some mass storage. You could easily make a keyboard connect through a controller port (and Nintendo did, with FamiCom BASIC), but storage is more difficult. Since you probably want to save your programs, you'll need to connect to a tape or disk or something. The easiest thing would be to play a modulated stream through the audio RCA jack and just record that. Problem is, you have no way to load it back to work on it further. Your best option (at least on the exported NES -- this won't work on a Japanese FamiCom) is to use the expansion port on the bottom. It has the CPU data bus connected to it directly, but most of the address bus isn't there. So, you could use it as a parallel port and dump data into a storage device, which could also act as a ROM burner, or at least something that adds ROM images to an SD card that you could pop into a multicart. You could dump assembly source and metadata in there, too. It would... not be fast... but it could work. The big "but" is that this would not give you the "code and try" immediacy you may be looking for. It would be a process, at best, of turning off the unit, swapping the SD card into a multicart, and swapping that in with the development cart. This is something you could easily do with the C64, or the Apple II or Atari 800, and you could still have all the fun of making a game with a 6502 system, and not go through all that. It also speaks to the "dream" of the X16, which gives you that immediacy along with the speed and resources to make the process as painless as possible.
  15. Not really. And to clarify, I was indeed talking about professional development being on other systems. Obviously, homebrew for the C64 was almost entirely on the unit itself until the advent of PC-based emulators like VICE. But this was because the C64 was a proper computer, if a really small one that wasn't good for much besides games. But it was at least good for SOMETHING besides games. Most 8-bit consoles can really do NOTHING other than play games. If you ever used the Atari 2600 BASIC cartridge, you'll know what I mean. With only 128 bytes of RAM, it's impossible to write code, much less run a compiler or assembler. There was BASIC for the FamiCom back in Japan, but again it was a really simplified thing, and not like the real home computer experience. You only have 2kB of RAM, so you still don't really have enough memory to work on code or run an assembler. Once we get to the 16-bit era, things turn around. The SNES has 128k of RAM, and I bet you could make that into a fairly serviceable computer that could at least do some real programming.
×
×
  • Create New...

Important Information

Please review our Terms of Use