Floppy Emulation for the C1P/C4P

w4jbm
Posts: 23
Joined: Sun Jun 18, 2017 1:41 pm

Floppy Emulation for the C1P/C4P

Post by w4jbm »

There has been some discussion of how to handle floppies drives in the thread on FPGA implementations. I have actually given this a fair amount of thought (although I'm sure there is also a lot I haven't thought of). I have done a bit of digging into the ROM and OS65D code, but not as much as I need to. The main thing that keeps me from digging out my C4P MF at this point is a concern about the floppies and not wanting to burn through their remaining life without some kind of Plan B.

To me, there are a couple of ways to go about this:

1. "Drive" Emulation
One approach would be a solution where the existing floppy drive ribbon cable connects to some other type of device that could accept and provide the I/O of the floppy drive itself.

2. "Board" Emulation
Another approach would be to emulate both the controller board and the drive. This might be easier because you could add some "abstraction" between the emulated floppy controller chip and the emulated drive. The disadvantage is it means hardware, but the advantage would be that even people using systems without floppies could implement the solution on their machines.

3. Patched OS65D Software
I like the DriveWire solution the CoCo users have come up with. It is basically based on a serial interface approach where the drive is emulated on a PC. This makes file transfer to the PC world easier. It also lets you do some creative things. One example would be you could always have a file named "TIME" and one named "DATE" that return the current time and date in what looks like a file on a floppy to the OSI machine. You could also have something like a file named "POUT" that would accept raw text and print it out. You could also handle sound and other things in the same solution framework. This would require patching OS65D, but could probably be done in a way where that was largely invisible--except for the issue of the bootstrap...

4. Hybrid "Floppy" Emulation with Serial Patch
So the boot process is fairly straight forward. Things check to see if the "Track Zero" flag is set by the floppy. If not, it sends the signal to step back down a track and checks again. Once at Track Zero, it waits for a pulse from the index hole and then (after a short pause) reads the track. The first two bytes indicate where the track is to be loaded in memory and once it is loaded control is passed to it. (There is loading the head and some timing details glossed over in that.) If you think about it, that is pretty easy to emulate--always show you are on Track Zero, send an index hole pulse and then a stream of data over an over again until something else happens. The Track Zero image you load could be a modified version of OS65D patched to use a serial port for file storage (similar to DriveWire). Basically you would just keep repeating the sending of the index pulse and your new Track Zero over and over again until the bootstrap was run and sent you some type of response that said it was ready for you to change from "Boot Mode" to "Run Mode".

My thinking started with #1 and then moved to #3 and quickly (from there) to #4. (I have given some thought to how to handle a machine that currently doesn't have a drive controller. I think you could probably figure out a way to do it without resorting to a new ROM, but having a modified ROM would have the advantage of giving you a way of also dealing with a failed drive control chip. If you went down a path similar to DriveWire, I really think a patched ROM would save a lot of time dealing with the "how do I boot?" issue and let you focus on the storage solution itself instead.)

Setting that aside for a minute, I've also thought about the hardware needed.

1. A PC "Server" Solution
This is how DriveWire does it and it offers a lot of advantages. You can control the loading and unloading of disk images on the PC if you want. You can (as mentioned earlier) draw on resources the PC has like a clock or even the Ethernet port or Internet access. The disadvantage is it does likely mean a patched OS on the OSI and having to boot your PC every time you want to use the OSI.

2. Dedicated "Board" Part 1: Raspberry-ish...
Something like a Raspberry Pi could replace the PC in a server type solution. It is small and could even be mounted inside one of the C4P MF drive enclosures while leaving the drive in place (but disconnected--and maybe with a smaller power supply if you didn't want to use a wallwart). My problem is that I can do 8-bit assembly and a bit of PIC assembly or BASIC. I'm comfortable with Linux, but not with C or some of the other programming options. But it feels like the "Track Zero" stuff could be coded without too much trouble.

3. Dedicated "Board" Part 2: FPGA...
I've also thought about an FPGA-based approach. I'll admit that this seems non-trival to me. (But seeing how Leslie can crank out HDL code to emulate a C4P, that is very likely more of a problem with me than with the approach.) For me, this feels like a path I might start down but I'm not comfortable I could finish before frustration overtook me.

What about storage media? SD cards? I've also thought about that. For something PC based, it is a moot point. (You use the computer's hard drive.) But a SS/SD floppy only stored (once overhead was removed) a maximum of 40 tracks with 2 kilobyte each--a total of 80 kilobytes. 1 Megabyte of storage would be about a dozen floppies, so talking about something like a gigabyte just seems to be huge overkill. I'm thinking that 10 Megabytes or so is probably going to be enough for anything I do.

