Commander X16

Has any new info come forth on the new 60-pin IO interface?

No, but if new information had come up, it would be posted here and/or in the documentation.

Here's the pinout doc, if you're interested:

https://github.com/X16Community/x16-doc ... ardware.md

and another one of our users has spent a lot of time doing a technical breakdown of the system, here:

https://ayce.dev/emptyx16.html#interface-ports

At this point, the port pinouts are fixed. With 100 PCBs manufactured, the only way something like a port pinout would change is if a major problem came up. Like "halt and catch fire" major.

We're safe from a "Halt and Catch Fire" scenario, I expect... Ever since 0h5C, the "Forbidden Opcode", was banished from the 65c02 in later revisions catastrophes like that which befell Bashtarle are almost certainly relegated to history.

Later processors in the series have tamed the Forbidden One's 8 cycle NOP instruction by fortifying the instruction with guard walls and sinking support columns into the Earth. This increases packaging costs, but in cases like this, safety is tantamount.

Just some followup questions on the bus

• if a expansion card wanted to dma or a coprocessor wanted access it would need to assert wait and ba to get access?
• intb is bidirectional? so a card can trigger interrupt or respond to interrupt?
• how can a card hook into intb callback routine?
• am I right in assuming intb is global and not vectored?
• io 3 - 7 are duplicates on all expansion cards? Won't this make it more difficult to access cards and find them in the bus?
• are the i2c pins banked or switched in some way or is i2c address collisions an issue on similar chips?

spargue wrote: ↑Thu May 04, 2023 7:57 pm Just some followup questions on the bus

1. if a expansion card wanted to dma or a coprocessor wanted access it would need to assert wait and ba to get access?
2. intb is bidirectional? so a card can trigger interrupt or respond to interrupt?
3. how can a card hook into intb callback routine?
4. am I right in assuming intb is global and not vectored?
5. io 3 - 7 are duplicates on all expansion cards? Won't this make it more difficult to access cards and find them in the bus?
6. are the i2c pins banked or switched in some way or is i2c address collisions an issue on similar chips?

1. Wait for non-write cycle, then pull RDY low
   https://retrocomputing.stackexchange.co ... 502-system
2. I believe this is intended to trigger a CPU interrupt. However, as the expansion ports are in parallel with the rest of the system, a card could read the interrupt pin and do something internally - just don't expect access to the bus until the CPU is in a position to allow DMA access.
3. You would have to write code to handle callbacks or service interrupts and hook into that code as part of the operating system's IRQ or NMI handler. I don't know the address off the top of my head, but you can review the ROM code to figure out where the KERNAL locates the IRQ and NMI handlers in RAM. You would then take over that vector and point it to your code, which would check the state of the hardware, then pass control over to the default handler (the address that was in the vector before you took it over.)
4. There are two interrupts: IRQ and NMI. There are not interrupt controllers, so any hardware that uses these interrupts needs to provide its own means of checking "did I trigger that interrupt?"
5. Yes, IO 3-7 are the same for each card. These are there to help decoded addresses on one of 5 32-byte I/O blocks in the $9Fxx space. Which I/O line you use is up to you, but the best practice is to provide a jumper block or DIP switch to select which I/O block to respond to.
6. afaik there's only one I2C bus. Again, use jumpers to allow the user to select different I2C addresses.

TomXP411 wrote: ↑Thu May 04, 2023 11:24 pm

1. Wait for non-write cycle, then pull RDY low
   https://retrocomputing.stackexchange.co ... 502-system
2. I believe this is intended to trigger a CPU interrupt. However, as the expansion ports are in parallel with the rest of the system, a card could read the interrupt pin and do something internally - just don't expect access to the bus until the CPU is in a position to allow DMA access.
3. You would have to write code to handle callbacks or service interrupts and hook into that code as part of the operating system's IRQ or NMI handler. I don't know the address off the top of my head, but you can review the ROM code to figure out where the KERNAL locates the IRQ and NMI handlers in RAM. You would then take over that vector and point it to your code, which would check the state of the hardware, then pass control over to the default handler (the address that was in the vector before you took it over.)
4. There are two interrupts: IRQ and NMI. There are not interrupt controllers, so any hardware that uses these interrupts needs to provide its own means of checking "did I trigger that interrupt?"
5. Yes, IO 3-7 are the same for each card. These are there to help decoded addresses on one of 5 32-byte I/O blocks in the $9Fxx space. Which I/O line you use is up to you, but the best practice is to provide a jumper block or DIP switch to select which I/O block to respond to.
6. afaik there's only one I2C bus. Again, use jumpers to allow the user to select different I2C addresses.

