Topics

Todd's ELF-ish to get an FDC #Homebrew #microboards

taf123
 

Back in July, in the crazy topic "Okay, let's get really crazy...", https://groups.io/g/cosmacelf/topic/32570650, there was a discussion about the RCA CDP18S651 Microboard Floppy-Disk Controller.  This got me interested in a the idea of building a clone of that card for my ELF-ish project.  However, as was pointed out then, a large number of the components are dedicated to the data separator, which also required some rather critical adjustments, and there are dedicated chips to do this sort of thing.

Initially, I looked at the FDC9229BT which does the data separator and write precomp function and directly supports the FDC765.  But then I found the FDC9266 , which is basically both of these combined. And conveniently for me, a UK based eBay source.

This radically reduced the component count, removed the critical adjustments, and brought the project into the scope of something reasonable to build.

Another aspect of the CDP18S651was the support for the various floppy interfaces of the time.  But in the post-PC world, the interface is now fairly standardized unless you want to go for some rather vintage drives.  So I decided to cut out all of the unrequired drive interface support stuff.  The simplified drive interface is based upon the example FDC design on page 24 of the 1979 application note on the uDP765, which I found as uPD765_App_Note_Mar79.pdf on bitsavers. There is support for up to four drives using two PC-style 34-pin IDC interfaces.

I replaced the single motor-on flip-flop with a 74HC175 Quad D-Type Flip-Flop to give separate motor-on control for each drive.  Although I added a jumper to allow both drive 0 and 1 to be controlled by the same motor-on bit to be compatible to the original.

I also dropped the full-support of the RCA two-level I/O system and just hard-wired Group-8 (or IO4 in my ELF-ish world).  I used the now spare 1/2 4013 flip-flop to latch the state of BUS3 during an OUT 1.

I also allowed a jumper option to connect to the IR7 level of the CDP1877 Programmable Interrupt Controller back on the CDP-IO chassis.

I also like the idea of being able to read the control latches, so I added a 74HC244 3-state Octal Buffer controlled by the previously unused INP 7.

And I use a DIL-8 8Mhz can oscillator rather than a crystal.

The complete schematic has been uploaded to https://groups.io/g/cosmacelf/files/Todd%27s%20ELF-ish%20Schematics as ELF-BB-FDC-II_20191124.pdf.  It's "-II" as it's my second attempt at a design, the first having been closer to the RCA original.

Here's the planned layout.



Now I just have to build it.  I'll keep the forum posted on how I get on.

I would appreciate reading any comments, thoughts, or suggestions on the design.

Share and enjoy,
Todd

ajparent1/kb1gmx
 

The 18series board was developed off the early NEC apnote.  I pounded on them (RCA back then) to
jump to the digital data separator that was much lower in parts count and NO adjustments. 
Same for the other suggestion (DMA selection).  I believe they eventually did but have no
documents to say.

Any who yes 9266 and later 37C65 series parts made the whole mess as small as one chip (37C65).

One thing the logic to determine DMA-in or DMA-out is simplified if you use the WRITE signal out
(pin25 FDC WE) of the FDC.  Then you need no logic hardware of software to control DMA direction. 
Also programming for FDC for PIO is nearly out of the range of what 1802 can do fast enough
unless clocked very fast.  The DMA interface is used for that and PIO only for command and status. 
FYI: the FDC running at DD high rate formats will want or spit a byte every 16uS during write or
read to media, the slowest format (SD 5.25) also being the least dense is 64us per byte.  Failure
to do that results in underrun/overrun as the FDC has minimal buffering and if that happens that sector is trashed.

Interrupt is not required. You can test EF-x or even poll the status register.

Programming hint.  To read only one sector without TC all that is needed is when writing
command string  is that the start sector is equal to end sector.  It will complete with end
of track(not really an error).

FYI the number of commands actually needed are less than 100%, some are really not that useful.
as a result its possible to create simpler software.

BTDT, have the full outfit on multiple CPUs.

Allison

taf123
 