(As an aside, I did a lot of work under OS65U on a machine with around 20 Megabytes and I had split the disk into three areas--the production system most people used (it was a multiuser machine running payroll, AR, AP, and GL), two backups of the production system that I alternated between doing regular backups (once a week at a minimum), and a development system that was pretty much just for me to use. We never came close to running out of space.)

So here is what I've been thinking...

Develop something like DriveWire on a PC using BASIC (cringe if you want), develop a patched boot ROM, and then a patched version of OS65D. I am thinking of something like a set of BIOS calls I could define with the C4P just sending simple commands over a serial link. (The commands could be things like go to a track number, load a track & sector to an address in memory, store from an address in memory to a track & sector, etc.. Probably also some extension like being able to retrieve time and date info, mount a volume (you could always "fake" a file that had a list of off disk volumes and also "fake" a file that was part of all of them that you could load and run to be menu driven on the C4P), etc..

That just "feels" achievable to me--some assembly language programming to patch the ROM and OS65D, some BASIC coding on the PC side, and then probably some BASIC coding back on the C4P side for the utility programs that could leverage a more powerful set of BIOS calls without forcing legacy programs to be aware that they even existed.

Once that was working, it would be logical to try to migrate it to something like a Raspberry Pi to get the PC out of the equation. It would also make sense to try the "emulated" Track Zero boot approach with some hardware to allow the system to boot without having to patch the ROM.

I like the "Have a big vision, but allow for modest victories." approach.

I will add two other things.

The first is that the FPGA implementation of a C4P is changing my thinking some. With it, patching the ROM is trivial. It offers a way for new users who never owned an OSI machine to have one to play with. An entire DriveWire-like solution could be implemented behind the scenes and just leverage a serial port for I/O between the FPGA-based computer and the storage solution.

I will also admit that whoever takes the time to do the first bit of hardware or coding work is the one who ultimately decides on the path. As much as I think I have a good idea, I don't expect anyone else to take and code /build my idea for me. Everyone has different skills (coding in different languages, a comfort with building hardware, knowledge of FPGAs, etc.) and different goals. (As a proof point, I've ordered the same FPGA board Leslie is using for development in part because I know that even migrating his project to another board would take effort and time that I would rather invest in something else.)

Once I have the FPGA machine running, I will probably start tinkering with OS65D as time allows. My initial thought is to have it load via the monitor as a memory load file along with the patches needed so it doesn't hang when it can't discover a disk drive. I'd like to get that to the point of having OS65D BASIC running (without the disk functions).

(A warped part of me wants to also get the editor, assembler, monitor that was part of OS65D running for the sake of nostalgia.)

The idea is to get some discussion going, so I'd be interested in hearing feedback, other thoughts, etc..

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

Re: Floppy Emulation for the C1P/C4P

Post by stm »

Jim,

thanks for starting this thread.
w4jbm wrote: Sat Jul 01, 2017 8:56 pm 2. "Board" Emulation
Another approach would be to emulate both the controller board and the drive. This might be easier because you could add some "abstraction" between the emulated floppy controller chip and the emulated drive. The disadvantage is it means hardware, but the advantage would be that even people using systems without floppies could implement the solution on their machines.
Of all the approaches you are listing this is the one I'm interested in personally. I have a C1P that is in good shape. It is modified with a modern 32K RAM extension board produced by BillO, so it is not in its "original" state anymore. Although I would have loved to extend the machine with original components to get a working floppy-based system with maximum RAM, I know that it is illusionary to get the original components today. Specifically the floppy drives are a problem of course. So while I said goodbye to the idea to extend my original machine with original parts, I want to keep my original hardware (the C1P with 8 KB RAM I bought in 1979) and the original system software intact.

