rpineau Posted December 6, 2015 Author Share Posted December 6, 2015 I manage to run more test (as did Juliusz) and we now have better result with the 8/32 MHz switching : 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: STE + Blitter, ST High ============================================ GEM Dialog Box: 5.485 100% VDI Text: 5.315 103% VDI Text Effects: 10.665 138% VDI Small Text: 5.840 104% VDI Graphics: 11.255 209% GEM Window: 1.530 103% Integer Division: 1.560 1153% Float Math: 10.735 124% RAM Access: 2.945 213% ROM Access: 2.535 248% Blitting: 1.720 106% VDI Scroll: 3.970 107% Justified Text: 5.105 106% VDI Enquire: 2.480 107% New Dialogs: 7.010 108% ============================================ Graphics: 117% CPU: 434% Average: 201% Not a huge improvement but faster is always good. We have a few issues on MegaSTE : If we enable the 16KB cache : freeze When in 8/32 mode when general.cpx switch to 16MHz no cache: freeze. So the switch from 8 to 16MHz on the mother board probably create a glitch. If I set the jumper to directly get sys_clk from the mother board (so no 32MHz switching), the machine works fine and switch ok from 8 to 16MHZ (mother board). As the goal is to run always at 32MHz for the CPU we're not going to spend to much time tracking the issue with 8/32 to 16/32 switching. As for the MSTE cache, I'm still trying to figure out what's going on but I haven't had time to put the logic analyzer on it (may be next weekend). Quote Link to comment Share on other sites More sharing options...
GadgetUK Posted December 7, 2015 Share Posted December 7, 2015 Brilliant update - amazing how far you guys have come with this upgrade! Quote Link to comment Share on other sites More sharing options...
rpineau Posted December 25, 2015 Author Share Posted December 25, 2015 (edited) 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% Edited December 25, 2015 by rpineau Quote Link to comment Share on other sites More sharing options...
rpineau Posted December 30, 2015 Author Share Posted December 30, 2015 (edited) 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% Edited December 30, 2015 by rpineau 1 Quote Link to comment Share on other sites More sharing options...
Xebec Posted January 3, 2016 Share Posted January 3, 2016 I wonder if the 68030 with it's additional data cache (256 byte) would make a big difference out of the box? Quote Link to comment Share on other sites More sharing options...
rpineau Posted January 3, 2016 Author Share Posted January 3, 2016 I would probably help but I don't know by how much. Quote Link to comment Share on other sites More sharing options...
Lynxpro Posted January 3, 2016 Share Posted January 3, 2016 How large of a cache can you actually use with a 68020 in an ST? Or is it merely down to drivers? Quote Link to comment Share on other sites More sharing options...
rpineau Posted January 3, 2016 Author Share Posted January 3, 2016 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 1 Quote Link to comment Share on other sites More sharing options...
exxosuk Posted January 4, 2016 Share Posted January 4, 2016 It's also worth noting that "fast-ram" will out preform any cache anyway. Run the entire program at 32mhz CPU & RAM instead of just a few loops here and there in a cache. As Rodolphe said, the CPU itself ( 030 anyway) has instruction and data caches built in. So no need to add cache's to those systems. 020 only has Instruction cache, so while a external data cache could increase some programs performance, it would still be a lot faster to run the software in "fast-ram". Quote Link to comment Share on other sites More sharing options...
Christos Posted January 4, 2016 Share Posted January 4, 2016 It's also worth noting that "fast-ram" will out preform any cache anyway. Run the entire program at 32mhz CPU & RAM instead of just a few loops here and there in a cache. As Rodolphe said, the CPU itself ( 030 anyway) has instruction and data caches built in. So no need to add cache's to those systems. 020 only has Instruction cache, so while a external data cache could increase some programs performance, it would still be a lot faster to run the software in "fast-ram". That's false! Caches are way faster than RAM. You could easily check it on the CT60, where switching caches off has quite a dramatic effect on performance. Quote Link to comment Share on other sites More sharing options...
rpineau Posted January 4, 2016 Author Share Posted January 4, 2016 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 1 Quote Link to comment Share on other sites More sharing options...
rpineau Posted January 28, 2016 Author Share Posted January 28, 2016 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 Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted March 4, 2016 Share Posted March 4, 2016 Wishing you every success with this project, it's been fascinating reading the work done to date. Quote Link to comment Share on other sites More sharing options...
rpineau Posted March 4, 2016 Author Share Posted March 4, 2016 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 3 Quote Link to comment Share on other sites More sharing options...
GadgetUK Posted March 4, 2016 Share Posted March 4, 2016 Great news! All sounds positive! Quote Link to comment Share on other sites More sharing options...
Tillek Posted March 7, 2016 Share Posted March 7, 2016 Looking forward to this too. The BBS is running on a MegaSTE and while it works just fine in 16MHz, the Fidonet stuff could go a bit faster. I'd love to see how this makes it better. Quote Link to comment Share on other sites More sharing options...
+DarkLord Posted March 7, 2016 Share Posted March 7, 2016 Just going from 8mhz to 16mhz (Adspeed accelerator) on my Mega ST made quite a bit of difference in overall performance. I can imagine that this project will blow that out of the water. Quote Link to comment Share on other sites More sharing options...
rpineau Posted September 23, 2016 Author Share Posted September 23, 2016 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 3 Quote Link to comment Share on other sites More sharing options...
rpineau Posted December 12, 2016 Author Share Posted December 12, 2016 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 1 Quote Link to comment Share on other sites More sharing options...
rpineau Posted February 5, 2017 Author Share Posted February 5, 2017 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 1 Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted February 13, 2017 Share Posted February 13, 2017 Could a slimstack connector be utilised instead? Quote Link to comment Share on other sites More sharing options...
rpineau Posted February 13, 2017 Author Share Posted February 13, 2017 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 Quote Link to comment Share on other sites More sharing options...
rpineau Posted February 14, 2017 Author Share Posted February 14, 2017 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 Quote Link to comment Share on other sites More sharing options...
rpineau Posted February 16, 2017 Author Share Posted February 16, 2017 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 1 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.