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 »

This thread is for 68EC020 possibilities.

If you'd like to start a separate SMSQ customization or Q68 thread, that would be great. SMSQ as it relates to a 68EC020 is fine though.


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 »

mk79 wrote:1024x512 is okay in terms of resolution, but more on the minimal side.
I'm using 640x480 on a 1280x960 window with scaling factor of 2. Just enlarging the resolution without adjusting the character size will get you characters that are too small to read comfortably (at least at my age ;) ). Of course you can increase the CSIZE but most software uses the default 0,0.
(well, now while I'm thinking of it, anti-aliasing fonts would be a nice feature :D ).

Jan.


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 »

You have shared a bunch of interesting ideas and commentary. Between you, you've all given me some clear ideas about direction.

The thing I am thinking about now is the thru-connector. We know we'd need to include a basic QL connector, but we'd also like to make the extra address and data lines available somewhere too. I'm sure there are people who would have use for that. Nasta's suggestion was have the basic DIN41612 through-connector, and have a larger connector with the extra 24 data and 4 address pins. I see the merits of that. I could also see having those just be the QL standard ports but have a small header nearby for those extra signals. I'm not sure how sound that is from a signal integrity viewpoint, though. Another way to go is to just have a proper backplane on the thing, but that can get involved and forces the PCB to be a certain size.

So, a bit of a muddle in my thinking there. I want to provide the most utility for the least design and production cost.

Would it help you folks if I draw up some example pics and post them? Or if I show you 3D renders or even a 3D print of the expansion port cover I have been thinking about?


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

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

Post by tofro »

Dave,

I have absolutely no clue why anyone would want to have the extended data and address bus in full. Routing the 16+24 tracks around the board to another connector will give you a major headache and not add much value.

Towards the QL, it obviously makes no sense - QL peripherals won't be able to handle the extra bits.

If you want to make the memory expandable, add some connectors to accept a piggy-pack RAM/ROM board on top of the expansion. You won't need all address lines - Just the data lines and some chip selects and some lower address line. For 2M expansion, you're fine with 11 address lines, 16 data lines and a CS. The CS would be decoded on your on-board CPLD. The only restriction you would be introducing is limiting the selection of memory chips possible.

Any external peripherals someone would think to add would neither need 16 data lines nor the full address bus width as well. Sub-divide the address range into e.g. 16KB ranges like the QL did and provide a bank select signal and the lower address lines. That's enough for any QL-style extension.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
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 »

We're just looking at doing a 12MB on-board RAM so there's no need for any kind of RAM expansion. The catch is that people will want to still use expanded storage like CF or IDE, and might like a floppy interface. There are a number of possibilities for interfaces where they could benefit from 16- or 32-bit transfers. A SATA interface based off the QubIDE would benefit from the increased bandwidth, for example. A future ethernet expansion would certainly be bottlenecked by an 8-bit data bus.

If I don't provide some kind of extended access the door is permanently closed. It's not even an option.


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 »

Since the thing is SRAM based, memory expansion requires the full address and data line set. This is not going to be on the expansion connector, nor should it, the signal speeds there are far too critical and fast, This remains local to the CPU and is not seen on outside buses. If it is expandable, there is a piggyback board with it's own connectors.
Expansion buses MUST be buffered, not only for signal strength but integrity and RFI. Signals toggle on the external bus only when it is accessed.
With regards to those, we still need some simpler way of expansion using an 8-bit bus and a means to use (at least in the beginning) existing QL peripherals. So a suitable subset of the J1 signals should be provided anyway. Regarding address and data lines, you can't save anything as 16k + bank select for all 16k slots = full address lines. Based on the QL's architecture and existing peripherals, one could at best save one address line (in theory, A18..19 being 01 and 10 are not used as this would address an old QL RAM 512k RAM expansion, rather superfluous with existing 32-bit RAM of at least 8x the size).
On the other hand, there are peripherals that would benefit from a wide bus, and in fact some that really only make sense with a wide bus, the lattger notably being extended graphics. That being said, you do not need (nor do you have) the full addressing capability of the CPU, but you could manage up to 2M, because that's what's left in the address map assuming one day all QL style peripherals are phased out. And THAT being said, looking at the way the WMAN/PTRGEN work, even 1M of screen memory is pushing it, given 12M of RAM.
A simple protocol is possible that adds 24 more bits and 2 data transfer acknowledge lines to the third row of the connector, that would offer approximately 8-10x QL bus transfer speed, still remaining conservative on signal speeds - most of the transfer rate improvement comes from the 4x wider bus. This is not that important for file devices as QL files are miniscule by today's standards, but for any usable graphics it's an absolute necessity.

So, to summarise:
If you think of this board as a standard card with a connector on each end, you end up with a standard 2-row expansion connector on the right side - this plugs into an existing 'QL motherboard', even one 'cut down' with 2 DRAM chips, 8301, 8302, IPC and a few MSI chips to emulate the old QL. You could just as well put that into the original case. One could also use an Aurora here - still fit the whole thing inside the old case. In the future, this 'right hand expansion' would hold the basics, like keyboard, RTC, mouse, some basic storage device, some sort of serial and parallel port. In any case the basics of a 'motherboard', which are usually not extremely fast devices but are then easily connected through an 8-bit bus (which BTW may also get a new 'fast' mode).
The full connector, with an extra row, would be on the left side, where a regular through connector would be. In the beginning, one could sue regular QL peripherals here, just like before. One could also connect a QL style, or even better, and expanded backplane with 3-row connectors. Or - a card that combines new video and a faster mass storage device, perhaps hot plug/swap capable, like an SD card or a SATA port. So, that when 3 boards would be combined, it could STILL fit inside the old case :) and if you want something more compact, you can use a backplane of some sort.