As I wrote in the FPGA Implementations thread I made some efforts to implement a floppy emulator for the C1P. I have tried an FPGA-based implementation as well as an implementation based on Raspberry Pi Zero.

A general challenge is to attach the external hardware, be it an FPGA board or a Raspberry Pi, to the 6502 bus. Because of the different voltage levels you need level shifters. For an experimental breadboard setup lots of wires are necessary to connect the expansion socket to the level shifters and the level shifters to the FPGA board or to the Rasperry Pi board. The number of wires alone generates lots of possibilities for errors. I'm not even sure whether from the electrical perspective a breadboard circuit with dozens of wires carrying signals at 1 MHz can be considered stable enough to get repeatable results.

As I wrote earlier, I had to abandon the FPGA solution because I couldn't solve some fundamental problems with my VHDL code. That's why I did another attempt with a Raspberry Pi Zero. I thought that a Raspberry Pi Zero with a 1 GHz system clock should be powerful enough to emulate a peripheral device on a 6502 bus with a 1 MHz clock.

But as it turned out this is quite a challenge. You can't run a normal Linux on the Raspberry Pi because of the real-time requirements. To act like a real device on the 6502 bus the Raspberry Pi has to handle 2 million interrupts a second. It must act on the rising edge and on the falling edge of the 6502 system clock, and it must not miss a single cycle of the 6502 system clock. Because of this requirement I used a bare-metal programming environment for the Raspberry Pi Zero. I got to the point where a test program was able to handle 2 million interrupts a second with a test signal, but when I tried to apply this to a test program that was supposed to handle the real 6502 bus protocol I did run into problems that I could not successfully debug.

So if someone has ideas about or experience with how a floppy controller could be implemented, I would be very interested.

Thanks
Stephan
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
w4jbm
Posts: 23
Joined: Sun Jun 18, 2017 1:41 pm

Re: Floppy Emulation for the C1P/C4P

Post by w4jbm »

I hadn't thought through all the challenges of emulating the floppy controller before.

It does seem that if you implemented the chip select logic seperate from the Raspberry Pi, it would make software emulation easier. And a lot of things could be simplified from the original approach. For example, why bother to even interpret and process the head load and unload logic?

Originally, the data was moving in and out through an ACIA. Implementing that would be a challenge to the Raspberry Pi.

Bottom line is that if you have a controller board, it is probably a lot easier than if you don't.

I actually have all the boards except the floppy controller from a C3 system. It would be cool to find a way that is flexible enough to bring up 65U on that.

You raised some interesting points I need to think on.

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 purchased a couple CH376 modules. I think they might be an easy and inexpensive solution.
They provide an 8-bit parallel or SPI interface to an SD card or USB memory key.

https://www.mpja.com/download/ch376ds1.pdf

If the Mattel Aquarius can interface to it, so can we! ;-)
https://www.youtube.com/watch?v=pNILWgb0HBc

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.
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 »

Or, for something already done on a 6502 system... BBC Micro MMC interface:
https://swhs.home.xs4all.nl/bbc/mmbeeb/

I have a BBC Model B with this interface.

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.
stm
Posts: 63
Joined: Mon Oct 27, 2014 10:23 pm
Location: Germany

Re: Floppy Emulation for the C1P/C4P

Post by stm »

Steve Gray wrote: Sun Jul 02, 2017 4:39 am Or, for something already done on a 6502 system... BBC Micro MMC interface:
https://swhs.home.xs4all.nl/bbc/mmbeeb/
That looks simple, but how would you attach this to a C1P? And do I understand it correctly that you would need a modified ROM and/or OS65D for using it?
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
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 all,
On my phone so apologies for the brevity.

Few ideas, just thinking aloud:

Ch376 is cheap and easy to interface to any osi board. Two 8 bit latches and a chip select.
Multiple disk images can be held on the sd/USB stick.
Will need special drivers written, and rom patches to boot.
Positive side, can emulate floppies without a controller card.
Also easy to interface to your fpga board of choice.

Drivewire option requires drivers, and also host software.
Always tethered to your pc.

