Fun things to do with an MC68EC020....

Nagging hardware related question? Post here!
User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Fun things to do with an MC68EC020....

Post by Dave »

Yep. It uses 30mA in use and low uA if in standby - not that it will be a problem in this application.

I think I'll order 12 for prototyping (two full 12MB sets) to keep costs reasonable, then if it becomes a working design I can order 100+ to get the price break.

I did just find them for 25% cheaper from a US supplier, so memory costs just dropped.

Welp, there you go. I think I have the basis of a super-duper-gold-card++ *laughs*


User avatar
janbredenbeek
Super Gold Card
Posts: 629
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: Fun things to do with an MC68EC020....

Post by janbredenbeek »

tofro wrote: Yep, SRAM is designed to hold its contents with no further action as long as Vcc is applied. It consists of flip-flops rather than capacitive storage in DRAMs and doesn't need any refresh activity. If I guess right what you've selected, the Cypress SDRAM even has a sleep mode that powers down the RAM if address lines don't show activity.
I remember back in '87 or so I had a plug-in module like a ROM dongle with 16K SRAM on board. It could be set to read-only or read-write by means of a switch and operated at ROM speed so was very useful to test software before burning it into EPROM. It even had a battery backup but sometimes its contents got corrupted due to the voltage pulse which occurs at switch-on or switch-off. This could of course be due to insufficient filtering or buffering (mind you, I've had numerous occasions where the QL crashed when simply turning the light off or on!) but I think this is something to consider with SRAM.

Jan.


Nasta
Gold Card
Posts: 443
Joined: Sun Feb 12, 2012 2:02 am
Location: Zapresic, Croatia

Re: Fun things to do with an MC68EC020....

Post by Nasta »

1) The widest (data bus width) organization gives the least loads on the various buses. Keep in mind that all address lines on all SRAM chips are in parallel, but NOT the data lines - data lines go one per chip pair.

2) A 68020 access cycle takes 3 clocks of which approximately 2 are actually active. Decoding times must also be taken into account as well as data set-up and hold. What it comes down to is, 55ns SRAM = ~33MHz EC020 (no wait states), 45ns SRAM = ~40MHz EC020 (no wait states). The 020 still benefits from fast RAM, even with the cache enabled.

3) SRAM is called static because once data is written it is retained as long as the power supply is retained, no further activity (hence static) required. If data is to be retained with a battery (and it does NOT), care should be taken to disable the CS signal on the SRAM in accordance with the power supply going from normal to data retention levels. Not needed here and not really relevant, but just saying...

4) 68040 uses a completely different bus and would need twice the speed or better SRAM to operate at zero wait in all circumstances. 68060 uses the same, at an even higher clock. HOWEVER. 68030 might be able to use the SRAM at peak speed, but with 45ns (not to mention 55ns) SRAM it will be limited to about the same clock rate as the 68020. These two CPUs do not differ that much in performance per clock cycle and most of the advantage of the 68030 in raw speed comes from it being available for higher clock speeds, and having a burst mode which transfers 4 consecutive long words, one each every 2 cycles after the initial 2 or (more likely) 3 clock cycle set-up. 68040/60 also does not have dynamic bus sizing which is crucial in this application, and reduces the burst mode timing to 2+1+1+1 clock cycle, where 1 clock cycle will typically be twice the speed of the aforementioned SRAM. 68040/60 are most suited for SDRAM (_not_ DDR).

