Floppy Emulation for the C1P/C4P

RedskullDC
Posts: 62
Joined: Thu Jul 18, 2013 11:24 am
Location: Dorrigo, NSW , Australia

Re: Floppy Emulation for the C1P/C4P

Post by RedskullDC »

hi Stephan,
stm wrote: Sun Jul 09, 2017 11:46 am

As I wrote earlier I had attempted to simulate a peripheral on the 6502 bus with a Raspberry Pi attached directly to the bus via level shifters, and this wasn't successful. Therefore I would like to pick up Dave's idea to implement bus buffering and address decoding with "regular TTL chips".

I'm not fluent in designing logic with TTL chips, so if someone could sketch out roughly the elements of a bus buffering and address decoding logic I would appreciate it a lot. What kind of TTL chips would be suitable for this?

I also read about 5V-tolerant CPLDs. Could they be used to implement the logic and also the necessary level-shifting in one chip? I read for example about Lattice ispMACH 4000ZE CPLDs or the Xilinx XC9500XL family.
A 74LS245 8 bit bi-directional buffer is what you need.
Address decoding will depend on where you want the device to appear in memory?

Check out 6502.org for lots of home built projects along these lines.

Those CPLD families, also the Altera MAX 3000 series, could encapsulate both the address decoding and buffering functionality. You can get 9500xl chips mounted on DIP adapters cheaply on EBay if you want to experiment along those lines.

Cheers,
Leslie
Superboard II - RevD, 8Kb, DABUG monitor ROM.
C1P - RevD, 610, 2 drives, CEGMON.
FPGA C1P/C2/C4. 1-8MHz, 48Kb ram, CEGMON, 16KB Hires.
stm
Posts: 63
Joined: Mon Oct 27, 2014 10:23 pm
Location: Germany

Re: Floppy Emulation for the C1P/C4P

Post by stm »

RedskullDC wrote: Sun Jul 09, 2017 2:21 pm
A 74LS245 8 bit bi-directional buffer is what you need.
Address decoding will depend on where you want the device to appear in memory?
The device should appear at 0xC000 and the following addresses to emulate the 6820 and 6850 chips of the floppy controller.
RedskullDC wrote: Sun Jul 09, 2017 2:21 pm Check out 6502.org for lots of home built projects along these lines.

Those CPLD families, also the Altera MAX 3000 series, could encapsulate both the address decoding and buffering functionality. You can get 9500xl chips mounted on DIP adapters cheaply on EBay if you want to experiment along those lines.
Thanks, I will take a look at these resources.
C1P Model 600 CPU 1978 REV B, 40K (8K original and 32K BillO memory expansion), RS-232
Maintainer of cc65 OSI target and llvm-mos-sdk C1P target
dave
Site Admin
Posts: 710
Joined: Tue Sep 09, 2008 5:24 am

Re: Floppy Emulation for the C1P/C4P

Post by dave »

The PIA is at $C000.

The ACIA is at $C010

To get an idea of how the TTL decoding and buffering works, take a look at the 470 schematic, or any other of the OSI schematics on the site. However, as Leslie suggests, a more current chip would be a better choice for bus transceiver than the 8T26's. However, since the native OSI boards use inverting 8T26 buffers, the data on the 48-line bus is inverted, you you'd want to use something like a 74HC640.

Using HC logic, there should be no need for level shifting when using a 5V-tolerant MCU, as the logic thresholds will be compatible, and the HC parts will not load the outputs significantly.

You may end up using a bunch of chips for decoding: inverters for address lines A8-13, a '30 8-input NAND, more AND/NAND for the ph-2 clock, etc, plus a latch to hold the valid data for the MCU to read it. A better option would be a single 22V10. Atmel still makes them, they work from 3V to 5.5V, and they can hold address decoding and latching of data, plus latch the low address bits and R/W line, so the MCU can tell what register to emulate.

After a register control write, you'll have a few microseconds to set up the port outputs, as the processor will have to fetch the next instruction, etc. That should be doable.

Dave
stm
Posts: 63
Joined: Mon Oct 27, 2014 10:23 pm
Location: Germany

Re: Floppy Emulation for the C1P/C4P

Post by stm »

dave wrote: Mon Jul 10, 2017 12:27 pm The PIA is at $C000.