Doing it in the fpga requires a co-processor to emulate the PIA/ACIA, talk to SD card,and handle FATfilesystem.
Been done before in minimig (Amiga) and in coco3fpga.
Lot of work, but means no special software needs to be written.

I like the ch376 or a teensy 3.5 board myself. 5v tolerant I/Os, so can be connected to fpga and also real machines.
Teensy has SDFAT libraries to leverage.
On the fpga requires no drivers, on real hardware would require boot rom mods, and custom drivers.
Multiple disk images possible on an sd card.
Images can be in winosi format for easy exchange with an emulator.

On the road this week, but will give it some thought...

Cheers,
Leslie
dave
Site Admin
Posts: 710
Joined: Tue Sep 09, 2008 5:24 am

Re: Floppy Emulation for the C1P/C4P

Post by dave »

This is a good thread.

All of these options have some appealing features. Here are some thoughts.

The CH376 looks very interesting. The biggest advantage is that a relatively puny processor, even a 6502, can fully control it. Using the serial interface, it should be possible to interface this chip directly to the OSI without any hardware mods, via the ACIA on the floppy controller, or even via the standard serial interface. ROM and OS patches would be required, though.

The drivewire/Rpi option is similar, requiring no hardware mods, and leveraging the disk interface or standard serial port. The ROM and OS pathches could be even simpler, since more intelligence could be implemented at the host. The idea would be to replace the various PIA control lines with serial commands (step in/out, query track 0, ACK when ready, etc.) and also give all serial transmission (commands and data) a packet format, such as <command, length, data, CRC> and implement some handshaking. The host would know the disk format and geometry and could map the raw sectors / tracks to a standard format (WinOSI, or a JSON equivalent).

Replacing the disk controller board would best fit the capabilities of a medium-power processor with enough RAM to buffer at least one track of data (like a cortex M0/M3, PIC24/PIC32, or ATMega). Regular TTL chips would still handle bus buffering and address decoding, so there is no need to generate an interrupt for every address bus change. The chip would emulate PIA and ACIA control registers, which could definitely be done fast enough to keep up with the OSI bus. FAT32 libraries are available, and using a fixed file format such as the WinOSI disk format, it would be straightforward to map tracks directly to disk. Although MCU libraries may make the CH376 reduntand for SD-card interfacing, the ability of the CH376 to interface to a USB stick as well as SD card makes it an intersting option.

Using the standard disk interface and replacing a drive would be similar to the controller-replacement option, with nearly identical firmware, except instead of emulating the control register interfaces, it would read the parallel control lines directly via a parallel port with interrupt-on-change; and would read the serial stream directly via the UART. There would be 3 options for handling the FM data stream from the OSI disk controller

1) Modify the OSI disk controller: bypass the FM encoder on the disk controller. This would result in a synchronous serial data stream that would interface directly to the MCU UART.

2) Unmodified OSI disk controller: Include a data separator in the emulator circuit, do decode the FM serial stream back to clock/data, which then interfaces to the UART. Same firmware as option (1). In fact, either option (1) or (2) could be selected in a single implementation with some jumpering, etc.

3) Unmodified OSI controller, data separator in software: This would be similar to the firmware for (1) and (2), but instead of a UART receiving the FM data, the clock/data would be bit-banged using an interrupt-on-change line, and a timer to sort out clock and data pulses. The timer would be adjusted on the fly to center the data pulse, either using a timeout like the classic hardware data separator, or using a digital PLL. The rest of the firmware, including UART transmission back to the OSI controller, would be identical to options (1) and (2).

Dave
w4jbm
Posts: 23
Joined: Sun Jun 18, 2017 1:41 pm

Re: Floppy Emulation for the C1P/C4P

Post by w4jbm »

I haven't been in the guts of my C4P MF in years, so I'd have to check what space is like, but actually the idea of using the existing 6850 and 6820. Some type of "daughter board" could be used on each to run most of the chips pins except those that you wanted to connect to the storage device straight through. On the daughter boards you could pull the PIA and ACIA pins you wanted to use off.