Thanks for all of that Allison.  Definitely was planning on using the DMA mode.  Jumper select-able between EF-x polling and Interrupt use.

I like the idea of using the WE for DMA direction.  I'll go ahead and build it as-is (RCA) but could always retro-fit that change later. Ah, the joys of wire-wrap.

Best regards,
Todd

ajparent1/kb1gmx
 

DMA, you don't have a choice there. either that or a new design with a 8mhz 1806 minimum.

I did it that way, dma decided by WE (drive write commend). that and a few gates I
forget if I used 7400 or 7432 and an inverter.  The goal was fewer wires to get in
the wrong places.  I used the 37C65 as a I had a few back when.

taf123
 

I've assembled the FDC chassis and populated all of the sockets.




And it's all labelled on the back side




Now for the "quick" job of wiring all of this...

cmdrcosmac
 


Todd,
What operating system will you be running on this?
-Chuck

taf123
 

Hi Chuck -

One of the reasons for basing it on the RCA CDP18S651 is so I can use UT71 and RCA MircoDOS intended for the RCA MicroDisk Development System MS2000 - see RCA MPM-241.  I managed to find an original Disk for this and the associated BASIC on eBay.

I'll need to make an additional memory card to go with this as well since that system used a 2k ROM at 8000 with RAM filling the rest of the addressable space.  My ELF-ish currently only has 16K RAM and a 4k ROM at 8000.  This will require disabling the memory-mapped I/O devices I have in upper memory, but I included a jumper in the system to do allow this.

Cheers,
Todd

 

A suggestion for your new memory card, if I may?  I realize it's a radical departure from your current design strategy (grin)...

Happy Holidays...  Cheerful regards, Mike, K8LH


From: "taf123" <todd.ferguson@...>
To: cosmacelf@groups.io
Sent: Sunday, December 1, 2019 3:50:37 AM
Subject: Re: [cosmacelf] Todd's ELF-ish to get an FDC #Homebrew #microboards

Hi Chuck -

One of the reasons for basing it on the RCA CDP18S651 is so I can use UT71 and RCA MircoDOS intended for the RCA MicroDisk Development System MS2000 - see RCA MPM-241.  I managed to find an original Disk for this and the associated BASIC on eBay.

I'll need to make an additional memory card to go with this as well since that system used a 2k ROM at 8000 with RAM filling the rest of the addressable space.  My ELF-ish currently only has 16K RAM and a 4k ROM at 8000.  This will require disabling the memory-mapped I/O devices I have in upper memory, but I included a jumper in the system to do allow this.

Cheers,
Todd

cmdrcosmac
 


I second Mike's recommendation for the memory mapping scheme.
I am running it on my current SuperElf expander. I've got IDIOT in a 32k EEPROM,
mapped at F800-FBFF. All the rest is RAM, in an AS6C1008 RAM 128kx8
from Digikey 1450-1017-ND  $2.77. It's hooked up exactly as in Mike's drawing.
 This also makes possible an arrangement described by Tony Hill in Ipso Facto # 21.
This allows you to locate a Monitor anywhere in address space and optionally
jump to it after RESET, RUN. I did it on my Elf. RESET, GO runs at 0000.
RESET, MONITOR, GO runs at F800. I believe the tradition of placing monitors at 8000
began with RCA's reset,run-u/run-p scheme. They seem to have done it on most of their
COSMAC boxes. This was OK when RAM was in short supply, but now it's limiting.
 I've run Basic 3 under both UT62 and UT71. The serial I/O routines are at the
same addresses. The Basic I have came with UT62, from Herb's site. I believe he also
has UT71/MicroDos. I haven't found a Basic made for MicroDos. I'm looking forward
to seeing your system work. You'll be computing like it's 1984!
Best,
-Chuck

 

This 74HC688 method would work well for memory mapped I/O or memory mapped ROM but I'm not sure if it would be helpful if you needed both.