The ACIA is at $C010

To get an idea of how the TTL decoding and buffering works, take a look at the 470 schematic, or any other of the OSI schematics on the site. However, as Leslie suggests, a more current chip would be a better choice for bus transceiver than the 8T26's. However, since the native OSI boards use inverting 8T26 buffers, the data on the 48-line bus is inverted, you you'd want to use something like a 74HC640.

Using HC logic, there should be no need for level shifting when using a 5V-tolerant MCU, as the logic thresholds will be compatible, and the HC parts will not load the outputs significantly.
Currently I'm working with a Raspberry Pi Zero, which is not 5V tolerant. So therefore level-shifting is needed.
dave wrote: Mon Jul 10, 2017 12:27 pm You may end up using a bunch of chips for decoding: inverters for address lines A8-13, a '30 8-input NAND, more AND/NAND for the ph-2 clock, etc, plus a latch to hold the valid data for the MCU to read it. A better option would be a single 22V10. Atmel still makes them, they work from 3V to 5.5V, and they can hold address decoding and latching of data, plus latch the low address bits and R/W line, so the MCU can tell what register to emulate.

After a register control write, you'll have a few microseconds to set up the port outputs, as the processor will have to fetch the next instruction, etc. That should be doable.

Dave
I looked at the Atmel 22V10, and it has so few pins so that I don't understand how that could work. I had thought that a device that could handle decoding and buffering would need a lot more I/O lines: 16 address lines, 8 data lines, R/W, DD, clock on the 6502 bus side, and on the MCU side 8 data lines plus some additional control lines. How could the Atmel 22V10 handle decoding and buffering on its own, or would it still be necessary to have additional chips for a full solution?
C1P Model 600 CPU 1978 REV B, 40K (8K original and 32K BillO memory expansion), RS-232
Maintainer of cc65 OSI target and llvm-mos-sdk C1P target
dave
Site Admin
Posts: 710
Joined: Tue Sep 09, 2008 5:24 am

Re: Floppy Emulation for the C1P/C4P

Post by dave »

You're right, you'd have to use a transceiver for the data lines.

You only need 8 lines to decode $C0xx, plus a couple more for 02-VMA, R/W*, an output for DD, a line to generate an interrupt. If the processor is not fast enough to sample the low address lines and data lines in real time, then an HC373 could be used to latch the valid data, and 4 inputs+4outputs could latch A0, A1, A4, and A5, or encode them to a 3-bit register code, or the interrupt line could control a 4-bit latch.

So with a 22V10, you have a minimum of 2 chips, but could use 3 or 4 chips depending on how fast your processor can service an interrupt.

Dave
RedskullDC
Posts: 62
Joined: Thu Jul 18, 2013 11:24 am
Location: Dorrigo, NSW , Australia

Re: Floppy Emulation for the C1P/C4P

Post by RedskullDC »

Hi Dave, et al.
dave wrote: Mon Jul 10, 2017 11:21 pm
So with a 22V10, you have a minimum of 2 chips, but could use 3 or 4 chips depending on how fast your processor can service an interrupt.

Dave
Do any of the OSI disk operating systems use interrupts in any way? (That you know of).

I'm currently disassembling OS65D.32 (NMHZ) and can't see anywhere that interrupts are employed.

Looking at the schematics of the 610, 470, 505B disk controllers...
They all have provision for the PIA IRQ outputs to be tied to *IRQ or *NMI, but was there any need to ever do so?


Cheers,
Leslie
Superboard II - RevD, 8Kb, DABUG monitor ROM.
C1P - RevD, 610, 2 drives, CEGMON.
FPGA C1P/C2/C4. 1-8MHz, 48Kb ram, CEGMON, 16KB Hires.
dave
Site Admin
Posts: 710
Joined: Tue Sep 09, 2008 5:24 am

Re: Floppy Emulation for the C1P/C4P

Post by dave »

RedskullDC wrote: Tue Jul 11, 2017 5:11 am
Do any of the OSI disk operating systems use interrupts in any way? (That you know of).

I'm currently disassembling OS65D.32 (NMHZ) and can't see anywhere that interrupts are employed.

Looking at the schematics of the 610, 470, 505B disk controllers...
They all have provision for the PIA IRQ outputs to be tied to *IRQ or *NMI, but was there any need to ever do so?


