Expansion slots

[TomXP411]

I feel like the design team have just said no it's not our idea we couldn't be bothered to understand so please go away.

Have you talked to the design team? None of them use the forums.

[BruceRMcF]

... You just need to make the latches go high-Z when the banks are not in use and be part of the BE high-Z state from the CPU. ...

IIRC, they aren't necessarily tri-state latches, so they may not be able to go into a high-impedance state.

If the glue logic involved a choice between /Resettable latches and tri-state latches, you can see why resettable latches would be a priority, since you want the ROM latch to come up in a known starting state on system reset.

And of course the points already made about they are not at the stage of the project where they are going to do any breaking changes just to chase specialized niche benefits ... they are at the stage of the project where they are only going to do a breaking change if there is a lurking hidden bug that will otherwise cause a serious headache.

[BruceRMcF]

If 8MB memory space on the card suffices, you can have any segment of $80 and above access the X16 main memory map, then when you latch the segment address, bit0 to bit6 can connect directly to the card memory bus A16 to A22 and bit7 selects between the card address space and the X16 address space.

Sure, but why? The original Super CPU could handle 16MB of RAM. I wouldn't settle for less if I was trying to create a Super CPU X16 Edition.

For the reason noted, that it's a simpler circuit to select on one bit to select an entire power of two space, versus notching one 64KB segment out of a power of two space, and also that it's upwardly expandable, where if segment $FF is actually used to access the X16 main memory map, then $80-$FE are available for special modes.

It's not like a direct 8MB 65816 RAM space limits the card to 8MB if there are DMA capabilities ... the limit on the DMA memory is the width set aside for the DMA RAM address, so the DMA memory could well work with a 32bit address space.

[TomXP411]

If 8MB memory space on the card suffices, you can have any segment of $80 and above access the X16 main memory map, then when you latch the segment address, bit0 to bit6 can connect directly to the card memory bus A16 to A22 and bit7 selects between the card address space and the X16 address space.

Sure, but why? The original Super CPU could handle 16MB of RAM. I wouldn't settle for less if I was trying to create a Super CPU X16 Edition.

For the reason noted, that it's a simpler circuit to select on one bit to select an entire power of two space, versus notching one 64KB segment out of a power of two space, and also that it's upwardly expandable, where if segment $FF is actually used to access the X16 main memory map, then $80-$FE are available for special modes

I don't think that's a good trade. 8MB for a slightly simpler chip select logic doesn't sit well with me.

[spargue]

[q post_id=27258 time=1684040282 user_id=3978] ... You just need to make the latches go high-Z when the banks are not in use and be part of the BE high-Z state from the CPU. ...

IIRC, they aren't necessarily tri-state latches, so they may not be able to go into a high-impedance state.

If the glue logic involved a choice between /Resettable latches and tri-state latches, you can see why resettable latches would be a priority, since you want the ROM latch to come up in a known starting state on system reset.

And of course the points already made about they are not at the stage of the project where they are going to do any breaking changes just to chase specialized niche benefits ... they are at the stage of the project where they are only going to do a breaking change if there is a lurking hidden bug that will otherwise cause a serious headache.
[/quote]

I assumed they were due to the need for vectors being duplicated on all roms, but realised this wouldn't cover the situation where the bank pointed to invalid memory, or the vector was invalid.
There is no octal latch with reset and output enable, only a quad which would double the chips needed. I guess somthing like an sr latch which would disable the bank latch on vector pull but re enable it on write would work, the original content can be restored from the shadow ram value.

[BruceRMcF]

Sure, but why? The original Super CPU could handle 16MB of RAM. I wouldn't settle for less if I was trying to create a Super CPU X16 Edition.

For the reason noted, that it's a simpler circuit to select on one bit to select an entire power of two space, versus notching one 64KB segment out of a power of two space, and also that it's upwardly expandable, where if segment $FF is actually used to access the X16 main memory map, then $80-$FE are available for special modes

I don't think that's a good trade. 8MB for a slightly simpler chip select logic doesn't sit well with me.

While I am thinking 8MB might be overkill for where directly addressed memory dominates the arbitrarily large DMA memory, which is superior for writing data to video or sound chips.. At about $15 q1, a 16Mbit 45ns part might do me for SRAM, which only occupy a quarter of the directly addressable SRAM.

[Martin Schmalenbach]

Just so I'm clear from having followed this interesting & spirited discussion...

If I WRITE to the banked ROM space for banks above #0-#31 and I have an expansion card with RAM mapped in to the ROM space, the data that is written by the CPU will actually be stored in the RAM, assuming I've wired the RAM up correctly?

The application I'm thinking of here is. simple Expansion card with RAM occupying several ROM banks at #32 and above that will be useful for speedier development of ROM-based code for cartridges etc.

Something like the circuit below/attached

[spargue]

Just so I'm clear from having followed this interesting & spirited discussion...

If I WRITE to the banked ROM space for banks above #0-#31 and I have an expansion card with RAM mapped in to the ROM space, the data that is written by the CPU will actually be stored in the RAM, assuming I've wired the RAM up correctly?

The application I'm thinking of here is. simple Expansion card with RAM occupying several ROM banks at #32 and above that will be useful for speedier development of ROM-based code for cartridges etc.

Something like the circuit below/attached

This seems OK, I wouldn't put the activity led on the OE line as this is bad for rise fall times, better to buffer it with the extra gate. Not sure how you'd program it unless this is just a simplified sch

[spargue]

Just so I'm clear from having followed this interesting & spirited discussion...

If I WRITE to the banked ROM space for banks above #0-#31 and I have an expansion card with RAM mapped in to the ROM space, the data that is written by the CPU will actually be stored in the RAM, assuming I've wired the RAM up correctly?

The application I'm thinking of here is. simple Expansion card with RAM occupying several ROM banks at #32 and above that will be useful for speedier development of ROM-based code for cartridges etc.

Something like the circuit below/attached

Oh wait I just saw an issue. You need to watch A15 A14 from the slot to see if you are accessing the rom address space. Not (A15 & A14) - > #CE

[Martin Schmalenbach]

Just so I'm clear from having followed this interesting & spirited discussion...

If I WRITE to the banked ROM space for banks above #0-#31 and I have an expansion card with RAM mapped in to the ROM space, the data that is written by the CPU will actually be stored in the RAM, assuming I've wired the RAM up correctly?

The application I'm thinking of here is. simple Expansion card with RAM occupying several ROM banks at #32 and above that will be useful for speedier development of ROM-based code for cartridges etc.

Something like the circuit below/attached

This seems OK, I wouldn't put the activity led on the OE line as this is bad for rise fall times, better to buffer it with the extra gate. Not sure how you'd program it unless this is just a simplified sch

Good catch on the activity LED - thanks!