Jump to content

BruceMcF

Members
  • Posts

    1187
  • Joined

  • Last visited

  • Days Won

    39

Everything posted by BruceMcF

  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.
  16. "I love the retina display on this phone!" "But, but ... that's NOT a retina display at all!" "OK, to be fair, it's a retina display given MY retinas. YMMV."
  17. ... and the 6502's architecture of zero page addressing AND only having byte ADC and SBC arithmetic with "set up the carry bit, then start operating at the first byte and go as far as you want to go" makes starting at the little end a fairly natural choice. But if you don't realize that the 6502 is little endian, then "<" and ">" as "pointing to" the low or high byte respectively doesn't make sense.
  18. Yes, an advantage of G-Pascal is that Nick Gammon has already written it, and it was originally written to run in ROM on a 6502 board in the 70's, then ported to the Apple II and C64, so porting it to another 8bit system is a lot less challenging than porting a system originally designed for a larger system. And a tiny Pascal compiler for a bytecode VM fits a lot more easily in a ROM of an 8bit system than a native code compiler for a more complex language. Intrinsic to the design of the original Pascal was a syntax that supports single pass compilation.
  19. Nick Gammon's G-Pascal for Ben Eater's 6502 breadboard computer, based on G-Pascal for the C64 (if I understand correctly, because the C64 version was the one where he could find his old source code) is similar, with a bytecode "tiny" Pascal compiler (integers and chars, no sets or floats, but IIUC integers are 24 bit), assembler, simple line editor and command line shell, along with I/O code for connecting a serial UART via the 65C22 VIA: G-Pascal on Github, G-Pascal on Nick Gammon's site, 6502.org discusssion.
  20. While I concur, when I was talking about a "home in ROM", even though my open source Sweet16VM is "fat" compared to Woz's masterwork of spaghetti 6502 code ... it's still under 0.75K, so it it's going to find a home in ROM, it has to ride along with something else that is (1) more substantial but (2) under 16K in its own right. The alternative is to implement enough applets using the Sweet16 VM to justify putting the whole collection in a ROM, but I am working 11 hour shifts at present, so I probably don't have the time for that
  21. The CX16 includes the "stable development platform" philosophy inspired by 80s 8bit home computers like the VIC20 and C64 .. but it's not like there is "one true and proper approach" ... a variety of different projects each with their own coherent approach makes for a more interesting Vera ecosystem.
  22. This is exactly the kind of ROM home I would like to see for a Sweet16 VM.
  23. I was referring to: 00000409 is not in the list, so on standard name is available to select 00000409. US - International is listed in the docs as the default keyboard, and US - International isn't supposed to have ~^"' as live keys (though I wouldn't be surprised if there are variants that require AltGr for them to act as dead keys). And from the announcement of release 41 candidates: So from that, the default US layout appears to be with dead keys for ~ ^ " ' replacing the version with those as live keys. EN+US for US International and EN-US as US standard would allow a choice between the two (which one is the default is not what I am discussing).
  24. Let me try it and see. '"~^ nope, all four live keys. They would be dead keys if I changed to an English International keyboard, but I would do that in a context where I wanted to use (at least some of) those characters as accent keys, such as typing pinyin pronounciation of Chinese words with the proper tone mark.
  25. As an option, they are handy either way ... but for people used to typing with standard US keyboards, the constant typos when used to using ' and " as live keys is going to be there in productivity applications as well. If someone were to port Nick Gammon's G-Pascal, which in the 80's had a C64 version but which has been revived for systems like Ben Eater's breadboard computer, I'd expect they would port the modern version and program in ISO mode. And while the work-around of allowing PETSCII £ to work as ISO \ makes it possible to have a ANSI Standard Forth which can be used in PETSCII mode, it would not be surprising if users coming to it with previous Forth programming experience would opt for the greater familiarity offered by operating in ISO mode.
×
×
  • Create New...

Important Information

Please review our Terms of Use