5) CMOS compatibility would mean that the _INPUT_ logic level transitions are defined at 1/3 (1 to 0) and 2/3 (0 to 1) of the power supply voltage. The outputs normally go rail-to-rail, i.e. zero is virtually 0V, one is virtually the power supply voltage. TTL on the other hand defines 1 to 0 transition at around 0.8-1V, and 0 to 1 at around 2.2V. This means that any CMOS output operating at around 2.5V and above (to the 5V common maximum) will properly drive a TTL compatible input. The TTL output driving a CMOS input may not work - because TTL is required only to get over that 2.2V as it goes to 1, while at 5V, the corresponding CMOS logic treshold is 2/3 of 5V, i.e. 3.33V. In reality this is very rarely a problem as the levels are specified for maximum loading, AND, as TTL is taken as standard even for CPUs that are internally CMOS, the inputs will operate as if they were TTL regarding voltage levels, but with far less current loading (being CMOS and not really TTL).
What it means in this case is, that the SRAM uses TTL levels at it's input, and may not swing it's output over 2/3 of the power supply, even if it is 5V. The reason for this is that most modern 5V CMOS chips with high integration internally use a core running at a lower voltage and an internal regulation system. This is particularly true of die-shrunk CPUs, CPLDs and similar chips that were originally manufactured for 5V operation only and then 3/5V versions became available. Because they all still have to correspond to the old TTL standards, it will work just fine (also note that 3.3V CMOS logic is compatible with TTL logic levels almost perfectly, since 1/3 and 2/3 of the power supply is 1.1 and 2.2V respectively).
There is not going to be any compatibility problem here as long as the chips that connect directly all run from the same power supply. If logic levels need to be converted, there are chips for that. Also, sometimes it pays to drive formerly TTL specified signals at 3.3V CMOS levels if these signals are now driven by CMOS outputs (such as from more modern chips) - less interference will occur as the voltage swings and capacitive current spikes as well as reflections of the ends of tracks are smaller.

6) Power supply current figures are much smaller in reality because the maximums imply chip select being active 100% of the time. Because the CPU only accesses one location at a time, depending on the width of the access it only ever falls within one pair of chips at any given time (assuming only RAM is accessed, which can be taken as true 99% of the time). Also, during a cycle, chip select is not active 100% of the time. Finally, the access may not be done a the fastest possible speed. As a consequence, SRAM memory uses very little power. At full speed, one can realistically expect around 50mA for the entire 12Mb. It is not uncommon for a GAL or similar small PLD chip that generates the required SRAM chip selects, to consume more than that!


User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Fun things to do with an MC68EC020....

Post by Dave »

It's been an odd day. In picking away at this, I have been wondering if I should do something quick and easy first, but all the low hanging fruit has already been picked. There are at least two QubIDE replacements, each with 512K. There's a replacement floppy interface. I don't know what simpler project would be useful to the community and work to refresh my skills.


Silvester
Gold Card
Posts: 436
Joined: Thu Dec 12, 2013 10:14 am
Location: UK

Re: Fun things to do with an MC68EC020....

Post by Silvester »

Dave wrote:It's been an odd day. In picking away at this, I have been wondering if I should do something quick and easy first, but all the low hanging fruit has already been picked. There are at least two QubIDE replacements, each with 512K. There's a replacement floppy interface. I don't know what simpler project would be useful to the community and work to refresh my skills.
I guess the two most useful things for retro BBQL'ers would be TK2 on ROM port (invaluable extension to QDOS by same author) and battery backed clock. Providing both off ROM port avoids user having to open QL and offers possibilities off NET port using TK2 built-in network device (N1_ to N8_).

In place of 7410 (obsolete?) use one GAL and either MM58274C (as SGC) or DS1374 (Q68) as RTC. A 64K EPROM (4x16K pages) could hold full TK226 (*) with room for code to manage RTC (copy/set/dialogue). The 4 bits (MM58274C) or 3 bytes (DS1374) of battery backed memory could store option: TK2 enable/disable, EPROM page, run N1_boot, user function, etc.

