Project STacy (STaceX, TOS 2.06 & others)

[IngoQ]

The whole idea is to utilize the unused and unpopulated expansion slot, which is 100% compatible with Mega Bus. There are no 41612 connectors available anywhere. That is the same as a VME connector but with 24pins in 3 rows. This is why I have to make an adapter with 3 header strips and route the signals to two 34-pin floppy connectors that carry the signals to the Mega Bus via ribbon cables. End result should be that any Mega ST expansion card should work.

Okay, this far I can follow. It is basically an adapter to convert Stacy expansion slot to Mega Bus.

The point of the DIP64 socket was to eliminate a redundant Mega Bus adapter to be able to use AlanH's MonSTEr card. You would have STaceX -> Mega Bus -> Alan's DIP64 adapter -> MonSTEr. By providing a DIP64 socket that connects directly to the STaceX we would eliminate one step and save space.

And here I loose you

It is my understanding (and I might be wrong), that solutions like Magnum ST and Monster disconnect the CPU from the bus to be able to intercept lines and signals. To make these work you would need to do the same, or am I wrong?

[Atarian Computing]

The whole idea is to utilize the unused and unpopulated expansion slot, which is 100% compatible with Mega Bus. There are no 41612 connectors available anywhere. That is the same as a VME connector but with 24pins in 3 rows. This is why I have to make an adapter with 3 header strips and route the signals to two 34-pin floppy connectors that carry the signals to the Mega Bus via ribbon cables. End result should be that any Mega ST expansion card should work.

Okay, this far I can follow. It is basically an adapter to convert Stacy expansion slot to Mega Bus.

The point of the DIP64 socket was to eliminate a redundant Mega Bus adapter to be able to use AlanH's MonSTEr card. You would have STaceX -> Mega Bus -> Alan's DIP64 adapter -> MonSTEr. By providing a DIP64 socket that connects directly to the STaceX we would eliminate one step and save space.

And here I loose you

It is my understanding (and I might be wrong), that solutions like Magnum ST and Monster disconnect the CPU from the bus to be able to intercept lines and signals. To make these work you would need to do the same, or am I wrong?

The Magnum ST hasn't connected the IPL lines according to the schematics here: http://www.uweschneider.de/archive/Magn ... ltplan.pdf

I'd have to provide VCC though as the Mega Bus does not carry it.

[exxos]

I would assume Magnum ST works like any other alt-ram. Really it is just bolted on top of the CPU. CPU puts the address on the bus, then some gal logic will decode that address and issue chip enable lines to the DRAM. Then a few cycles later issued a tack in the CPU will read the data and terminate the cycle. So there should not be any real need to isolate the CPU.

There is some exceptions to this where you could isolate CPU from the bus, but this is getting complicated and will need even more gal logic to isolate the bus, so I will not mention that

But it sounds like you are trying to mash a lot of upgrades into one, once I finished the new 32 MHz booster for the ST FM, I will be making a proper alt-ram board, maybe even flash tos. I am not sure about IDE, it is actually a lot slower then DMA, but jookie has hinted he will be making Cosmo open source in the future, so I may build a very small basic version to fit over the top of the DMA chip, basically like a internal ultra Satan.

Monster does not work CPU boosters anyway, so a new alt-ram board will have to be designed to work at 32 MHz anyway this is just the first step.

[Atarian Computing]

I would assume Magnum ST works like any other alt-ram. Really it is just bolted on top of the CPU. CPU puts the address on the bus, then some gal logic will decode that address and issue chip enable lines to the DRAM. Then a few cycles later issued a tack in the CPU will read the data and terminate the cycle. So there should not be any real need to isolate the CPU.

There is some exceptions to this where you could isolate CPU from the bus, but this is getting complicated and will need even more gal logic to isolate the bus, so I will not mention that

But it sounds like you are trying to mash a lot of upgrades into one, once I finished the new 32 MHz booster for the ST FM, I will be making a proper alt-ram board, maybe even flash tos. I am not sure about IDE, it is actually a lot slower then DMA, but jookie has hinted he will be making Cosmo open source in the future, so I may build a very small basic version to fit over the top of the DMA chip, basically like a internal ultra Satan.

Monster does not work CPU boosters anyway, so a new alt-ram board will have to be designed to work at 32 MHz anyway this is just the first step.

Thanks. I might give Magnum ST a go myself. Problem is the MACH210 but I'm sure someone can program it for me. I'm also not absolutely certain about a TOS upgrade on the STacy as, according to Brad from Best, STacy has a special version of 1.04 due to a "shadow" chip that drives the LCD.

But, unless anyone of you sees a major flaw in my plans, I will proceed with the STaceX first and then have a go at the Magnum ST. At the very least this can be a learning experience for me.

Feel free to merge threads to my Project Stacy one. I will continue progress there.

[exxos]

Thanks. I might give Magnum ST a go myself. Problem is the MACH210 but I'm sure someone can program it for me. I'm also not absolutely certain about a TOS upgrade on the STacy as, according to Brad from Best, STacy has a special version of 1.04 due to a "shadow" chip that drives the LCD.

But, unless anyone of you sees a major flaw in my plans, I will proceed with the STaceX first and then have a go at the Magnum ST. At the very least this can be a learning experience for me.

Feel free to merge threads to my Project Stacy one. I will continue progress there.

