Alt-RAM logic brain fart

[Badwolf]

I'm pretty sure NVDI on the Falcon will make sure the Blitter is not being touched though?

Great idea! I’ve tried emutos + NVDI, but that does sound like an easy win with TOS.

Here are the results of plain tos, maprom and nvdi:

032E9F8D-67BA-4190-A0CF-07A660BF8E45.jpeg

Not too shabby.

I haven’t look into modding maprom yet, but thanks for the tip, @agranlund. :)
BW

[Badwolf]

Though really, you should be able to run the CPU at full speed all the time anyway. Mostly you just have to resync DTACK ... Wait like 2 8mhz clocks then let the cpu see dtack kinda thing.

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.

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).

The TF branch got there first, but it's definitely inelegant and there are still some issues when my 48MHz oscillator and the onboard 16MHz clock start up sufficiently out of phase to crash on enabling. If it survives the moment of turn-on, it's usually rock solid for hours, but sometimes it needs a restart or two until it'll enable cleanly.

I was thinking about using a clock multiplier for the next revision, or perhaps going to a far faster base oscillator and sampling the onboard clock, like Stephen does. Not sure which would be more effective, or if either are needed if I can get the alternate firmware to work.

Cheers,

BW.

[exxos]

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).

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) .

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.

[Badwolf]

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.

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.

Incidentally, having recently acquired an STE, I very much have my eye on your booster there. But one project at at time :lol:

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) .

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.

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.

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.

Definitely worth a revisit, though. :-)

BW.

[exxos]

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.

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).

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.

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 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 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]

Quick update on progress before I take a couple of weeks break on holiday.

The below are comparisons against the same Falcon with NVDI installed but the accelerator card disabled. I have to have NVDI at the moment as I've not developed Maprom to replace the blitter yet. This is at least a fair comparison of what it's doing.

I've just be tweaking and paring down firmware. I've removed my counter routine (that counted the processor 'S' states) and replaced where it was used with cascading flip flops as delay lines. It's reduced my macrocell footprint, but I'm running out of line routeing space. I've had to jumper some signals to other parts of the CPLD. I may be running up against the limits of the old Max3000A.

Anyway, by holding off returning to full speed after a mainboard access for a couple of cycles, I've avoided the (slow) switch back in to 16MHz mode in between the consecutive word accesses of a longword retrieval. This has speeded up RAM access from 89% normal to 103% normal (presumably the extra 3% is when it can jump back to 50MHz between longword retrievals).

Also I've tweaked the altram DSACK signal timing and got the altram test down to just under 12 seconds (speed boost of 157% over the TT reference figure). Not bad for 16 bit. When using maprom to put TOS into altram, that yields an impressive 356% figure for ROM access.

Unfortunately, with only 1MB altram available at the moment I have to choose to either use maprom to get quick ROM routines, or reserve the whole 1MB for the OS. The latter means I can run Gembench from altram.

With Maprom, running Gembench from ST-RAM:

IMG_3860.jpeg

Without Maprom, Gembench run from AltRAM:

IMG_3859.jpeg

I want to consolidate the bodges I've had to apply to this board into a new revision, but before I do that I want to decide on the next steps to experiment with, so I can build in support.

The obvious ones are:-

* Try a clock multiplier rather than a crystal to simplify the switching. I've a couple on order to experiment with. I'll probably just bodge them into the crystal socket, so that's not a biggie.

* Move away from the obsolete Max3000A CPLD. That will probably mean going to 3.3V, so I'll need some bulk buffering. Stephen uses 8 bit SN74CB3T3245s for this, which look nice, but level shifting two lots of 32 bit lines would need eight of them, plus the control signals. Does anyone have any recommendations for similar, directionally auto-sensing level translators?

* More memory. This was the main aim of this project. Memory, and lots of it. DRAM is the only real option here. This will again need 3.3V infrastructure and probably a bigger CPLD.

* 32 bit memory. I kept the 16 bit bus for simplicity in this early design. This is the second revision, but the first that's worked. It's time to get the benefit of those opened up lines.

* Onboard ROM. I'm thinking of putting a flash chip on the board for quick-access and repogrammable ROM. Does anyone have any hint or tips on doing in-circuit external programming of a flash chip? Else I might try to fit a TSSOP48 ZIF socket on here for now.


Otherwise, whilst mulling those over, I can try experimenting again with the 'exxos' delayed DTACK clock domain technique on this board and I've a *significant* issue I need to investigate: the DSP. Anything that tries to use the DSP hangs. I'd kind of overlooked it in development as I don't really use the DSP much, but it's one of the big Falcon selling points so I ought to spend a bit of time learning how it is talked to and see if there's anything to do about it. My FPU's been off the board for a while (long story going back to 1996...) and I suspect that'll be a similar situation as I simply haven't thought about them. I'll have to try to lay hands on a minimalistic program for the DSP to help me debug. 'Hello Word' for 56K, I suppose.

Any thoughts or recommendations on any of the above brain dump appreciated :-)

Cheers,

BW.

[exxos]

Try the GTL2003 type stuff :)

[ctirad]

* More memory. This was the main aim of this project. Memory, and lots of it. DRAM is the only real option here. This will again need 3.3V infrastructure and probably a bigger CPLD.

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.

Any thoughts or recommendations on any of the above brain dump appreciated :-)

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..?

[Badwolf]

Try the GTL2003 type stuff :)

The GTL2000 looks interesting -- 22 bit width! But it seems to need external pull-up resistors, unless I'm reading that incorrectly?

BW.

[exxos]

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.

https://www.exxosforum.co.uk/forum/viewt ... 229#p16229