Another related project, as mooted already by others on forum, would be QL compatible NET device (rPi/AVR) which could know enough about dialogue to provide simple external filing system (LOAD 'N1_program_bas', etc). Nothing too ambitious though (ie. no fancy OPEN#3;'N1_con' device stuff). Also avoids opening up QL, and would be relatively simple for inexperienced users to use (N1_ to N8_ devices, or through NET_USE mdv).

Though to retain authentic retro look it would need case similar to original (perhaps slightly bigger to hold battery/superCAP)

I guess you'd need to do a quick straw poll to see if something as useful as TK2+RTC had sufficient interest.

(* TK226 less CLOCK/ALARM which could be stored in another 16K page and RESPR'd into RAM. Leaving two spare 16K pages for alternate toolkit etc.)


David
User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Fun things to do with an MC68EC020....

Post by Dave »

That's a good idea.

One I was considering was a microdrive bridge, to plug onto the QL microdrive expansion socket and allow 2 more microdrives to be connected. With a nice 3D printed QL-matching case and reset button extender...

There should really be a separate thread for this.... Lots of good ideas the community could pick over anyone could take on any project.


Timbucus
ROM Dongle
Posts: 49
Joined: Sat Apr 01, 2017 12:14 am

Re: Fun things to do with an MC68EC020....

Post by Timbucus »

I would certainly like to get a TKII / RTC cartridge - now if it had a way of adding a plug and play mouse of some kind it would be ideal... but, we could address that with something easy and cheap for the actual serial port I suppose. I am trying to find a way to use my SERIAL mouse at the moment... seems I need some commercial software which I can't locate... or write my own.

Especially if the rPI QL/Spectrum NET interface was working as that as you say is an elegant solution that is even usable by unexpanded users - not everyone who gets hold of an old QL is going to want (or be able) to jump into the IDE or even floppy world that you long time users find second nature... or pay out for expansion memory immediately.

E.g. two scenarios:

return to ql
struggle with getting data on and off
realise headers are a problem for exec's
try to do some thing useful but find your Toolkit 1 MDV is faulty...
realise ZIP will not fit on 128K machine
think several days and nothing yet working is a waste.

not the user experience that will keep many people interested in moving forward.

or

Return to QL
Read about rPI interface, download and use old mono cable you have lying around but get some programs running quickly even if that is using a serial port on the rPI as the NET interface needs some hardware.
Realise you need Toolikt (use the RAM version for moment) loaded from the rPI
Want to try PTR environment (need RTC for that applet to be useful, need a mouse for it to be pretty)
Need TKII in ROM for advanced QL net stuff.
Order reasonable price new shiny toy (cartridge with TKII, RTC and code needed to get a mouse running) - feel good

I think with a good easily locatable README1ST.PDF the second approach would get people back into it faster...


User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: Fun things to do with an MC68EC020....

Post by Peter »

Probably wrong thread for rPI interface and returning to QL - at least Dave disliked side remarks concerning Q68 ;)
But as short feedback: I personally find a dependency on rPI not encouraging for an average person returning to QL.


Timbucus
ROM Dongle
Posts: 49
Joined: Sat Apr 01, 2017 12:14 am

Re: Fun things to do with an MC68EC020....

Post by Timbucus »

Sorry yes - I will start a new thread... was meant to support the idea of a device on the cartridge port! For both old and new users... RPI totally optional...


User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Fun things to do with an MC68EC020....

Post by Dave »

I already started a thread for these more speculative ideas.

It's not my job to police the forums, but I do like threads to stay on topic. Often people post good info on the wrong thread and it makes it so much harder to find and refer to later.

For on topicness - Nasta has been even busier than usual lately so my communication back and forth with him has slowed. I'm trying to work out a lit of parts I need to be buying to do some more advanced prototyping and we're picking a CPLD family and programming hardware. I'm in a holding pattern until he has some free time to reply. I know he's incredibly busy, so this may take a while.

One of the discussions that's ongoing right now is, is it better to use a single larger CPLD for $9 or so, or two smaller CPLDs for $2.50 each? The two would have more IO pins and could have a few pins for a private bus between themselves. The idea would be to have one just do address decoding/bus width and the other handle clock/buffer/etc. Comments welcome :D


Post Reply