FAQ Update for Gen-2 aka "CX16GS" system

[TomXP411]

And now whoops there goes the rug from under me again, the memory layout is going to be totally different.

Have you even watched the video? David clearly stated that in 8-bit mode the memory layout will be exactly the same as in the Gen1 boards, since the FPGA that replaces all the address decoding logic can detect the mode the processor is running in and change its behavior accordingly. So, if you target only the 65C02 instruction set (minus those four(?) instruction missing from the 65C816), you'll be just fine.

If you want to use the flat memory model of the 16-bit mode then yes, you'll have to change your code, although I think it will only make it simpler since there will be less need for constant bank switching because the new "banks" will be 8 times bigger.

More than likely, what Kevin has in mind is to make CPU bank 0 the same as the current memory map: I/O space at $9F00, 8K Banked RAM at $A000 and ROM at $C000.

When switching to CPU bank 1 or higher, then the CPU will simply talk directly to 64K pages on the 32MB RAM chips.

Either way, software written for the Dev system will still work on the GS. David's current testing seems directed toward just that goal, it would appear. The few new capabilities built in to the GS are already available on the Dev systems via expansion cards, so if you write a game that works on a dev system today, it's still going to work on a GS next year.

[TomXP411]

Is the pinout of that card edge connector the same as the expansion slots? If so it would be possible to make a backplane and add more slots. Having said that given what has been added to the board I'm not really clear what I'd put on an add on card. 32MB directly accessible to the '816 bus makes this an AMAZING computer.

