Jump to content

calags

Members
  • Posts

    3
  • Joined

  • Last visited

calags's Achievements

Newbie

Newbie (1/14)

Week One Done One Month Later

Recent Badges

0

Reputation

  1. Couldn't the VPOKE and VPEEK commands for the X8 be implemented to hide the access method to the VERA's video RAM? They only need to deliver or retrieve a byte from the VERA's VRAM address space and the VERA memory map need not be that dissimilar with only the missing 64K being different. I admit (from the 8BG's description) it would be different for machine code programs but the BASIC interpreter could hide it from the BASIC programmer. FWIW I have a pending question asking why the access interface should be different for the X8. If it was only because of a performance improvement I think it would be worthwhile to reconcile the X8 and X16 and take the performance hit for the sake of compatibility.
  2. Can anyone tell me why the X8 interface to the VERA has to different from the X16 apart from the fact that it has only 64K of VRAM? It seems to me that if they can be reconciled that would make writing from the X8 to the X16 easier kinda like writing from EGA to VGA. If the programmers choose they can just write to the "lower" specification and have it run on both with no code changes. Also is the upper 16K of ROM for the BASIC and Kernal ROM code "hiding" the remainder of the lower 64K from the FPGA? If so would it be possible to make these accessible by allowing them to be banked to the same range in the X16? That would give the X8's 65C02 another 16K to work with almost like it was an X16 with a small amount of "upper" RAM.
  3. I think it may make sense to release the X8 but only if the BASIC it uses is compatible with the X16 BASIC with enough keywords to implement compatible graphics and sound functions. This could make it possible to write BASIC programs for the X8 that can be immediately moved to the X16 and thus can get you started with a usable code base before the more ambitious X16 is completed. It gets the project some cash flow now, gets you a BASIC application code base the X16 can use and if there is a good machine language entry point for the graphics and sound functions it would be possible to write compatible code there too. Some programmers like myself appreciate the extra discipline of coding to lower specs. I wouldn't brand it with the Commander name though. Think of it as the VIC-20 to the Commodore 64. Heck, since it's almost a 21st century VIC-20 why not call it a VIC-21? After the X16 phase 1 is complete we can reconsider a phase 3 device to replace the X8 and the X8 code should still run on it if you choose to proceed. I wouldn't implement it faster than 8MHz though to keep the apps compatible.
×
×
  • Create New...

Important Information

Please review our Terms of Use