Here are the results of plain tos, maprom and nvdi: Not too shabby.
I haven’t look into modding maprom yet, but thanks for the tip, @agranlund.
BW
Here are the results of plain tos, maprom and nvdi: Not too shabby.
This is how I started out as on the face of it it's precisely what the 030's asynchronous bus is all about. I couldn't make it work.
My current boosters like the STE one do clock switching, 8/32mhz its all synchronised though as a simple GAL doesn't have the capability of much else. My SEC booster (still under development) run at 60Mhz all the time, and that took a lot of work to get it right. its literally been ongoing for years (mostly due to lack of time to work on it all) .Badwolf wrote: ↑Mon Sep 28, 2020 12:31 pm I ended up with two branches of the firmware: the 'Exxos' branch tried do what you suggest above, based on one of your old posts about fiddling with DTACK; the 'TF' branch did the clock switching (as Stephen made a comment that he only goes to 50MHz during fast ram cycles).
I think that's using the STE's own 32MHz (so it's in sync with the 8MHz), isn't it? That would make life a lot easier. Hence why I was thinking about trying a clock multiplier. It'd really simplify the switching, but never used one & not sure how stable they are / how long they need to become stable.
Cool. Have you had to implement different timings for different address accesses at all? It wouldn't surprise me if you have to be tighter on some chips than on the memory, for example.My SEC booster (still under development) run at 60Mhz all the time, and that took a lot of work to get it right. its literally been ongoing for years (mostly due to lack of time to work on it all) .
I don't think the trouble I had is at the 030 end, to be honest. It seems very forgiving in general (of course the translation from 030 lines to pretend-68000 lines that the bloody Falcon expansion bus makes you do is a PITA). I think most of the issues I've had is with getting the strobe lines in sync with what the mainboard expects. Using the Falcon's clock, you can pretty much wave them through. Maybe the delay from the CPLD when it's gating them is enough to throw something out of kilter.But anyway, I guess the 030 being more complicated is going to have more issues than the 68000 does So clock switching is probably good to start with until everything else is sorted out, then at least you could go back to it at a later date.
Yeah the STE has a master clock of 32MHz so its generally in sync with the 8MHz clock. The STFM clocks are all over the place which is why only a 16MHz clock switching topology is doable (the STFM also has 32MHz master clock).Badwolf wrote: ↑Mon Sep 28, 2020 2:50 pm I think that's using the STE's own 32MHz (so it's in sync with the 8MHz), isn't it? That would make life a lot easier. Hence why I was thinking about trying a clock multiplier. It'd really simplify the switching, but never used one & not sure how stable they are / how long they need to become stable.
Sort of yes.. for example the ST bus will use some slower timings, so RAM access etc is all happy.. a lot of the problems are that DTACK arrives earlier than when the data is actually ready.. on a 68K system , the CPU doesn't care, but when running 60Mhz, its a huge issue. I run at higher speeds for ROM access.. this is bottled necked by the 55ns ROM currently, so I have to use waitstates for that. I have a alt-ram boards which should cope with 60MHz fast-ram with the CPU.. But just one of those projects I don't have chance to work on at the moment although everything is actually built.
I wouldn't have thought the PLD delay would be a issue in general when talking to the 16MHz bus.. the delays are normally below 10ns.. If the delays are too long, your processing of data will just mean you skip over another cycle on the system runs marginally slower than it should..If you are running the CPU faster than 16 MHz, the CPU reacts faster and compensates for that delay anyway.Badwolf wrote: ↑Mon Sep 28, 2020 2:50 pm I don't think the trouble I had is at the 030 end, to be honest. It seems very forgiving in general (of course the translation from 030 lines to pretend-68000 lines that the bloody Falcon expansion bus makes you do is a PITA). I think most of the issues I've had is with getting the strobe lines in sync with what the mainboard expects. Using the Falcon's clock, you can pretty much wave them through. Maybe the delay from the CPLD when it's gating them is enough to throw something out of kilter.
I'd use SDRAM. You can get 128MB or more for cheap. Directly soldered. The controller should fit into something like XC95144XL as on CT6x cards or ACA cards from Jens. Or similar CPLD from Altera/Intel. These devices are still 5V tolerant.
What about some (quad)SPI expansion port for fast interfacing with some MCU based daughterboard, that would serve as gateway to USB, Ethernet, Wifi, etc..?Any thoughts or recommendations on any of the above brain dump appreciated
The GTL2000 looks interesting -- 22 bit width! But it seems to need external pull-up resistors, unless I'm reading that incorrectly?
If its being hooked to the CPU bus, it already has a pull up on the 5V side.