Yes. The pinout should be the same and should support a backplane. (I thought I noted that in the article; I'll go check.)

[TomXP411]

I just did the math. How are we addressing 32MB of RAM on a 24bit address bus?

Address mapping is handled via an FPGA. It sounds to me like Kevin is still figuring out the mapping scheme.

At a guess: the CPU might have direct access to the first 16MB, with the rest being carved up between $A000 and $C000 banks, plus some additional ROM shadow and ROM switching capabilities. (Kevin alluded to that in his notes on the FPGA registers.)

[mgkaiser]

And now whoops there goes the rug from under me again, the memory layout is going to be totally different.

Have you even watched the video? David clearly stated that in 8-bit mode the memory layout will be exactly the same as in the Gen1 boards, since the FPGA that replaces all the address decoding logic can detect the mode the processor is running in and change its behavior accordingly. So, if you target only the 65C02 instruction set (minus those four(?) instruction missing from the 65C816), you'll be just fine.

If you want to use the flat memory model of the 16-bit mode then yes, you'll have to change your code, although I think it will only make it simpler since there will be less need for constant bank switching because the new "banks" will be 8 times bigger.

More than likely, what Kevin has in mind is to make CPU bank 0 the same as the current memory map: I/O space at $9F00, 8K Banked RAM at $A000 and ROM at $C000.

When switching to CPU bank 1 or higher, then the CPU will simply talk directly to 64K pages on the 32MB RAM chips.

Either way, software written for the Dev system will still work on the GS. David's current testing seems directed toward just that goal, it would appear. The few new capabilities built in to the GS are already available on the Dev systems via expansion cards, so if you write a game that works on a dev system today, it's still going to work on a GS next year.

It also looks to me like 2MB banked RAM at $A000 is completely unique from the rest of the 16MB memory space. It also sounds like even in full 16bit mode that space is still banked. This is actually REALLY good given that the direct page and stack page must be within the first 64k. You can potentially use up to 2MB as direct page and/or stack page if you get clever with coordinating the RAM bank register and PBR/DBR processor registers. Give ever subroutine a unique processor stack and/or direct page. Pre-emptive multitasking on an '816 is pretty easy with the main limiting factor being finding enough space in the first 64k to keep each process on its own stack.

[mgkaiser]

I just did the math. How are we addressing 32MB of RAM on a 24bit address bus?

Address mapping is handled via an FPGA. It sounds to me like Kevin is still figuring out the mapping scheme.

At a guess: the CPU might have direct access to the first 16MB, with the rest being carved up between $A000 and $C000 banks, plus some additional ROM shadow and ROM switching capabilities. (Kevin alluded to that in his notes on the FPGA registers.)

This is a NEW FPGA that was not previously in the CX16 architecture that can see the whole 32MB of RAM? Maybe DMA between the RAM you can see with the '816 and the RAM you can't see. So 16MB directly accessible and the rest kinda like the REU was? No chance this new FPGA can see the VERA RAM, is there?

[TomXP411]

I just did the math. How are we addressing 32MB of RAM on a 24bit address bus?

Address mapping is handled via an FPGA. It sounds to me like Kevin is still figuring out the mapping scheme.

At a guess: the CPU might have direct access to the first 16MB, with the rest being carved up between $A000 and $C000 banks, plus some additional ROM shadow and ROM switching capabilities. (Kevin alluded to that in his notes on the FPGA registers.)

This is a NEW FPGA that was not previously in the CX16 architecture that can see the whole 32MB of RAM? Maybe DMA between the RAM you can see with the '816 and the RAM you can't see. So 16MB directly accessible and the rest kinda like the REU was? No chance this new FPGA can see the VERA RAM, is there?

Yes, the FPGA is all new. This completely replaces the address logic and adds some internal bits: UARTs for the wavetable chip and the ESP32, plus an FM synthesizer.

I doubt DMA is in the works, but Kevin is working on some sort of interesting shadow ROM system.

Consider this: the current ROM Bank allows for 4MB of total memory. Adding 2 more bits then expands the ROM to 16MB. So if we had a way to load data into that space prior to switching the bank bit (similar to the way we load VERA now), then we could load an entire alternate OS into shadow ROM, then flip the bank switch to boot to the new OS.

As to VERA: there are currently no changes in the VERA architecture (except some small bug fixes or minor changes to support higher CPU speeds.)

[tim1724]

How about a C compiler? CC65 has limited support for 65816. Calypsi has pretty good support and already has profiles for the Foenix256. Should be a pretty short lift to get CX16GS support into that. Finally it is possible to write relocatable code on the 65816. I don't think Calypsi does that. Does anybody know of a C compiler that does relocatable 65816 code?

There were three C compilers that targeted the Apple IIGS:

MPW IIGS C: ran in the MPW environment in classic Mac OS. (The MPW assembler, C compiler, and Pascal compiler were what Apple used internally for writing most software in the later years of the IIGS.) I believe it's ANSI C (C89) but I've never used it so I'm not sure.

APW C: ran under ProDOS 16 on the Apple IIGS. (Should also work under GS/OS, but I never tried it.) I very much do not recommended using this. (It only supports 1970s-style K&R C, never really received any updates, and was abandoned by Apple pretty early on.)

ORCA/C 2.x: runs under GS/OS on the Apple IIGS (and can run on Linux/Windows/macOS via the Golden Gate compatibility environment). It's still being actively maintained and has been updated to support most of the C17 standard. (IIRC it has everything except wide characters, non-ASCII string handling, and some optional parts of the standard. I believe a few parts of C23 have been implemented as well.)

MPW and APW are effectively abandonware (Apple still owns them but certainly isn't going to come after you for using them, but they would probably get upset if someone tried to distribute them in any sort of official dev kit)

But ORCA is still commercial software (as is the Golden Gate environment that allows you to run it on modern computers).

Note that all of these produce output in Apple's OMF format (not the same as 8086 OMF format) used by the System Loader tool in GS/OS (and ProDOS 16). So to use any of these you'd either need an OMF loader on the CX16GS or a tool that can transform OMF into some format supported on the CX16GS.

Also, the standard C library in all of these is going to be implemented in terms of the IIGS toolbox and either ProDOS 16 or GS/OS system calls. So you'd need a replacement C library for them.

[mgkaiser]

Is there an emulator?

[TomXP411]

Is there an emulator?

The current X16 emulator emulates the Dev board, including the Wavetable MIDI chip.

The emulator will need to be updated to include the GS features: flat memory mapping, FPGA commands, and ESP32 networking.

[Xiphod]

Wow, what a great way to get people to stop doing all software development for the x16. Don't bother writing 6502 code, because that's going to be obsolete...

I think the rant here is valid but for a different reason. Not because the software will be obsolete - but because it won't be interesting. Sort of like writing (or playing) 16-bit CGA 8088 game when the system is a 32-bit VGA with a 386 (well, sure, except now we know original IBM CGA Composite could actually do a lot of colors). Maybe it's like having a LearJet and just using it to fly around the local lake? The passengers expect a bit more since the system can do more. Devs can pour hours into a 6502 masterpiece, but end users will say "but it has an 816 and could do so much more." It becomes hard for both devs (and users) to put the blinders on and just imagine it as a humble 65c02 system. It becomes an issue of platform fragmentation- why focus on excellent 6502 software, when the 65816 version is (probably) going be more "wow"? BTW, wouldn't a 65816 be much better at 14MHz?

But I also see the other side to this: there were far more 65816-based Gameboys sold than even C64 units. So it makes sense to try to appeal to that community (plus the GSII). So, if they pull off a perfectly backwards compatible system -- who knows, maybe it will even dynamically accelerate to 14MHz in the 816 mode -- that in itself would be neat to see. And now with more experience and more certain-persons involved, I think they might be able to pull this off now (whereas before Kevin already explain in past videos why they couldn't do an 816 at that time)

I'd still be concerned about (1) higher level language compiler support (even cc65's X16 support as it is, is barely supported -- things like how it corrupts the zeropage and you have to reset the system when the C program ends, still isn't addressed). (2) Or what licensing issues will come up incorporating some 65816-version of BASIC. (3) The "technical distraction" in all things '816 integration, while (to me) the largest feedback on the X16 has been "more docs pls" (intro to CMDR-DOS w/ complete programming examples, hardware component overview, organized/filterable app-store, etc.)