OSS 7 in 1 cart

[luckybuck]

For some, we have the source codes, for some sadly not. Those with source code should be able to compile to the needs above. Sorry to say.

[GoodByteXL]

2 hours ago, reifsnyderb said:

Do all of the above use the newer OSS Cart banking scheme?  (Defined here:  https://www.atarimax.com/jindroush.atari.org/acarts.html)

 

Newer scheme, uses 2 d-flipflops, bits A0 and A3.

Physical order of banks: M, 0, 9, 1.

PCB Bottom (103 KB JPG)
PCB Top (96 KB JPG)
PCB Bottom (91 KB JPG) (with parts)

Schematics (8 KB GIF) drawn by me from the board pictures above. I doubt they are 100% correct, but are good enough to understand how does it work.

 

A3	A0	A000-AFFF	B000-BFFF	RD5	Values
0	0	bank 0	bank m	1	0,2,4,6
0	1	bank 1	bank m	1	1,3,5,7
1	0	off	off	0	8,A,C,E
1	1	bank 9	bank m	1	9,B,D,F

Please keep in mind that the original cart design M091 does lack a proper address decoding. While banking the whole bank $D5 is addressed, what causes other hardware or software using other parts of that bank (than the few addresses really needed by these OSS carts) to crash. For  correct schematics please contact tfhh in this forum. It needs one more chip - LS 32 - to solve this. Or a proper programmed GAL, etc.

[reifsnyderb]

4 hours ago, GoodByteXL said:

Please keep in mind that the original cart design M091 does lack a proper address decoding. While banking the whole bank $D5 is addressed, what causes other hardware or software using other parts of that bank (than the few addresses really needed by these OSS carts) to crash. For  correct schematics please contact tfhh in this forum. It needs one more chip - LS 32 - to solve this. Or a proper programmed GAL, etc.

I'll contact tfhh and ask.  Thanks.  I did check and compare the information at https://www.atarimax.com/jindroush.atari.org/acarts.html and it matches the boards available at https://www.pcbway.com/project/shareproject/OSSCART__OSS_4_in_1_Short_Cartridge_for_Atari_400_800_Computers.html.  (I traced the board from the pictures on the page.)  The boards at PCBWay don't have a LS32 chip.  (74LS32?) 

 

[GoodByteXL]

4 hours ago, reifsnyderb said:

The boards at PCBWay don't have a LS32 chip. (74LS32?)

When modifying the original OSS pcb it needs an additional 74LS32 if you plan to use the rest of the bank $D5 together with one of the OSS languages in M091 cart format.

I am not familiar with the boards from PCBway.

BITD I managed to modify one of my OSS carts to a 4-in-1 type hosting ACTION!, BASIC XL, BASIC XE, and MAC/65.

More than a decade ago I learned with the help of Hias that those carts lack proper decoding and modified my OSS-4-in-1 again.

[reifsnyderb]

6 minutes ago, GoodByteXL said:

When modifying the original OSS pcb it needs an additional 74LS32 if you plan to use the rest of the bank $D5 together with one of the OSS languages in M091 cart format.

I am not familiar with the boards from PCBway.

BITD I managed to modify one of my OSS carts to a 4-in-1 type hosting ACTION!, BASIC XL, BASIC XE, and MAC/65.

More than a decade ago I learned with the help of Hias that those carts lack proper decoding and modified my OSS-4-in-1 again.

Do you have any information on what mod you made?  

[GoodByteXL]

21 hours ago, reifsnyderb said:

Do you have any information on what mod you made?  

Yep, took it from the corresponding article I wrote for ABBUC magazine #105. It reads like this:

Quote

Hias proposed this solution for it, which fixes the lack of proper decoding in OSS Supercarts:

Pick up the CCTL signal in the cart, AND it with A4 to A7 and output the result as a new CCTL signal for the cart. Adding a 74LS32 is easy, it fits inside as there is sufficient space. All pins except pin 7 and 14 at the 74LS32 are bent up horizontally. Cut off the thin ends of the bent up pins.

 

Since all chips in my OSS carts are socketed, I assume this is generally the case. Next, pull the 74LS08 out of the socket and bend up its pin 11 horizontally, pinch off the thin part as well. This way the original CCTL signal from pin 15 of the cart connector to the LS08 gets disconnected.

 

Next solder the LS32 piggyback with pins 7 and 14 to pins 7 and 14 of the LS08. The bent up pin 11 of the LS08 gets connected to pin 8 of the LS32.

 

Connect at the LS32: pin 3 to pin 13, pin 6 to pin 12, pin 10 to pin 11.

 

Now the LS-pack can be put back into the socket. The connections to the address lines A4 to A7 and CCTL are still missing. These can be easily made with hookup wire. A4 to A7 I tapped on the solder side of the OSS board at the socket of the EPROM and pulled them over the top of the board to the component side and soldered them to the LS32 as follows: Pin 1 to A4, Pin 2 to A5, Pin 4 to A6, Pin 5 to A7. I picked up the connection for the new CCTL at the through hole above pin 15 of the eprom on the component side of the pcb and wired it to pin 9 of the LS32.

 

Now the addresses in OSS carts are decoded correctly. Conflicts with other hard-/software are avoided as long as the same addresses will not be used.

 

Edited February 16, 2022 by GoodByteXL

[reifsnyderb]

17 minutes ago, GoodByteXL said:

Yep, took it from the corresponding article I wrote for ABBUC magazine #105. It reads like this:

 

If I understand correctly, and without making a schematic diagram of this change, this change is to make sure pins A4 through A7 are low when banking?  Is there any concern about A4 through A7 as the original schematic ignores them?  Does the software try to change them?  Are there problems because of this?

 

Thanks!

 

Brian

 

[GoodByteXL]

4 hours ago, reifsnyderb said:

Is there any concern about A4 through A7 as the original schematic ignores them?  Does the software try to change them?  Are there problems because of this?

It is like written earlier ...

On 2/15/2022 at 10:07 AM, GoodByteXL said:

Please keep in mind that the original cart design M091 does lack a proper address decoding. While banking the whole bank $D5 is addressed, what causes other hardware or software using other parts of that bank top crash. For  correct schematics please contact tfhh in this forum. It needs one more chip - LS 32 - to solve this. Or a proper programmed GAL, etc.

Or in other words, the OSS supercart does not allow the usage of bank $D5xx as it kills what is there unless corrected.

Edited February 16, 2022 by GoodByteXL

[reifsnyderb]

22 hours ago, GoodByteXL said:

It is like written earlier ...

Or in other words, the OSS supercart does not allow the usage of bank $D5xx as it kills what is there unless corrected.

I contacted tfhh and he cleared up this confusion.  (A big thank you to tfhh!)  The problem is with stacked cartridges and I did not understand the issue as without a stacked cartridge there is no conflict and I did not consider stacked cartridges.  So, since SpartaDOSX uses $DFEx to select it's bank this will result in a crash because the OSS Cart only looks at the first 4 address bits and ignores the rest.  Once SpartaDOSX calls a bank whereby the address bits of it's call changes bits A0 and A3 a crash will result.  So any OSS Cart future design needs to ignore A0 and A3 if any of the higher bits are set.  I can see where an Or gate chip could fix be used to fix this.

[GoodByteXL]

15 hours ago, reifsnyderb said:

The problem is with stacked cartridges and I did not understand the issue as without a stacked cartridge there is no conflict and I did not consider stacked cartridges.

Yes and no - the problem arose back then when trying to engage bank $D5 for other uses, e. g. internal real time clocks. So it has not necessarily to be a 'stacked cart' but something using that bank. When resigning the those carts this fix should always be taken into account.

[reifsnyderb]

8 hours ago, GoodByteXL said:

Yes and no - the problem arose back then when trying to engage bank $D5 for other uses, e. g. internal real time clocks. So it has not necessarily to be a 'stacked cart' but something using that bank. When resigning the those carts this fix should always be taken into account.

Thanks for the info.  I've added Or gates.

[GoodByteXL]

Took some time to find it, but here is the oldest hint to this problem I know of:

ANALOG issue 45, page 23, Using BASIC XL's Hidden Memory by Robert Opitz