rpineau

Would you ship it if I pay for the shipping ?

Brilliant.

I'm in USA and I might be able to do that mod for you. contact me directly. Rodolphe

This is the so called blitter patch. It's usually on a small board soldered to the cpu, this one was done with the chop (flip-flop) on top of another one then wired to the cpu. Rodolphe

so the connector above are not easy to find so we've also ordered some APM G832MB011206222HR and G832MB111205222HR receptacle and plugs and we're going to check the mechanical strength (these are also 120 pins so it's a direct mapping from one to the other for me in Eagle). We'll keep you posted on our progress. Rodolphe

I'm going to take a look at the Hirose FX2-120P-1.27SV and FX2-120S-1.27SV receptacle and connector. I'll order a set and will take some measurements. This doesn't mean we'll be able to put any and all cards in the STE, but if we put the connector as far as possible toward the back we can may be have "short" cards that fits. Rodolphe

these are not easy to solder and we still need a lot of connections ( 96 signals so far and we're planning on adding another 8 for card IRQ ) which is why we chose a simple pin header connector with 2x 2 rows (56 + 40 which will latter be 56 + 48). If you have a good example of something that can allow board stacking (don't forget that we have the 68020 on a socket and the 2 PLCC sockets for the TOS) and leave enough space for the component between the board we could look into it. This doesn't solve the fact that there is little to no space in the STE to stack boards. Rodolphe

Hi everyone. We now have some very stable working code and we've been testing this for the last 2 weeks and it's very stable. The same code run on the STE and MegaSTE which is a good thing. We're now facing the mechanical issue of fitting the card in a STE and closing it.. as we have an expansion port for cards. On the MegaSTE this is not an issue as there is a lot of space above the card. On STE .. with our current connector (see image) we can't even close the machine, let alone put a card in it on top of the main cpu board. So the question is ... what do people want for a STE (and STF which has even less space) ? Is a simple 32MHz 68020 card with no expansion port enough (so no additional RAM, Video, network, .....) ? Adding some SRAM in 32 bit mode is an option but is fairly costly and will require us to rework the board to be able to fit the component (probably a max of 8MB with Cypress CY62167ELL-45ZXI SRAM as they are 5V devices) Or do you guys want the card with an expansion port .. which mean re-casing the STE ? (and how would you do that .. PC tower ? ) but will allow for better expansion board (DRAM, ...) so let us know. Picture : http://www.rti-zone.org/images/2017-02-05-3050.png

On the MegaSTE, you probably blew the keyboard connector fuse. So you probably need to first change that (I had to do it on mine for other reason). I never used an Eiffel interface so I can't advise on that part. Regards, Rodolphe

So I have been fighting a problem for a few weeks now. One of the GB622 test was not working at all, total screen corruption, super slow. The test is "VDI Text Effects". If I disable the blitter, the test works. My MegaSTE has a combo GSTMCU with the integrated blitter. Juliusz has an external blitter and didn't have any issue. Everything else was working and the machine was very stable (bus at 8MHz, no 16KB cache). Yesterday I finally got it working. I had to delay the CPU /AS by one 32MHz cycle before using this variable in our general strobe sync VHDL process. Everything works now and the machine is very stable still. My guess is that combo chip react faster to /AS then the external Blitter and some data was not quite stable on the bus when the integrated blitter was reading it. With this solve we're now good to move on the 32 bit TOS (I already have the 2 eprom on my board). The current result in GB622 : Display : 151% CPU : 467% Average : 224% As I'll be travelling and out of the country until the end of the month I don't know how much progress we'll make on this but at least we have a stable working base. Rodolphe

You can find the schematics there : http://dev-docs.atariforge.org

Last time I had a chat with them it ended up with them telling me to shove it where the sun doesn't shine and that they will never make any effort to make it Atari compatible ... so even though they seem to have changed their mind, I'm not to sure I want to talk to these guys again. Rodolphe

Did they add the VMA/VPA/E signals support ? If not, it's not going to work on a ST (they are not used on Amiga).

We've made huge progress. The STE board has been tested in a MegaSTE and is now working at full 32MHz (no clock switching) and was tested up to 35MHz. We tried 40MHz but got a black screen. So for now we're continuing with 32MHz. We still have a few issues to fix, mostly slow rising time on tri-state pins so we need to change some pull-up from 4.7K to 1K to see if it helps. This is needed to allow us to use the expansion bus and allow a bus master on it. The new code is fully written in VHDL using the Xilinx tools and gives us a lot more options and is easier to modify/maintain. We still need to do a few things: - 32 bits TOS access at 32MHz (will probably need 1 or 2 wait states with 55ns ROM). - Blitter TOS access when the blitter is bus master (need to multiplex 32 bits to 2x 16b its) - Fix pull-up to allow bus master on the expansion bus We have a preliminary doc for the expansion bus (eagle file and pinout doc available upon request). Rodolphe

http://www.exxoshost.co.uk/atari/last/V1STE/index.htm

If you need a US TOS 2.06 let me know, I can burn you one.

This is based on the 68020 card made by Jean Conter a long time ago (1992). That's part of why I started my 68020 project and the current GAL are very simple and don't offer any option for async frequency (which is why we started fresh after trying with this). It's a good simple 68020 card.

Thanks Right now we're routing the cards (STE version and MSTE version), reviewing the schematics over and over to make sure we haven't forgotten something, running all signals we need for testing to headers.. and trying to route with the smallest amount of vias .. so today I routed the STE board about 20 times, moving one or two component at a time to try to help the routing. Juliusz did a schematics review and had me do a few changes to help with debugging. So we're getting close to sending the new boards to the PCB manufacturer. After that .. soldering and then coding for the XC95144XL .. so there is a lot of work ahead .. but we're having fun doing it and we're learning Rodolphe

Quick update. We've made some progress on running at constant 32MHz.. but it crashes on memory test and other bus access. So not there yet. We're also running into issues with the CPLD IDE (WinCUPL) that make coding on this very ... painful to be polite. So we've made the decision to do a v2 board and use a Xilinx CPLD : XC95144XL (100-pin TQFP). This means a new round of board, learning to solder these with my new reflow oven (aka learning to lay down the solder paste in the right quantity then fix bridges between pin), learning the Xilinx tools (and VHDL)... So we're making progress and learning from our mistakes along the way. Rodolphe

Do not mistake CPU cache for external cache. CPU cache are of course way faster. Here we were talking about external caches (like the one on the Mega STE). The Mega STE cache uses 70ns SRAM. We plan on using 55ns SRAM (and may be in the future 60ns DRAM). That's what exxos meant by faster FastRAM than the "cache". Rodolphe

The 68020 has a 256 bytes instruction cache (I-Cache) that is enabled by default (by the TOS). That's the only cache on our card. We don't add an extra cache (like what the Mega STE has). The 68030 has 2 caches, instruction and data (I-Cache and D-Cache) of 256 bytes each. These are also enabled by the TOS. So there is no need for any drivers to take advantages of the CPU cache(s). Rodolphe

I would probably help but I don't know by how much.

Quick update, MegaSTE 8/32 MHz without the 16KB cache : GEM Bench v4.03 Ω Ofir Gal - 3 March 95 ============================================ Mega STE TOS 2.06 AES v3.20 GEMDOS v0.32 MiNT not present Blitter Enabled NVDI not present Video Mode: 640*400*2 FPU not present Run and Malloc from STRAM Ref: MSTE + Blitter, ST High ============================================ GEM Dialog Box: 4.840 94% VDI Text: 4.510 111% VDI Text Effects: 9.145 134% VDI Small Text: 4.875 112% VDI Graphics: 10.275 138% GEM Window: 1.380 95% Integer Division: 1.560 567% Float Math: 10.705 67% RAM Access: 2.940 107% ROM Access: 2.075 151% Blitting: 1.650 105% VDI Scroll: 3.575 111% Justified Text: 4.450 109% VDI Enquire: 2.295 72% New Dialogs: 6.340 91% ============================================ Graphics: 106% CPU: 223% Average: 137%

So I got some 20ns SRAM to replace my cache and after that I was able to enable the cache at 16MHz. So the cache can work with faster SRAM. I ran into more issue mostly on the 8 to 16MHz switch. If the system clock (from the 68000 socket) is directly connected to the 68020, the 8 to 16 MHz switch works most of the time (I still get some craches 3 out 5 times on boot when CPX are loaded as GENERAL.CPX is what does the frequency switch). Once at 16MHz I can enable the cache. If I save the config with 16MHz with cache enable, it's almost a 100% crash are CPX load time. So I think that when the MSTE switch frequency the switch is not clean and we get some glitches that the 68020 doesn't like (but apparently doesn't cause issues with the 68000 .. probably because it's slower). I'm guessing a DTACK arrives to early, the 68020 decodes it (even though we delay by 1 clock cycle to resync with the ST on a 4 clock cycle) and tries to read data on the bus when it's not yet valid. We might not have that issue later when we run the 68020 at full 32MHz async. Also, the MSTE doesn't support enabling the cache at 8MHz (I wanted to test 8/32 MHz with cache). If you write $FD (8MHz with cache) to $ffff8e21.w and re-read it, it return $FC .. aka 8MHz no cache. I've look at the MSTE cache schematics and will see if there is a way to force enable the cache by forcing one of the GAL signal (not sure that's going to work but I'll see). The pure gain of just the 68020 is not that great overall. Also this is with our first version of the CPLD code. A lot of progress has been made but I didn't have time to test the new code on this machine yet. I'll try to post some result at 8/32 (without the cache for now) to show the difference the clock can make. MegaSTE 68000 at 16MHz with 16K cache MegaSTE 68020 at 16MHz with 16K cache GEM Bench v4.03 Ω Ofir Gal - 3 March 95 GEM Bench v4.03 Ω Ofir Gal - 3 March 95 ============================================ ============================================ Mega STE TOS 2.06 Mega STE TOS 2.06 AES v3.20 AES v3.20 GEMDOS v0.32 GEMDOS v0.32 MiNT not present MiNT not present Blitter Enabled Blitter Enabled NVDI not present NVDI not present Video Mode: 640*400*2 Video Mode: 640*400*2 FPU not present FPU not present Run and Malloc from STRAM Run and Malloc from STRAM Ref: MSTE + Blitter, ST High Ref: MSTE + Blitter, ST High ============================================ ============================================ GEM Dialog Box: 4.745 96% GEM Dialog Box: 5.220 87% VDI Text: 5.040 99% VDI Text: 5.605 89% VDI Text Effects: 12.250 100% VDI Text Effects: 11.400 107% VDI Small Text: 5.520 99% VDI Small Text: 6.170 88% VDI Graphics: 14.230 100% VDI Graphics: 11.055 128% GEM Window: 1.340 98% GEM Window: 1.410 93% Integer Division: 8.815 100% Integer Division: 3.095 286% Float Math: 7.170 101% Float Math: 7.130 101% RAM Access: 3.155 99% RAM Access: 2.005 157% ROM Access: 3.145 100% ROM Access: 2.030 155% Blitting: 1.740 100% Blitting: 1.785 97% VDI Scroll: 3.925 101% VDI Scroll: 4.135 96% Justified Text: 4.850 100% Justified Text: 5.310 91% VDI Enquire: 1.755 94% VDI Enquire: 1.790 93% New Dialogs: 6.065 95% New Dialogs: 6.325 91% ============================================ ============================================ Graphics: 98% Graphics: 96% CPU: 100% CPU: 174% Average: 98% Average: 117%

TOS 2.06 has direct support for 68020.