From: "cmdrcosmac" <cmdrcosmac@...>
To: cosmacelf@groups.io
Sent: Sunday, December 1, 2019 10:40:23 AM
Subject: Re: [cosmacelf] Todd's ELF-ish to get an FDC #Homebrew #microboards


I second Mike's recommendation for the memory mapping scheme.
I am running it on my current SuperElf expander. I've got IDIOT in a 32k EEPROM,
mapped at F800-FBFF. All the rest is RAM, in an AS6C1008 RAM 128kx8
from Digikey 1450-1017-ND  $2.77. It's hooked up exactly as in Mike's drawing.
 This also makes possible an arrangement described by Tony Hill in Ipso Facto # 21.
This allows you to locate a Monitor anywhere in address space and optionally
jump to it after RESET, RUN. I did it on my Elf. RESET, GO runs at 0000.
RESET, MONITOR, GO runs at F800. I believe the tradition of placing monitors at 8000
began with RCA's reset,run-u/run-p scheme. They seem to have done it on most of their
COSMAC boxes. This was OK when RAM was in short supply, but now it's limiting.
 I've run Basic 3 under both UT62 and UT71. The serial I/O routines are at the
same addresses. The Basic I have came with UT62, from Herb's site. I believe he also
has UT71/MicroDos. I haven't found a Basic made for MicroDos. I'm looking forward
to seeing your system work. You'll be computing like it's 1984!
Best,
-Chuck

cmdrcosmac
 


It's such a simple circuit. Use two of 'em!. One is set to the size and location
of the ROM. The other is set to reserve 256 bytes and addressed anywhere else
as needed. When placing the hardware, watch out for routines that scan for RAM
by writing and reading back. (As IDIOT does) Perhaps a control bit fed to the
688's enable pin, so the hardware cannot be accessed until software enables it.
 Then you run the /PQ outputs of the 688's thru a gate so either one will deselect
the RAM, and the one for the hardware can enable the chip selects of the hardware
devices, and the lowest address bits operate the register address bits of the devices.

 -Chuck

taf123
 

Thanks for all of the helpful feedback on the memory addition.

I'm getting tired of building low capacity memory cards.  Plus I'm running out of sprawl, so I was already thinking about moving forward a technology revs for this expansion.

I posted in an earlier thread about adding 16k RAM by using 8 * HM6167LP 16k x 1-bit chips.  I haven't built that card yet, but I'm thinking that would be a good way to fill out the lower 32k.

For the upper, I wasn't really sure the way to go, but this looks like such a good approach, I'm thinking about doing this with some bits I already have.  For the ROM, I'd go with the 28C256 (I have the AT28C256R).
For the RAM, I have a a couple HY62256ALP 32k x 8-bit.  I may instead use 2 of these and forget about all of the low capacity stuff I've already done for use with the FDC.

I like the 74HC688 method.  I have a signal that is generated back on the first expansion chassis if the memory-mapped I/O is enabled - this was to disable the ROM on the main chassis which isn't fully decoded.  This could be used to disable the upper RAM if the memory-mapped I/O has been jumper-enabled.

I'll work out the details and post the results.

Cheers,
Todd

taf123
 

The basic is RCA 1800 Basic 1 Compiler/Interpreter Manual; MicroDisk CDP18S834V4, supposedly NOS 1982.

I'll be picking up this and the MicroDOS disk, CDP18S845, over Christmas.  Hopefully they arrived intact, etc.

I'll post when I have them.

Best regards,
Todd

 

David Schultz
 

On 12/1/19 7:13 PM, taf123 wrote:
The basic is RCA 1800 Basic 1 Compiler/Interpreter Manual; MicroDisk
CDP18S834V4, supposedly NOS 1982.

I'll be picking up this and the MicroDOS disk, CDP18S845, over
Christmas.  Hopefully they arrived intact, etc.

How are these different from: https://groups.io/g/cosmacelf/files/MicroDOS

--
https://web.archive.org/web/20190214181851/http://home.earthlink.net/~david.schultz/
(Web pages available only at the Wayback Machine because Earthlink
terminated that service.)

