Jump to content

BruceMcF

Members
  • Posts

    1187
  • Joined

  • Last visited

  • Days Won

    39

BruceMcF last won the day on June 9

BruceMcF had the most liked content!

3 Followers

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

BruceMcF's Achievements

  1. Yeah, no ... circumstances have changed from when the project started & I was teaching in China. Right now I am busy with 12 hour shifts, six days a week, so don't have any time for playing with any boards -- and saving up so we can start building our house, so don't have a lot of spare funds either, right at this moment. But I'm hopeful that next year, things will have eased up, and also hopeful that the project will get far enough along to take pre-orders or crowd-funding for the CX16c.
  2. Also, for parts where a 8MHz 65xx clock require really tight address select timing, 6.29MHz may allow more slack ... and the further away from the edge of the speed performance envelope, the more robust in the face of some noise. However, the 65816 is one of the appealing aspects of the Feonix256 systems for me, so I am a bit ambivalent about the 256 Jr.
  3. However, going ahead with EITHER the X16p or X16c requires that the FPGA that hosts Vera is readily available in quantity, which implies that the current ship shortage will have eased to SOME extent. A key -- and in reality not actually knowable part -- is how a shift to a situation where the FPGA that hosts Vera is actually readily available in quantity will be reflected in the price of chips/parts that at present cost substantially more than they did two years ago. In any event, the X16p design has to be finalized ... which means,among other things, available in sufficient quantity for beta testing ... in order to have the benchmark on whether the X16c CPLD (and possibly etc{+}) presents an identical software platform to the X16p. ______________ {+ Note: For example, moving to SMD chips implies a larger selection of SRAM, so one cost reduction might be to have a single 1MB SRAM with LowRAM selecting the top 40KB and 123 banks of High RAM, and one 1MB SRAM will be cheaper than one 512KB SRAM and one 64KB SRAM.}
  4. Since the Super NES used a processor from a maker that licensed the 65C816 core, and the Apple IIgs used the 65816, one presumes it can be managed. AFAIU, the original CX16 design was intending to rely on a CPLD to handle it, and I would guess that the 64K memory map implemented with classical glue logic would appeal much more to Dave ... and it is, after all, Dave's dream computer, not mine!
  5. Yes, and a daughterboard could use pin E (pin 35 in the PDIP layout, pin 39 in the PLCC layout) to toggle between using the CX16 ROM bank in Emulation mode or a board-specific ROM in Native mode, which as one benefit would allow more easily taking care of what to do with interrupts happening when in Native mode. Or, given that the opcode emulation model only applies to opcodes from the 65C02 so that the RAM above $00FFFF can still actually be accessed in Emulation mode, have one of four 16K RAM segments from the on-board RAM appear in the ROM window in Native mode, and use an extended RAM bank as a trampoline location. Disable interrupts before going into the Native mode routine to copy the Native mode interrupt service vectors and support code into the appropriate space(s) of the on-board RAM ... then the expansion board doesn't need ROM, just RAM, the CPU and the CPLD that implements the access to/from the CX16 motherboard bus (including bus mastering once the CX16 "flips the switch" to turn that on), the on-board RAM, and captures the Bank address data during PHI2 low.
  6. Behind many design elements considered to be "abominations" by some often lurks that horrible phrase, "commercial considerations". AFAIU, Apple LIKED the smaller CPU footprint that resulted from multiplexing D0-D7 with A16-A23. Nintendo certainly did, and the design license fees flowing from the SNES was a much bigger cash cow than any 21st century hobbyist systems are ever going to be. If used for a 64K address space for a 65xx family system, with RAM and I/O conditioned on PHI2 high, it seems to me that the high address space can simply be ignored.
  7. There is always a possibility that some of the single bit operations that are 65C02 specific sneak into some Kernel code ... but it would have to be new code, since the original code base was for NMOS 65xx processors, which don't have those single bit operations either. So unless some of those sneak into the Kernel via new code, all it would mean is Kernel calls are made in 65C02 opcode emulation mode.
  8. Some would express the "assumption" part as, "... with the awareness that they are..."
  9. Quite. "$10 more for an FPGA that can use external SRAM and $6-$8 for the SRAM" means $6 versus $22-$24, for a system with a CPU that is $10 q1 at Mouser ($6 q1000). It seems like the POINT of the FPGA in the Vera is to support designs where the amount of RAM available as Block RAM in most inexpensive commodity FPGA's is not quite enough, but to save the cost of supporting enough I/O pins to allow access to a RAM of that size. And remembering how the project started with the Gameduino version 1.0, with its 32K of visual space being very constraining, Vera is kind of right in the strike zone.
  10. It would be possible but putting a ROM Forth in one of the free ROM banks allows one to continue to use distributions of programs that use Basic the way that PC-DOS used BAT to execute batch files.
  11. And the"free" here should be underlined. You can run any language on the bare metal, where the only role Basic plays is executing the auto-exec statement which loads the desired environment. For all intents and purposes, if (1) I ever complete xForth {NOT to be taken for granted!} and (2) you load and run xforth.prg as your auto-exec statement, then the Commander X16 becomes, to for all practical purposes a Forth system ... which happens to have a bank of ROM code that contains a Basic interpreter.
  12. Yes ... the dominant move when playing the "let's make a game" game to try to make enough money to stay in business and be able to keep on making games. When the "let's make a game" game is being played to satisfy the instinct of workmanship (in Veblen's phrase), there probably isn't a dominant move.
  13. Or perhaps the ADSR envelopes ... the easier it is to USE the PSG channels in an effective mix with the FM channels, the more likely they are to be used side by side.
  14. And if the C128 game was successful, the 15m C64 installed base means that you would want to do a C64 port ... and once you have a C64 port, the C128 version ONLY adds the fraction of the C128 audience that are unwilling to buy C64 games ... which would have been effectively 0 people. Simply focusing on trying to do the most appealing possible C64 game is what they call in Game Theory the "dominant move".
  15. Open Sourcing the ROM ... that would be a reason to provide an alternative "OS". I'm not 100% sure that there is another one. See, the thing is that the X16 "OS" is more a BIOS ("Basic Input/Output System") kernel than what most people would think of as an "operating system" today. Since it allows you to program on the bare metal, what would be an "alternative operating system" in a modern computer doesn't actually need to REPLACE the X16 "OS" ... the X16 "OS" will happily load anything and let it take over completely.
×
×
  • Create New...

Important Information

Please review our Terms of Use