Just watch out that TI have stopped making 74XXX646 type devices in DIP
packages https://groups.google.com/forum/?hl=en#!topic/n8vem/rKgo1uuiakw .
of edge triggered registers ('646 '374). There is a fall through version of
find.
combination of standard buffers like '244s and '373 latches. For a Z80 16
enabled). If you want to do a 16 bit read from IDE the low byte goes
read on the following Z80 bus read cycle. You just have to work out how to
control the LEs and OEs on the '373s. It may be easier to use a '245 on the
through other IO addresses that enable the '373s as required.
Cheers, Ian.
Post by John MonahanDonât know how I missed that one Dave. Excellent, dirt simple too.
Will look into it for sure
Thanks
John
*Sent:* Thursday, October 1, 2015 7:31 PM
*To:* N8VEM-S100
*Subject:* Re: [N8VEM-S100:7707] SD Card Questions
Hi John,
You should take a look at the board that John Coffman designed for the ECB
bus - it uses a couple of 646 latches and is very fast and reliable - much
more reliable and less sensitive to timing that the 8255 has.
See
http://n8vem-sbc.pbworks.com/w/browse/#view=ViewFolder¶m=ECB%20Dual%20IDE%20--%20with%20FDC
for details and yes 16 bit transfers can be very fast - being done on
another board. No need to reinvent the wheel when John C has a working
design - it should transport to S100 bus fairly easy - and the software
becomes actually much simpler without the 8255 in the way.
Dave
Thanks Tom, So it looks like SD cards (in any form) are slower than CDF
cards. Did not really appreciate that and is good to know. Thanks.
On the CF card interface, Iâm missing how a PIC32 (or any microprocessor)
as a bridge on the S100 bus would in fact be faster that âstraightâ 74Fxx
style buffers/latches to get 8 or 16 bit data in and out of the CF card
registers. Currently Iâm thinking of multiple 74F374 style latches
interfacing directly to the CF card data lines and on to the S100 bus. In
essence it would be emulating the 8255 in 74Fxx TTL fast logic. Even at
that, Iâm wondering if all of this could in fact save me a wait state.
The only way I can see a microprocessor being faster in between the â two
bussesâ would be that it internally buffers multiple sectors and later
writes them to the CF card. Reads I cannot see an advantage unless we do
track reads assuming a decent number of sequential sector reads. The one
lesson I learned way back with that Propeller Console IO board is that the
S100 bus generated pDBIN and pWR* signals are in fact very short. Too short
for another microprocessor to do anything useful and definitely too fast
for a high level language.
John
Behalf Of *Tom Lafleur
*Sent:* Thursday, October 1, 2015 10:30 AM
*Subject:* Re: [N8VEM-S100:7707] SD Card Questions
Maybe if you re-do that board, you do a dual CF/SD card board...
Instead of an Z80, use a PIC32... VERY FAST, SD driver available in C,
should be-able to find CF drivers...
Inherent timing is available on the chip.. less, board space than Z80..
simple to program...
I Agree Tom,
I would like as far as possible to keep the hardware transparent to the
software. I think even the 82C55 is the bottleneck. Iâm wondering if I
should put in a fast (10MhZ) Z80/ROM/ROM chip set and buffer data to/from
the CF cards or as Dave suggests do a 74Fxx/GAL hardware equivalent of the
82C55. Any suggestions for a really fast onboard CPU that has RAM/ROM and
the capability of having 3 I/O ports in a circuit.
John
Behalf Of *Tom Lafleur
*Sent:* Thursday, October 1, 2015 9:21 AM
*Subject:* Re: [N8VEM-S100:7705] SD Card Questions
One of the issue I have is that we have a number of 8080/z80/cpm/mpm
projects on many different platform, all use a mix of SD (most of them) and
CF cards..
John's CF board
Josh 8080 board SD card
Grants cyclone IV board SD Card
Waynes Zeta Board SD Card
Others...
It would be nice if we has a standard so that a card on one would work on
another system.. at lease at file interchange level, not necessary boot
level
also, john's current CF board is NOT tolerant of many well known brands of CF cards...
If a new design is done, it should allow use of most any CF cards, or what
John is proposing, moving on to a more common SD card....
thanks
Hi Alex,
then I think my second point becomes the relevant point.
Would it be possible to develop a discrete logic replacement circuit to
achieve higher performance and allow continued use of CF media and the
current CF media
imaging process with cpmtools.
regards
David
David,
I assume that John is thinking that the bottleneck is the Intel PPI
(8255A) interface chip, and not the media. The maximum throughput for this
chip is far lower than the theoretical maximums for even basic SD/MMC cards.
- Alex
On Thu, Oct 1, 2015 at 11:05 AM, 'David Fry' via N8VEM-S100 <
John,
Before you develop another flash memory card have you tried using any of
the higher end x266 or better CF cards that are designed for SLR
photography to see if performance picks up.
Iâve looked at the Kingston website for the basic (White Lilly) 4GB cards
and they donât specify a speed which makes me suspect that they are slow
cards,
Whereas the x266 CF card is specified at 40 â 45MB/Sec, and the x600 CF
card is specified at 90MB/Sec.
If it does turn out that the 8255 is the bottleneck would it not be worth
developing a discrete logic replacement to try and maintain broad
compatibility with the existing software (monitor)
Base and CF card imaging process (cpmtools)
Maybe others could comment on the differences between CF media and SD card
media in terms of disk layout etc...
Regards
David Fry
*Sent:* 01 October 2015 13:13
*Subject:* [N8VEM-S100:7701] SD Card Questions
Hi Josh,
I am toying with the idea of building a dual Micro SD card S100 board.
Iâm finding that the bottleneck in my 80386/80486 prototypes for MSDOS etc.
is the 8255A driven dual IDE/CF board. Did you get the SD card working
with CP/M on your 8080 board. Any idea how âfastâ it is relative to a CF
card for data access. Iâm worried the interface is in fact slower that an
8255A. Perhaps a large Flash RAM board would be a better approach. What do
you think.
John
------------------------------
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6140 / Virus Database: 4431/10735 - Release Date: 10/01/15
--
You received this message because you are subscribed to the Google Groups
"N8VEM-S100" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"N8VEM-S100" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"N8VEM-S100" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.
--
~~ _/) ~~~~ _/) ~~~~ _/) ~~~~ _/) ~~
Tom Lafleur
--
You received this message because you are subscribed to the Google Groups
"N8VEM-S100" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"N8VEM-S100" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.
--
~~ _/) ~~~~ _/) ~~~~ _/) ~~~~ _/) ~~
Tom Lafleur
--
You received this message because you are subscribed to the Google Groups
"N8VEM-S100" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"N8VEM-S100" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.