It should be noted that the CPU automatic bus sizing mechanism enables this approach to work just like the old QL bus - any part of the 2M address map dedicated to expansion can hold a 32-bit peripheral because the CPU expects the peripheral to tell it how wide it is when it ends the access (at which point the CPU sets itself up to execute additional accesses if the bus was narrower than 32 bits which it assumes at the start). Thus a 32-bit peripheral can be made that over-rides or shadows an existing 8-bit one, using all the same lines for all the same purpose as before, if one wanted it.


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 »

Those are my instincts too, Nasta.

Some kind of expansion is essential. There's a cost to adding the wider bus, but there's a different and much more permanent cost to omitting it. The extra 24 data lines are useful in their entirety. It's not so important to have any additional address lines available if we maintain the original scheme for expansion cards. However, restricting the cards to such a small amount of address space might be limiting in future. Even the largest QL systems only have three or four expansion cards fitted. I'm unaware of any with 5 or more, though I'd love to see a photo essay and description of any larger systems.

I'm only looking at this CPU/RAM card right now, though I am doing some side experimenting with ethernet. To me, this is a much easier undertaking because the focus is specific and the scope is limited. The idea of doing the combo card that might plug into this and bring fast serial, SATA, SDHC, ethernet, etc is quite scary and complex by comparison as it has much more complex design requirements. If there were a way that such a card could be designed to accommodate an 8-bit or 32-bit system and be optimal for both....

Anyway, I found large SRAMS, but I am still on the hunt for larger flash ICs. I find ones that fit the bill in every way except voltage. A part of me wants to halve the flash so it's just two deep and one wide, and move it in memory so there's 1MB of flash and only one alias of the original QL map, and then increasing RAM to 14MB. I'd even be happy to just then have that flash be organized as 16 bit native, so two ICs deep by 1 IC wide, them mirror those contents into faster 32-bit RAM. It's a bit less than ideal but it gives a slightly leaner system. At that point though, any changes are only very marginal gains or losses, so obscure design considerations of compatibility to an existing QL play a larger role.


Derek_Stewart
Font of All Knowledge
Posts: 3929
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

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

Post by Derek_Stewart »

Dave wrote:Would it help you folks if I draw up some example pics and post them? Or if I show you 3D renders or even a 3D print of the expansion port cover I have been thinking about?
Hi Dave,

I have been drawing up in Sketchpad a replacement Trump Card Cover, which I will send to a £D Printing Company for printing.

This could do the same for QL expansion covers based on other QL expansions, i.e. Sandy Mouse I/F, PCML interface.

Can you make your board dimensional to be enclosed within the QL case?


Regards,

Derek
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 »

Dave wrote: A future ethernet expansion would certainly be bottlenecked by an 8-bit data bus.
With a MC68EC020 and a QL OS, it would be surprising if you could handle 1 MB/s of data stream with the usual OS calls.
My experience is, that you need a decent 68030/040 system to make use of more than 1 MB/s for file transfer, which would be a typical ethernet application.
You can easily do 1 MB/s with 8-bit data bus.
tofro wrote:Any external peripherals someone would think to add would neither need 16 data lines nor the full address bus width as well. Sub-divide the address range into e.g. 16KB ranges like the QL did and provide a bank select signal and the lower address lines. That's enough for any QL-style extension.
The 16 KB were only needed for drivers. Those could be placed into the main Flash of Dave's system. For the peripheral itself, it's usually about a handful of address lines.

The Q68 has a minimalistic 8-bit data extension bus with only 9-bit address and a few control signals, in space saving 2mm pitch.
If (partial) compatibility is of interest, we could discuss that.


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

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

Post by tofro »

I cannot think of (m)any extensions suitable for a QL replacement that would require 16-bit transfers (IDE/ATA maybe, but that's a dying technology and takes a lot of PCB real estate for data lines and connectors - IMHO SDHC is a better way to go). Even Motorola's own I/O chip line (like 68901 MPC) only had an 8-bit data bus.

And implementing SATA on a QL compatible is, honestly, speaking, a bit on the ambitious side IMHO.

But your call, Dave.

Regards,
Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Post Reply