The MACH210 is very hard to program without special software and hardware. I did look into it years ago as I was planning on recreating the Magnum, but untested hardware was about £200. People just moved to modern PLD is now instead. The problem is a lot of the RAM is now 3.3 V and causes problems interfacing to the 5 V logic.

I don't remember if Stacey has a special version of tos, I half seem to remember that it does not. It might be better asking darkLord about it.

[Atarian Computing]

The MACH210 is very hard to program without special software and hardware. I did look into it years ago as I was planning on recreating the Magnum, but untested hardware was about £200. People just moved to modern PLD is now instead. The problem is a lot of the RAM is now 3.3 V and causes problems interfacing to the 5 V logic.

I don't remember if Stacey has a special version of tos, I half seem to remember that it does not. It might be better asking darkLord about it.

I've talked to Darklord quite a bit about everything STacy related and he's been super helpful. He's not sure about the TOS though. Here's a thread where I got the info: http://atariage.com/forums/topic/258391 ... acy/page-2

In there is Brad's quote about the TOS

Q. Is it possible to do a selectable TOS, like 1.04 and 2.06 on the Stacy?

A Sorry No Robert. The Atari Stacy TOS chips are unique to the Stacy computer only because of the Atari
Custom LCD display Shadow Chip used only in the Atari Stacy and I think the ST book too.

Regards
Bradley Koda

However, in that same thread are implications that other TOS versions would work. Holger's patched TOS 3.06 for Darklord's PAK:ed STacy apparently had no STacy related patch done to it.

I might just have to try it myself. I might even copy the STacy TOS and compare it to a regular TOS 1.04.

Edit:

Here's what I've come up with so far. Routing is not done yet and this is bound to change. I have however printed a mockup and sizewise it will do the job. The metal shielding will be in the way and would have to be removed anyway in order to use STaceX.

STaceX proto 1.jpg (156.25 KiB) Viewed 7008 times

[exxos]

However, in that same thread are implications that other TOS versions would work. Holger's patched TOS 3.06 for Darklord's PAK:ed STacy apparently had no STacy related patch done to it.

I might just have to try it myself. I might even copy the STacy TOS and compare it to a regular TOS 1.04.

Does not seem to be any special Stacy version here..

http://www.avtandil.narod.ru/tose.html

I know this question has come up before in the past but I cannot exactly remember sorry as far as I know Stacey just uses generic tos 104.

[Atarian Computing]

However, in that same thread are implications that other TOS versions would work. Holger's patched TOS 3.06 for Darklord's PAK:ed STacy apparently had no STacy related patch done to it.

I might just have to try it myself. I might even copy the STacy TOS and compare it to a regular TOS 1.04.

Does not seem to be any special Stacy version here..

http://www.avtandil.narod.ru/tose.html

I know this question has come up before in the past but I cannot exactly remember sorry as far as I know Stacey just uses generic tos 104.

I really hope so

[rpineau]

Ok so the adapter, if you want to connect CPU replacement need all the CPU signals.
If you also want it to be Mega Bus compatible it needs the same signals as the MegaBus.
These 2 statement basically conflict with each other as the Mega Bus has some extra signals as we saw for the interrupt that are not direct mapping to IPL lines but go through a 8 to 3 encoder so that the proper IPL level can be asserted when there is a INT on the Mega Bus (level 3, 5 or 7).
So to be able to put a CPU card on there you need to have a way to switch between Mega Bus "mode" to pure 68K mode. As far as I can see only the INTx to IPLx line need to be swapped so that could be done with a 74LS 157 and a way to switch from one to the other (as simple switch can work).

As for the track length .. the shortest the better... always. If you intend to put more than one card... buffers .. buffers ... (data and address line at least).

And then there is the CPU .. that need to be disabled if you add a CPU card on the 68K expansion connector.. that's why card with their own CPU plug in the 68k socket as they fully replace it in most case. If you don't want to remove it you'll need some special logic to disable it using HALT and BR/BG (the 68K will try to retake the bus after every bus master switch ...).

Rodolphe

[Atarian Computing]

Ok so the adapter, if you want to connect CPU replacement need all the CPU signals.
If you also want it to be Mega Bus compatible it needs the same signals as the MegaBus.
These 2 statement basically conflict with each other as the Mega Bus has some extra signals as we saw for the interrupt that are not direct mapping to IPL lines but go through a 8 to 3 encoder so that the proper IPL level can be asserted when there is a INT on the Mega Bus (level 3, 5 or 7).
So to be able to put a CPU card on there you need to have a way to switch between Mega Bus "mode" to pure 68K mode. As far as I can see only the INTx to IPLx line need to be swapped so that could be done with a 74LS 157 and a way to switch from one to the other (as simple switch can work).

As for the track length .. the shortest the better... always. If you intend to put more than one card... buffers .. buffers ... (data and address line at least).

And then there is the CPU .. that need to be disabled if you add a CPU card on the 68K expansion connector.. that's why card with their own CPU plug in the 68k socket as they fully replace it in most case. If you don't want to remove it you'll need some special logic to disable it using HALT and BR/BG (the 68K will try to retake the bus after every bus master switch ...).

Rodolphe

Thanks. This is very helpful. I will concentrate on making a Mega Bus adapter for now.

The purpose is to either have a Mega Bus or 68K bus on the STacy. Not both at the same time. STaceX would provide all necessary signals for either application.

Since I get 4 unused pins on the two HDR2x17 connectors, I will route them to four header pins on the STaceX that can be used for providing the IPL signals to the DIP64 adapter in the future.