1. This ignores the MLB status, It wouldn't be safe for atomic RMW instructions.
3. So it's basically a linked list of code vectors relying on everyone to play nicely and not worry about jitter?
4. I feel a simple addition of a priority encoder with inputs routed to the expander would have been a neater solution, adding a linked list could be a secondary fallback.
5. mapping IO 3-7 doesn't seem to simplify io mapping very much as it's only reduced by 3 bits. Adding an IO for bank 0x9F and a slot-specific IO selection would have been neater. If a card needs more complex IO decoding a simple 3-8 or 4-16 decoder can be included on the card. This would free up more IO pins for interrupts or control signals.
6. does the bus support Multimaster with the negotiation or is it active drive, can it support clock stretching?
7. another thing I realized is ram cannot be banked from the IO cards directly. Does this mean the banked ram vector 0x0000 needs to be shadowed to allow ram expansion?

spargue wrote: ↑Fri May 05, 2023 8:08 am This ignores the MLB status, It wouldn't be safe for atomic RMW instructions.

Right. It is better to wait for an opcode fetch cycle (SYNC asserted)

spargue wrote: ↑Fri May 05, 2023 8:08 am I feel a simple addition of a priority encoder with inputs routed to the expander would have been a neater solution

Yes, interrupt hardware is as barebones as it gets. Many inexpensive improvements could have been included.

spargue wrote: ↑Fri May 05, 2023 8:08 am mapping IO 3-7 doesn't seem to simplify io mapping very much as it's only reduced by 3 bits. Adding an IO for bank 0x9F and a slot-specific IO selection would have been neater. If a card needs more complex IO decoding a simple 3-8 or 4-16 decoder can be included on the card. This would free up more IO pins for interrupts or control signals.

Yes, the slot decoding is goofy.

spargue wrote: ↑Fri May 05, 2023 8:08 am does the bus support Multimaster with the negotiation or is it active drive, can it support clock stretching?

The bus does not support anything. There is no hardware arbitration nor advice for software arbitration. Expansion card designers are in the driver's seat.

Something like this might work:

• disable all interrupt sources except for the expansion card about to take the bus
• tell expansion card to wait for RDY negated
• execute WAI instruction (which negates RDY and halts the CPU)
• expansion card negates BE to free the bus
• expansion card does its thing
• expansion card asserts BE
• expansion card wakes the CPU with an interrupt

spargue wrote: ↑Fri May 05, 2023 8:08 am

1. This ignores the MLB status, It wouldn't be safe for atomic RMW instructions.
2. So it's basically a linked list of code vectors relying on everyone to play nicely and not worry about jitter?
3. I feel a simple addition of a priority encoder with inputs routed to the expander would have been a neater solution, adding a linked list could be a secondary fallback.
4. mapping IO 3-7 doesn't seem to simplify io mapping very much as it's only reduced by 3 bits. Adding an IO for bank 0x9F and a slot-specific IO selection would have been neater. If a card needs more complex IO decoding a simple 3-8 or 4-16 decoder can be included on the card. This would free up more IO pins for interrupts or control signals.
5. does the bus support Multimaster with the negotiation or is it active drive, can it support clock stretching?
6. another thing I realized is ram cannot be banked from the IO cards directly. Does this mean the banked ram vector 0x0000 needs to be shadowed to allow ram expansion?

This is, more or less, the same design used on the PET, VIC-20, Commodore 64, Commodore 16, and Commodore Plus 4, in addition to the 8502 side of the Commodore 128.

And you're right - there is no decode logic on the expansion bus for RAM at $A000. This is because the system already has RAM at that address, and on a fully populated system, there's no room for additional RAM banks in the $A000 block. The only place to add memory via expansion port connectors is in the ROM bank at $C000-$FFFF.

Do Rom Banks ROMB[0-7] follow the BE logic of going high impedance when BE is low or do they retain state?

It should, since the cartridge ROMs are reliant on that behavior.