As per comments in the Fuzix thread, I had a go at coming up with a schematic for a 82c55 IDE adapter for the RC2014.
It's a clone of Philip's YAZ180 design with added '688 based address decoding (thanks to PianoMatt and various S100 designs. I looked at this one: https://www.retrobrewcomputers.org/lib/exe/fetch.php?media=boards:ecb:ramfloppy:printing_ecb-ramf-r11.sch.pdf), and a 40pin IDE connector.
One thing I'm not sure about is the IDE INTRQ signal. Attaching this directly to the Z80s interrupt line seems like a bad idea if we want to be able to use the Z80 in interrupt mode 2, which is ideally what you'd want to do when using the Z80 peripheral chips, the CTC, SIO etc.
I'm wondering if attaching it is necessary?
All comments welcome! I knocked it up quickly so will definitely be some errors...
Looking forward to getting a RC2014 IDE interface soon. ;-).
I've gone for both a 40 pin and 44 pin connector so everyone should be happy. The 40 pin is a right angle on on the edge so you could use it with a CF adapter.
Re the pin assignment, I went with Philip's variation (see the Fuzix thread for details) so you would have to swap a couple of the RomWBW defines around... Now thinking that maybe should just go with the same as the other RetroBrew interfaces though.
At the moment just going for an IDE interface, so have reverted to the RetroBrew pinout. Figure if need one for general purpose use can spin another PCB.
The IDE interface is created by another PPIDE mini-board adapter attached in between the 82C55 and the IDE drive, and it carries the inverters necessary to drive the IDE bus. Since the PPIDE mini-board is a special purpose interface they don't care about Mode 1 applications (keyboard scanning, CRT, parallel printing), or Mode 2 applications (Floppy Controller).
The current RetroBrew PPIDE mini board uses exactly the same pin-out solution as Paul Stoffregen, and Peter Faasse before him, leaving PC0, PC1, and PC2 for the IDE address pins (non-inverted).
Are the other modes of operation that the 82C55 is capable of useful in the context of an IDE interface?
Cloning the DiskIO board makes sense to me, because it makes it easier to implement RomWBW on the RC. It'd be great to see the RC become officially supported by RomWBW, and adding the standard IDE interface to the RC arsenal could bring us one step closer.
PianoMatt
Will add some jumpers to swap those round and send it off to get a PCB made. Hopefully I've not missed anything else, although wary as I've not prototyped this!
Will be interesting to see what kind of performance you get vs bit banging the compactflash card in 8 bit mode. I expect it's not going to make any difference at all.
What speed do you run the Z180 on your YAZ180? I was looking at an S100 82c55 design, and they'd added some logic to latch signals to enable it to work on buses > 8Mhz.
Will be interesting to see what kind of performance you get vs bit banging the compact flash card in 8 bit mode. I expect it's not going to make any difference at all.
That's faster than I imagined.
So regarding the z88dk stuff, there's the 82c55 driver then diskio layered over that as an abstraction and c interface, then FatFS on top of that?
And you could theoretically build this into a CP/M program? (the COM file would have to reside on a normal CP/M formatted drive, but you could load data in-program from a FAT partition on a different drive?)
Will be interesting to see what kind of performance you get vs bit banging the compact flash card in 8 bit mode. I expect it's not going to make any difference at all.Well the question is intriguing enough to make it worth a bit of an investigation. So, I took my `diskio.c` test program, put in some timing captures and increased the sector count to 32 (512 byte) sector writes and reads. And the results are in.Kingspec-SSD KSD-PA18.6-XXXMS 16kB W/R in 14 /256th of a second or 292kB/s.that seems like quite fast... so lets try an old IBM drive.IBM-Travelstar DBCA-206480 16kB W/R in 15-21 /256th of a second or 195kB/s to 273kB/s
And you could theoretically build this into a CP/M program? (the COM file would have to reside on a normal CP/M formatted drive, but you could load data in-program from a FAT partition on a different drive?)Yes. Absolutely.Actually I have a cunning plan, and that is to build a "modern" CP/M2.2 platform with FAT32 disks, and memory banking similar to ZDOS, potentially looking quite a bit like (if not the same as) FUZIX, that can run CP/M applications without all the mucking about with inefficient file types and other limitations from the 1980s. Admittedly, one should produce running code before one mouths off about stuff. But, it is a medium - long term outcome focus for me.
Have you looked at an app called "RUNCPM"? I believe RUNCPM does this by replacing the BDOS and BIOS layers in CPM, while running the stock CCP layer. Seems to me the same think could be done on the Z80 to access media formatted in FATxx fashion.
That's faster than I imagined.Yes, it is faster than I imagined too. By 10x what PJRC mentioned on his web site. The performance is purely driven by the number of reads and writes to the 82C55, so I used the Z80 ini and outi to great benefit, allowing me to run the interface more efficiently than PJRC was doing with his 8051 code. And, I've specifically written only byte and sector transfer routines, and tried to optimise for that. PJRC went about it a bit differently.
Will be interesting to see what kind of performance you get vs bit banging the compact flash card in 8 bit mode. I expect it's not going to make any difference at all.Well the question is intriguing enough to make it worth a bit of an investigation. So, I took my `diskio.c` test program, put in some timing captures and increased the sector count to 32 (512 byte) sector writes and reads. And the results are in.
Kingspec-SSD KSD-PA18.6-XXXMS 16kB W/R in 14 /256th of a second or about 292kB/s.
I'll try some C interface (FatFs) speed testing, of file copies, etc, to see how much performance is lost between C wrapped asm diskIO functions, and the FatFs calls.
total_bytes = 0;
for (;;)
{
res = f_read(&FileIn, buffer, sizeof(buffer), &br);
if (res || br == 0) break; /* error or eof */
res = f_write(&FileOut, buffer, br, &bw);
total_bytes += bw;
if (res || bw < br) break; /* error or disk full */
}
I'm wondering about "The 82C55 needs "tWA" (Address Stable after /WR) to be 20ns. This means the /CS must be generated from just the address lines in Z180 world.Don't incorporate the /IORQ line in the /CS calculation, or the /CS will be tied to the /WR (/IORQ) timing, rather than to the address validity timing."
It seems to work OK using /IORQ as the CS for the 82c55, and I see the DiskIO V3 design also uses it too... https://www.retrobrewcomputers.org/lib/exe/fetch.php?media=boards:ecb:diskio-v3:ecb_diskio_v3_-_schematics_-_color_1.0.pdf
Any thoughts? As it works I'm inclined to leave it...
Looking at the datasheet, aren't those values the minimum required rather than an absolute requirement?
As in the chip won't function if the timing are shorter than 20ns?
Many thanks for your assistance so far, I have it working on breadboard in RomWBW. (It's taken all day... using a PLCC44 to DIP40 adapter contributed to the confusion)
Cheers,
Ed
So the net FatFS read or write rate is about 230kB/s, so we lose about 60kB/s to the C wrapper and file system management for this simple task.
I was testing with the Z80, but as you asked I thought I better try with the Z180 too.
Seems to work OK using IORQ even with the bus at 20Mhz!
I had to build RomWBW with Z180 options, which I'm guessing sets some I/O wait states.
On the basis of this experiment, I think I'm going to go with just using IORQ as the CS in spite of it breaching the timing :D If I had a spare inverter would probably go for it, but I don't. If it works ok at 20Mhz on my rats nest of wires, should be hopefully OK on PCB...
See attached image for comparison of !MRQ and IORQ, Using !MRQ in yellow, as CS would mean it becomes active when not needed, which I guess might cause other issues.
I've created a pull-request for adding z88dk 8255 device support, IDE interface drivers, and diskio drivers, with relevant include files, for the rc2014.Once someone defines the preferred base address for this board, then the software at this level is ready. Spencer?
So the net FatFS read or write rate is about 230kB/s, so we lose about 60kB/s to the C wrapper and file system management for this simple task.
bwt = 0;
for (;;) {
res = f_read(&FileIn, buffer, sizeof(buffer), &br);
if (res || br == 0) break; // error or eof
res = f_write(&FileOut, buffer, br, &bw);
bwt += bw;
if (res || bw < br) break; // error or disk full
}
Can't say the same thing for FatFs. My deconstruction of ChaN's code for a new library for z88dk has completely broken it. It might just be better to use the library ffconf.h file to determine which functions you need included, and which not, and use the original ff.c to compile it. That's what I did for the testing above. I'll be thinking on what to do for a day or two...
PPIDEENABLE .EQU TRUE
PPIDEMODE .EQU PPIDEMODE_DIO3
PPIDETRACE .EQU 1
PPIDE8BIT .EQU FALSE
I'm slightly disappointed that it worked first time. I've lost out on hours of valuable troubleshooting. I didn't even need my meter let alone my scope!
--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+unsubscribe@googlegroups.com.
To post to this group, send email to rc201...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/d204cfeb-8a09-44e2-9f99-214aa6fd0f3b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Unfortunately this is becoming an intrinsic part of the RC2014 ecosystem.There seem to be many many people getting their RC2014 and assembling it without going through the troubleshooting experience :-( Some RC2014 users don't use a multimeter, let alone a scope.It's a sad sad day when people can buy a board, put it together and enjoy its goodness without need of a few probes. When I were lad, we went down the Python Yorkshiremen Sketch route, crafting packets by hand at 300 baud 24/7. But, tell that to the youngens today and will they believe you? Will'es by eck!:-DSpencer
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/87f69867-dc01-442f-bb46-912a67b40eea%40googlegroups.com.
Got my PCBs back and they work, which is a relief!
See attached picture :) I've not got the connectors for the 2.5" drive yet, could only find them on eBay from China, so may be a while.
Re I/O port, I've been running mine at 0x20, but that was a fairly arbitrary pick (what I was previously running my CF adapter at)
cd ~/libsrc/_DEVELOPMENT
make job-rc2014
On Friday, 29 September 2017 13:50:45 UTC+1, PianoMatt wrote:The base address could be defined at compile time couldn't it? Would make more sense since there are so many different systems that could use this implementation.
--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+unsubscribe@googlegroups.com.
To post to this group, send email to rc201...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/4c251d39-5f15-431d-9161-0578bcde9bb4%40googlegroups.com.
Time for another update on the FatFS progress.
The new net FatFS read or write rate is just under 300kB/s, which is barely different to the underlying assembly code for diskio.
ls
a CP/M image, copy a file (in this case bbcbasic.com
).> fsed.cpm -f yaz180-16MB a.cpm > cpmls -f yaz180-16MB a.cpm > cpmcp -f yaz180-16MB a.cpm ~/Desktop/CPM/bbcbasic.com 0:BBCBASIC.COM
The contents of the /etc/cpmtools/diskdefs
file need to be updated to include the specific to the file format calculations I've used.
diskdef yaz180-32MB
seclen 512
tracks 2048
sectrk 32
blocksize 4096
maxdir 512
skew 0
boottrk -
os 2.2
end
diskdef yaz180-16MB
seclen 512
tracks 1024
sectrk 32
blocksize 4096
maxdir 512
skew 0
boottrk -
os 2.2
end
diskdef yaz180-8MB
seclen 512
tracks 512
sectrk 32
blocksize 4096
maxdir 512
skew 0
boottrk -
os 2.2
end
Time for another update on the FatFS progress.It has been a few months since I've written on this topic. I've been busy working on details, and Christmas / New Year caused a bit of down time too.The new net FatFS read or write rate is just under 300kB/s, which is barely different to the underlying assembly code for diskio.Anyway, I thought that it might be a good time to put a few notes together about my experience of getting CP/M to run off an IDE drive, which is formatted with FAT32 file system.The TL;DR of this story is that it is possible (even easy) to use an IDE drive with FAT32 formatting together with CP/M, and that in doing this the cpmtools can be used to write com files directly from a Linux (and other) PC directly to the CP/M drive image file, and therefore make special disk "loading" tools unnecessary.As background, most (all) of the implementations of CP/M on IDE that I've seen take shortcuts with the decoding of the IDE Logical Block Address, which means that the CP/M drive is composed of non-contiguous sector data on the drive. Often either only 8 bits of the 16 bit IDE interface is used, or the CP/M sector, track and disk characteristics are laid out so that the data is spread across various sectors in the drive, making it impossible to read the data as a normal FAT32 drive.The main result I've achieved is writing a LBA translation routine that can take a specific CP/M format, and convert it to contiguous sectors on the IDE drive, which is within the bounds of a FAT32 file. This makes it possible for the cpmtools to read and write data directly when the drive is installed on a host PC system.
How does it work?Well IMHO, it works well. CP/M COM files can be stored directly from a PC, and can be read and written from the CP/M system. And, it is fast.That's all that matters. Getting files on the CP/M system is as simple as copying them on the host PC. The reverse is also true.I haven't pushed this to RC2014 yet. But, it won't be hard to do so, and use Ed's 8255 IDE interface to drive this.The usage works like this. To check the disk image on the host platform,ls
a CP/M image, copy a file (in this casebbcbasic.com
).
> fsed.cpm -f yaz180-16MB a.cpm > cpmls -f yaz180-16MB a.cpm > cpmcp -f yaz180-16MB a.cpm ~/Desktop/CPM/bbcbasic.com 0:BBCBASIC.COM
A few questions:Would it be theoretically possible to integrate this with the RomWBW BIOS?
Does it handle the file on the FAT32 file system potentially being fragmented?