Cheers,
Leslie
OS65D doesn't use interrupts, and I don't believe any other OS's do.

However, if a floppy interface is implemented by a microprocessor by emulating the PIA and ACIA registers at the board level, that software would likely be using interrupts to service the I/O port.
dave
Site Admin
Posts: 710
Joined: Tue Sep 09, 2008 5:24 am

Re: Floppy Emulation for the C1P/C4P

Post by dave »

The more I think about it, emulating at the floppy-cable level rather than the hardware register level, would reduce the timing requirements on the implementation processor, reduce the chip count, eliminate a section of code (and therefore potential bugs), and would benefit a wider range of systems.

Instead of address decoding and register emulation, you'd put the STEP, Drive select, etc. on a port, to generate an interrupt on change.

The FM serial TX line would go to an input which would be configured for interrupt when a clock input rising edge is expected. The ISR would disable the interrupt-on-change and start a timer for the data sample window, and the timer ISR would sample and queue the data bit, disable the timer interrupt, and re-enable the interrupt-on-rising-edge for the input. That would emulate the data separator circuit currently used, and would be easier than implementing a software/digital PLL.

The data out to the controller would simply be a UART in async mode, emulating the built-in data separator.

The rest of the software would be the same regardless of how the OSI interface is implemented: map an input stream to a track, and map a track in memory to an output stream. Preserve an approximate timing relationship between the data streams and data location on the track, when it can make a difference to the OSI Operating system. Map tracks to disk in a standard format.
w4jbm
Posts: 23
Joined: Sun Jun 18, 2017 1:41 pm

Re: Floppy Emulation for the C1P/C4P

Post by w4jbm »

I go back and forth on what I think is the "best" approach, but I tend to agree that something that emulates at the "floppy cable" level gives the most flexibility and probably would not require much in the way of exotic hardware.

For FPGA systems, you could emulate the VIA and ACIA and built what amounted to a 470 card without too much effort. (Gez, I say that like I actually have even modest VHDL skills...)

From that, it seems reasonable modify the FGPA code to build a "mini floppy controller board" that would interface to the OSI bus on one side and the emulated floppy on the other.

For reads, once you are on a track and have had some "settling time" (which, in this situation, would probably be time to load a buffer), you just keep sending the index pulse, wait a millisecond, and then send the track data. That just plays over an over. (And can even keep going when the "head up" command is sent without too much concern.)

When write is enabled, you send the index pulse and then listen. You could work with the timing, but the easiest way to do it would be to just take the track and sector number and byte count that is in the header of the data you read. You could "enforce" good behavior if you wanted to, but I'm not sure it is worth the trouble.

The only thing bad about that approach is you could not use the "standard" disk emulation formats without some type of conversion. Basically I could see a set of files that were named with the track number and sector. On read, you just play back the track one sector following the other. On write, you capture the sector number and data, and then store it.

Unless you do some type of error checking, someone could probably do things like write 8 sectors of 2K each on a track. I would have to dig into the disassembly, but I don't believe that would really "break" anything in OS65D. (It would also have limited value for the way most users access the disk anyway.)

I don't believe OS65D enforces good behavior, you just ended up with wrap around and overwriting past the index hole if you had a track that was too long. That would corrupt a track, but I don't remember you being stopped from doing that.

The only "trick" is track zero being formatted differently than other tracks. (The header includes the load address followed by the data.) I don't think that exception would be too difficult to handle.

If there is interest in the floppy cable interface instead of serial emulation, I'll have to dig the C4P MF out of storage and get it running... :-)

thanks,
Jim
Steve Gray
Posts: 321
Joined: Mon Oct 06, 2008 1:54 pm
Location: Markham, Ontario, Canada
Contact:

Re: Floppy Emulation for the C1P/C4P

Post by Steve Gray »

I assume eveyone is familiar with the gotek floppy emulator?
www.gotek.in
Available from about $10 on ebay. I have one for my amiga, although for amiga's special disk format it requires custom firmware. Not sure the OSI disk format could be supported but it might be worth a look.

Steve
C4P working, C1P working. 600D Replica working, C4P+D&N floppy not working. 505 board, 610 board, Mittendorf board, TOSIE hacker board need testing, PicoDOS disk untested.
Post Reply