taf123
 

I think they are the same.

Cheers
Todd

ajparent1/kb1gmx
 

I will repeat myself on one thing...

DO NOT PUT THAT DISK IN A DRIVE UNTIL ITS VERIFIED THE SYSTEM
CONNECTED AND THE DRIVE ARE WORKING (READS AND WRITES).

Sorry for the caps but:
Reason is something as simple as connector upside down can wipe a whole track.

Those disks seem scarce enough that killing one would be very bad.

Allison

taf123
 

Hi Allison -

Thanks for the all caps - I fully understand.  I'll treat them like the precious icons that they are.

Best regards,
Todd

ajparent1/kb1gmx
 

Just trying to make sure there is not one of those AH...poo! moments.

I should know.  My NS* horizon was hit by lightning back in '79
and spent 6 months tracking down all of the failures.  I made the
error described and soon as I hit reset... the boot tracks on
the master disk went away.  Fortunately it was not unobtainium
back then so it was a recoverable "very bad moment".

I got and built up the Netronics Explorer8085 to troubleshoot
boards one at a time.  Much easier.

If possible read the disks on a PC and save an image.  Least
then you can reproduce them.

Allison

 

On Sun, Dec 1, 2019 at 07:00 PM, cmdrcosmac wrote:

It's such a simple circuit. Use two of 'em!. One is set to the size and location
of the ROM. The other is set to reserve 256 bytes and addressed anywhere else
as needed. When placing the hardware, watch out for routines that scan for RAM
by writing and reading back. (As IDIOT does) Perhaps a control bit fed to the
688's enable pin, so the hardware cannot be accessed until software enables it.
 Then you run the /PQ outputs of the 688's thru a gate so either one will deselect
the RAM, and the one for the hardware can enable the chip selects of the hardware
devices, and the lowest address bits operate the register address bits of the devices.

 -Chuck
Ok, here's an untested design for inserting both ROM and I/O into the address space...  The I/O selector has priority so you could even map I/O into the middle of ROM address space.  You can also deselect I/O or ROM by driving the /OE pin high on the respective '688 chips.  So, yeah, you could swap ROM or I/O into and out of address space as needed.  While the design is relatively simple when using a 64K or 128K RAM chip, I suspect it wouldn't be difficult to use the other half of the 74HC139 decoder to provide the chip select signals for a pair of 32K RAM chips.
Cheerful regards.  Happy Holidays.  Mike, K8LH

 




From: "Mike McLaren, K8LH" <k8lh@...>
To: cosmacelf@groups.io
Sent: Thursday, December 5, 2019 12:40:21 AM
Subject: Re: [cosmacelf] Todd's ELF-ish to get an FDC #Homebrew #microboards

On Sun, Dec 1, 2019 at 07:00 PM, cmdrcosmac wrote:

It's such a simple circuit. Use two of 'em!. One is set to the size and location
of the ROM. The other is set to reserve 256 bytes and addressed anywhere else
as needed. When placing the hardware, watch out for routines that scan for RAM
by writing and reading back. (As IDIOT does) Perhaps a control bit fed to the
688's enable pin, so the hardware cannot be accessed until software enables it.
 Then you run the /PQ outputs of the 688's thru a gate so either one will deselect
the RAM, and the one for the hardware can enable the chip selects of the hardware
devices, and the lowest address bits operate the register address bits of the devices.

 -Chuck
Ok, here's an untested design for inserting both ROM and I/O into the address space...  The I/O selector has priority so you could even map I/O into the middle of ROM address space.  You can also deselect I/O or ROM by driving the /OE pin high on the respective '688 chips.  So, yeah, you could swap ROM or I/O into and out of address space as needed.  While the design is relatively simple when using a 64K or 128K RAM chip, I suspect it wouldn't be difficult to use the other half of the 74HC139 decoder to provide the chip select signals for a pair of 32K RAM chips.
Cheerful regards.  Happy Holidays.  Mike, K8LH