What Happens?

[Reciprocating Bill]

What happens when a console with 16-bit RAM built-in (and wait states disabled) is attached to a PEB that has a 32K card installed? Does the faster RAM prevail while the 32K card is ignored (down low, too slow)? Does console confusion follow? Are either the console or the card damaged? Is smoke released?  

 

The reason I ask is that I have two consoles, one with the 16-bit RAM and one without. I might have occasion to attach the latter to the PEB - but don't want to be constantly installing and removing the 32K card. That IS an invitation to release the smoke stored therein. 

 

I'm curious, but not curious enough to try it out. Which I guess means I am curious yellow.

 

P.S.: a similar question arises vis the 16-bit console and a NanoPEB. 

Edited June 6, 2022 by Reciprocating Bill

[+Ksarul]

You'd need to disable one or the other of them, as the two will definitely argue with each other. It might be easiest to install a disable switch for the in-console memory, that way, you switch it off and connect to the PEB or to the NanoPEB without having any odd memory issues.

[Reciprocating Bill]

9 minutes ago, Ksarul said:

It might be easiest to install a disable switch for the in-console memory, that way, you switch it off and connect to the PEB or to the NanoPEB without having any odd memory issues.

Actually, that wouldn't work, because it is when the 16-bit console is attached to the PEB that I'd want it to be active, yet the conflict would arise. So I would really need a way to switch the card on and off - off when the 16-bit console is attached, on when an unmodified console is attached. 

[apersson850]

Which leads to that the correct answer is "It depends on how the internal memory expansion is designed." If it can't be disabled, then you shouldn't have any expansion card in the box at the same time, or there will be a conflict. If you make it possible to disable the internal expansion, then it's reasonable to implement that feature in such a way that then the standard expansion becomes visible instead. And vice versa - when the internal expansion is active, the console will not see the card in the box.

That's how I did mine. The only difference compared to Ksarul's suggestion is that I disable mine via CRU bits. That means that a running program can turn off the internal expansion by itself (provided it's not running from it, or it will be the software equivalent of seppuku). Thus such an implementation effectively gives 2 pages of 32 K RAM expansion, if there's a card in the box too.

Edited June 6, 2022 by apersson850

[Reciprocating Bill]

4 minutes ago, apersson850 said:

Which leads to that the correct answer is "It depends on how the internal memory expansion is designed." If it can't be disabled, then you shouldn't have any expansion card in the box at the same time, or there will be a conflict. If you make it possible to disable the internal expansion, then it's reasonable to implement that feature in such a way that then the standard expansion becomes visible instead.

That's how I did mine. The only difference compared to Ksarul's suggestion is that I disable mine via CRU bits. That means that a running program can turn off the internal expansion by itself (provided it's not running from it, or it will be the software equivalent of seppuku). Thus such an implementation effectively gives 2 pages of 32 K RAM expansion, if there's a card in the box too.

This leads to the same issue - When I am using the 16-bit console, it is attached to the PEB and I want the faster RAM to be working, not the slower 32K card. So shutting off the 16-bit RAM to eliminate conflict defeats the purpose of the upgrade. It is only when the stock console is attached that I want the 32K card active. 

Edited June 6, 2022 by Reciprocating Bill

[apersson850]

No, you misunderstood me. Sorry if I wasn't clear enough.

 

With the design I did, there is 64 K RAM inside the console. Out of that, 32 K corresponding to the normal memory expansion is active. The fact that it's active automatically cuts access to the expansion box memory.

If I do disable the internal 32 K RAM expansion, then the memory in the PEB, if there is any, becomes visible at the same addresses. Nothing special has been done to the PEB. If you connect a standard console it works just normal. You have 32 K RAM, slower, in the box. If you run into a program that doesn't execute properly in fast RAM, just switch to the standard RAM.

The modified console has 32 K RAM, faster, regardless of if it's connected to a box or not. If I disable that, it runs like the stock console on the memory in the box.

The remaining 32 K RAM in the console is disabled by default, as it overlays the other addresses in the machine. That is operating system ROM, DSR space, cartridge space and system space (VDP, GROM access, sound etc.)

Edited June 6, 2022 by apersson850

[Reciprocating Bill]

3 minutes ago, apersson850 said:

The fact that it's active automatically cuts access to the expansion box memory.

That's the difference - I doubt there is any provision in the design of my upgrade that automatically cuts access to the expansion box memory. But I don't know that for a fact...the upgrade I undertook is described here:

 

http://mainbyte.com/ti99/16bit32k/32kconsole.html

[apersson850]

I was inspired by such a modification, but thought it was a waste to have 64 K RAM and only be able to use half of it. That thought lead to my design.

It would take a while to step through that instruction to check if it disables the box access too, but it's quite likely, as if it doesn't, then random data would be fed back into the console, which would assume a memory card is there.

[Reciprocating Bill]

33 minutes ago, apersson850 said:

It would take a while to step through that instruction to check if it disables the box access too,

If you find yourself so inclined, I'd really appreciate it.

 

 

[apersson850]

Kapten, Orsa kompani lovar ingenting bestämt! (Korpral Jonas Grifting, 1894)

 

Almost 40 years have passed since I designed my memory expansion, so I probably have a startup to do here. We'll see.

Edited June 6, 2022 by apersson850

[apersson850]

3 hours ago, Reciprocating Bill said:

I doubt there is any provision in the design of my upgrade that automatically cuts access to the expansion box memory.

Thinking about it I'd say there has to be. The CPU can access memory that's coupled directly to the data bus. This is the RAM PAD and system ROM in the console. It can also access memory that's on 8-bit wide data path. It does so via the multiplexer which reads two successive bytes and then present them as a word to the CPU. All memory access has one thing in common: Chips not selected must disable their outputs. Otherwise more than one chip respond to the same request. This implies that when accessing system ROM, the RAM PAD chips are disabled. But so is the 8/16 bit converter, or it would respond with some random data. Now when you install memory inside the console, you have to decode that memory instead of the memory outside the console, in the expansion box. Thus you have to turn off the 8/16 bit converter and access the chips directly in the console.

 

The only difference with my design is that I don't make this change permanent, but instead it's gated via a CRU bit, so I can switch between internal and external decoding of the same memory address. But your's should do the same, except you can't switch it. It will just never look in the box for expansion RAM any more.

[Reciprocating Bill]

17 minutes ago, apersson850 said:

It will just never look in the box for expansion RAM any more.

If I understand you correctly, the bottom line is that my accelerated console may work with the 32K card present in the PEB. It will ignore the card. Do you think there is any risk to either end of the hardware in trying? 

[+OLD CS1]

31 minutes ago, Reciprocating Bill said:

Do you think there is any risk to either end of the hardware in trying?

I would not expect to damage anything.

[Reciprocating Bill]

Turns out the 16-bit console runs fine with the 32K expansion card in place in the PEB. That gives me a bit of flexibility - I can run any console on my PEB. Oh - and the blinkenlight on the card flashes even when the 16-bit console is functioning, which I like. Thanks!

Edited June 7, 2022 by Reciprocating Bill

[apersson850]

That would rather worry me. That means that all of the circuitry for the expansion card has not been disabled. But it seems the design at least disables the access to data on the card, even if the card still senses the addressing.

With my design, the expansion card is dark when the internal memory is used. I typically use the expansion as part of a RAM-disk, and then it's obvious when the RAM-disk DSR accesses the card.