Fun things to do with an MC68EC020....

Nagging hardware related question? Post here!
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 »

The only point I could see for SATA on a system like this would be CDROM access.
If it had to be implemented, it would probably be via IDE-SATA interface.

On the other hand, even low-end SDHC cards can hold several ISO images.


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 »

SATA on QL is easy. It's done, two times over independently using the same method and invisibly to the QL. It's just a QubIDE with an extra couple of parts. It would be nice to support SATA because of the huge range of small devices available. SDXC cards are convenient, too. I have seen tests of SDHC cards that often fail at 4000-6000 overwrites, but those are always off-brand devices - stick with the name brands and everything should be fine. Samsung cards are guaranteed for 10,000 writes or more. But SATA devices have sector wear leveling algorithms and are much, much more durable. Since we're looking at machines that have 33+ year lives already... I think we need to use a storage system that can carry us through the next 33. Having SATA and SDXC also opens up a whole bunch of embedded applications. There's no end of people who might want a little embedded machine based around their favorite architecture of the 80s.

Ethernet is more tricky. Nice to see 1MB/sec may be possible. However, I don't see it being used for large sustained transfers as even a huge file on the QL is less than a MB ;) My experience on the QL using a wiznet on the QL's serial ports is that it's limited to 38,400 baud, but for practical purposes that's 4K/sec. It takes about 40 seconds to suck down a 48K image real world. The same wiznet on a faster serial port running at 230400 baud sucks down the same file in about 2 seconds. Web surfing is usable at 230400. But then, everyone finds their own use. Some discipline is required, but it's a really useful feature - especially between two QLs. It does nicely solve the ZIP problem ;) It does require some programming discipline - just a matter of opening and closing the needed connections promptly so they do not time out.


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 »

Peter wrote:The only point I could see for SATA on a system like this would be CDROM access.
If it had to be implemented, it would probably be via IDE-SATA interface.
This is the idea exactly. But the right bridge chip has to be chosen, some do not support CD ROMs.
On the other hand, all of them support hard drives (and SSD of course), so this is a possibility even if a vastly over-capacity one :)

Regarding transfer speeds, if the protocol is simple )or helped out by some hardware), about 1.8M/sec is the absolute maximum and SGC gets close to this. But it could go faster if the bus is well behaved. Then, on the other hand, if you can get 24 more lines to behave exactly as good (or bad), you get 4x the data rate essentially free since it takes exactly the same amount of time to transfer 1, 2 or 4 bytes.
Even on the Qubide I was thinking of ways to speed things up so the data port is aliased to 2 long words so at least 8 consecutive bytes can be transferred without cycles wasted for instruction reads. On the 020 one can approach an uninterrupted byte stream of whatever buffer size is set up (default is 1 sector, 512 bytes), which si why SGC gets close to the theoretical limit. This is good enough for a lot of peripherals. Only stuff that requires a lot of data in bulk requires more, one example is copying screen areas around under the PE, or scrolling a large window in a 'lots of colors' screen mode. Loading and saving files is usually not that much of a problem (not that speed does not provide a benefit) because it happens fairly rarely and QL files are tiny by modern standards.


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 »

Was the "about 1.8M/sec" absolute maximum figure including or excluding higher OS levels?

Is this actually reading a file to RAM?

If the SGC could actually read a file under SMSQ/E at that speed - regardless how well implemneted the hardware interface is - I would be surprised.


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 »

Peter wrote:Was the "about 1.8M/sec" absolute maximum figure including or excluding higher OS levels?

Is this actually reading a file to RAM?

If the SGC could actually read a file under SMSQ/E at that speed - regardless how well implemneted the hardware interface is - I would be surprised.
The theoretical maximum would be sequential 4-cycle (at 7.5MHz clock) byte transfers, which gives you the TOTAL BANDWIDTH of the bus, 7.5M/4 bytes a second = 1.875Mbytes/second. This is not transfer speed, as for a transfer something has to be read over the bus from one place and subsequently written over the bus to a different place. Since there is no DMA, both sides of the transfer have to be done by the CPU sequentially, the theoretical maximum transfer speed is half of the bandwidth, ~937k bytes/sec, not even 1M, assuming the instructions required for the transfer are an insignificant overhead (which takes some doing).

The SGC manages almost the theoretical rate on memory fills because it can do the required instructions and looping in parallel with the write (or read), or in any case executes them from RAM that has a 24x higher bandwidth and/or cache that is double that. Also, for things like file transfers, one end of the read-write pair is in RAM, so only one side is limited by the slow QL bus. It gets over the old QL's theoretical bandwidth on LBYTES/SBYTES (for large files and blocks). The SGC side (one side of the transfer plus code) is so much faster than the QL side that compared to the byte transfer over the QL's bus, they almost disappear.

But then, on the other hand, you can get worst case scenarios. Consider Aurora scrolling a window defined to the full resolution, say 512x480 in 256 colors. This is around 240k of RAM. Even doing this the most clever way, the whole screen less one line has to be read and written back at a theoretical maximum of 1.875Mbytes/sec (in reality slightly less). In other words, the screen can scroll barely under 4 times a second - rather abysmal.
Shadowing this in 32-bit RAM would speed this up by a factor of almost 2, to around 7.5 times a second.
Running Aurora at maximum speed would give you an additional factor of just over 2, to around 16 times a second
A 32-bit Aurora would speed this up additionally by a factor of 4, to around 64 times a second.
If you are editing text, think that many lines a second.


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 »

So do I understand correctly, that your peripheral (e.g. IDE or SDHC) speed calculations are excluding higher OS levels?


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 »

Peter wrote:So do I understand correctly, that your peripheral (e.g. IDE or SDHC) speed calculations are excluding higher OS levels?
Yes. LBYTES/SBYTES is close to raw read/write.


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 »

I would have expected that, too. Measurement tells otherwise, at least under SMSQ/E. Yet to be investigated. But it was to a degree that made low-level optimization relatively pointless. Just saying, because for the 68EC020, optimizing the mass storage interface might not be where you want to spend development time.


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 »

So, the CPU (68EC020) and RAM (huge modern SRAMs) have been selected. The memory map is almost finalized, which means we're almost ready to do the work on the fancy address decoder/memory controller.

I'm going to be taking a break for a healing trip to the mountains for a week or so. I don't know what the internet access will be like there, but I know the air will be clear and I'll be able to get some sun and maybe move around a little and get some light exercise.

When I get back, I'll be ordering components and working on the PCB design. A lot of it is automatic, and the fiddly bits will come together in time.

See you guys when I get back!


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 »

Sounds good :) Wish you a good time of recovery and healing!


Post Reply