I have to admit that I'm attracted to a pure "serial" solution. That means patching the ROM and the OS, but it also means something that is fairly easy to get up and running in a beta form. It also would be easy to build a "from scratch" interface because all you would need would be a 6850 and the chip select logic. And for an FPGA implementation, you just need a second ACIA.

One other advantage I see is that something like a C1P or C2-4P that does not currently have a floppy controller could be modified to use the existing serial port that normally connects to the tape interface as a way to now interface into an emulated floppy. (In fact, given a bit of work, it seems like you could include a boot strap that would emulate a tape at first to load a bootstrap and then swap over to a patched version 65D. You might be stuck with much slower transfer rates unless you wanted to change the ACIA clock and have to deal with backwards compatibility issues with tapes.)

Patching the boot code on the ROM would be easy. (Especially on an FPGA implementation. And that, more than modifying and restoring my C4P MF is what I'm thinking about at this point.)

Here's a total rabbit hole to go down...

The more I think about it, the less certain I am about that. Maybe you don't need to modify anything at all other than the existing serial port.

You could boot to BASIC, type LOAD, and then push a button on the floppy emulator. At that point, control has effectively moved from the keyboard to the serial port. You could load a small boot strap as a BASIC program with some POKEs and end the LOAD with a RUN command. The bootstrap you had just poked in could then take over, load a patched version of OS65D, and pass off to a cold start of that.

(That would work for all systems with BASIC in ROM--I need to think more on things like the C4P MF and others that did not have BASIC in ROM. I think the processor board has sockets for BASIC in ROM but they just aren't installed, but I'm getting way out on a limb without taking the time to dig through the manuals at this point. If they are socketed, then installing BASIC ROMs might be the way to go.)

What the other end of that serial connection looks like could be a couple of things. I would still lean towards a PC-based server side for a proof-of-concept with the idea being that eventually that would eventually migrate to a small board that could be installed in a floppy enclosure or maybe even inside the computer.

I am thinking that whatever is used would be driven by serial commands.

Since you are patching the OS anyway, some of the issues I've been concerned about would go away. You could make all "disks" look like they are 80 tracks (or maybe 128?) with the bottom always having the OS and the upper part always having a few utilities. You could have a BASIC utility that provided a menu driven system for loading particular images, setting options, etc.. It could be patched for 12 character file names. The directory could be expanded to support more entries.

Once someone digs into OS65D and figures out the necessary patches, it would not be that hard to build other patched versions for different flavors of drive emulation. As much as I would like to have 65D v3.3, the fact that the disassembly listing of v3.2 is available would tend to make me want to start with that. I'm not that familiar with the C1P floppy options and how different OS65D is for it compared to the C4P. (I don't think there is much difference. Trying to do something like HEXDOS might be entirely different.)

The one concern I have about something like the CH376 is whether I would have room for the patches in the existing code. Obviously there would be a strong preference to having patches that were shorter than the original code rather than longer. That is part of why I like offloading a lot of the intelligence to the remote end. Having said that, I know there are a few chunks of unused code in OS65D v3.2 where you might be able to free up some space for use.

I need to pull out some manuals and do some research at this point...

Thanks,
Jim
dave
Site Admin
Posts: 710
Joined: Tue Sep 09, 2008 5:24 am

Re: Floppy Emulation for the C1P/C4P

Post by dave »

w4jbm wrote: Sun Jul 02, 2017 2:21 pm (That would work for all systems with BASIC in ROM--I need to think more on things like the C4P MF and others that did not have BASIC in ROM. I think the processor board has sockets for BASIC in ROM but they just aren't installed, but I'm getting way out on a limb without taking the time to dig through the manuals at this point. If they are socketed, then installing BASIC ROMs might be the way to go.)
The 505 CPU in most C4/8 MF/DF systems doesn't have BASIC ROM sockets. Plus, BASIC takes up 8K that could otherwise be used for RAM (which the 505-based systems do).

However, all systems have monitor ROMs that can be used to download a boot program, and that would provide a workable boot option for all systems, with or without ROM BASIC, without any modification.

The existing cassette interface can be sped up to 4800 baud without any hardware mods, but I think that a 1 MHz machine could support a 115200 baud rate.

Dave
Post Reply