Floppy Emulation for the C1P/C4P

RedskullDC
Posts: 44
Joined: Thu Jul 18, 2013 11:24 am
Location: Sydney, Australia

Re: Floppy Emulation for the C1P/C4P

Post by RedskullDC » Tue Jul 04, 2017 8:25 am

Few more thoughts on the drivewire idea...

On the Tandy CoCo, to run drivewire, you need a floppy controller cartridge with a modified eprom, rs232 cartridge, and an MPI board to allow both cartridges to be connected at one.
All of Tandy DOS, or drivewire DOS is in rom on the FDC anytime it is connected.

On the plus side, drivewire can still work with normal disk drives, allowing image copies to be made.
Easy to get going on FPGA, less so on real hardware.

A Modified OS65 could also be stored in a rom area, say $C800, $E800 for instant on access,
like DW on the coco, or for storage of the DW drivers, or both!

Leslie

MK14HAK
Posts: 351
Joined: Wed Mar 16, 2011 1:49 am
Location: New Zealand

Re: Floppy Emulation for the C1P/C4P

Post by MK14HAK » Tue Jul 04, 2017 10:02 am

Would be good to take a look at Drivewire4 in operation. Is there an A2e client for available ? (A2e and Atari logos)


(6809 daughter board http://www.cloud9tech.com/ Nice...)
600RevB:16K,2MHz,64x32,470,CEGMON
SuperKit:502,540B,542B,CEGMON, 8" and 5" FDDs
Cards:PE IO,6522 D-A-D, AY3-8910,ProgramGraphics,Color,UK101
WIP:HexDOS,FDD Emulator

RedskullDC
Posts: 44
Joined: Thu Jul 18, 2013 11:24 am
Location: Sydney, Australia

Re: Floppy Emulation for the C1P/C4P

Post by RedskullDC » Tue Jul 04, 2017 2:02 pm

MK14HAK wrote:
Tue Jul 04, 2017 10:02 am
Would be good to take a look at Drivewire4 in operation. Is there an A2e client for available ? (A2e and Atari logos)
Check out:
https://youtu.be/oFnttB5YOMg

Apple 2 has ADT, which is kind of similar.

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

Re: Floppy Emulation for the C1P/C4P

Post by w4jbm » Wed Jul 05, 2017 9:56 pm

I've been digging through the OS65D manuals a bit. To me, one of the challenges is that there is no set number of sectors and no set sector size on the floppy.

You have roughly 2K to work with on a track, so you can define that as one sector that is 2K in length, two sectors that are each 1K in length, or some other number and random combination (where sector sizes are multiples of 256). If I remember right, really trying for 8 sectors of 256 bytes usually didn't work.

The thing is, that entire complication goes away (or at least was behind the scenes) with the way I used the floppy 99% of the time. BASIC programs were based on taking up entire tracks (in some multiple). Some of the utilities and the directory structure rely on smaller sectors.

It is fairly simple to patch OS65U to handle 12 character file names. (Although you have to also edit many of the utilities to deal with them.)

Parts of it make me think any patches will be straight forward. Other parts of it make me think it would almost be better to start from scratch. (Yeah, I know... That wouldn't really make much sense.)

I do want to dig into DriveWire a bit deeper. I do wonder why there doesn't seem to be something like a Raspberry Pi version of the DriveWire server. (Although it should be doable even without someone already making the image for you.)

One really interesting thing is that DriveWire even has .WAV files to allow booting from the cassette interface.

I will ask one question--does anyone know of any application or would anyone be writing anything that needs multiple sectors per track? What I'm thinking is that part of the patching would be to give the things that use sectors their own tracks and increase the number of tracks to 99. (I would like to keep with the smaller track size of 2,048 bytes used by on the mini-floppy version just so you don't have to create large buffers for large track sizes.) That would also allow more entries in the directory. (Which only became an issue with longer file names, but would also come into play with more tracks.)

All the utilities (create, rename, print the directory, sort the directory, print the sector map, etc.) could be up in one of the higher tracks. The OS would be on the lower tracks as it originally was. I'm also thinking that some type of utility could be used to manage "volumes" and allow them to be indexed and "loaded" into one of the two drives.

I still kind of view first step for me is getting disk BASIC into memory on an FPGA-based system and "booted". I'll admit the C4P was largely used for tinkering and writing games in BASIC and assembly language. During college my "day job" was with multi-user systems using OS65U. I never really did much file I/O in OS65D. By the time I graduated, IBM PCs were getting traction and the C4P went up on a shelf for a while and then into the box where it has been when I first moved back around 1992.

I do see a fairly serious "design criteria" emerging. To make it usable on the FPGA-based system, it is easier to go the serial connectivity path with a patched version of OS65D. That also may be a good approach for systems that lack a floppy controller if they are willing to use the serial port that is currently used for the cassette port, but would require some modification of the clock unless you were willing to live with a 300 baud floppy. For a system with floppies, you could either use the serial port or you could modify the ACIA on the floppy controller. (I have not looked at how hard it would be to get the ACIA on the controller to some kind of reasonable speed.)

If you don't go that approach, you have several things that have to be developed: 1) Something that emulates the drives to the "ribbon cable", 2) something that looks like a floppy controller card for systems that don't have disk controllers, and 3) some way to interface all of that into FPGAs either in HDL or hardware. The upside is you could use an un-modified OS65D in theory.

It just seems like the serial approach takes a lot of coding while the other approach involves a fair amount of hardware interfacing work.

Sorry to ramble... Always interested in feedback or observations.

Thanks,
Jim

RedskullDC
Posts: 44
Joined: Thu Jul 18, 2013 11:24 am
Location: Sydney, Australia

Re: Floppy Emulation for the C1P/C4P

Post by RedskullDC » Thu Jul 06, 2017 1:02 pm

Hi Jim, et al.

On my phone, so please forgive any errors.

The drivewire server program is java?
Someone has it going on the Pi:
https://youtu.be/csBeXwNJaeA

Source is freely available I think.

Amiga hardware also reads/writes 1 full track at a time. Any division into tracks and sectors is done by the software. So it is possible. disk driver just sees a "block number".

OS65d looks more tied to the hardware as far as I can see.
Any emulation has to generate index hole pulse to a degree of precision. Easy on fpga.

Interval between index holes could be increased for more storage in emulation.
Would require minor patching of os35d

One option that hasn't been suggested is interfacing real 5.25/3.5" floppy drives to the fpga board. Being able to create real floppies is attractive.
(In addition to some DW/SD card interface).
Easy to up the transfer rate from 125kHz to 250kHz too for more storage.

Enhanced floppy controller could be placed on a cpld for real osi machines.

Cheers,
Leslie

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

Re: Floppy Emulation for the C1P/C4P

Post by w4jbm » Thu Jul 06, 2017 10:51 pm

I wouldn't mind being able to read and write real floppies. (And, hopefully if it isn't in too bad of shape, the original C4P MF would be able to do that.)

I believe that 65D watches for the falling edge after the index hole passes. In theory, it waits some period (1 ms?) and then begins writing. I know there were compatibility issues between old disks and later versions of OS65D because originally there wasn't the delay ACIA would miss the first character sometimes and cause the read to fail.

I'm trying to remember what else is on the track with the directory. I know that when I was thinking about this a few years back, that was the track that gave me the most heartburn.

The timing on the disk sectors are also quirky. They have to leave enough room before they start to write a second or third sector to make sure they don't clobber earlier sectors. Those delays are why you can't really fit 8 sectors of 256 bytes on a track.

I don't think OS65D would care if you "stretched" the interval between index hole pulses. I'll look at the disassembly, but I think it just watches for the pulse, resets the ACIA to clear any garbage, and then starts reading. On writes, I think you can "wrap around" and be recording through an index hole pulse (event though that is a really, really bad thing) while you write a sector. (And I think writing 8 sectors of 256 bytes does exactly that.)

I'll dig a bit deeper into the disassembly. I would worry that if you up the transfer rate too much you are going to have trouble on "real" (non-FPGA based) systems because the processor won't be able to handle things fast enough on a 1 MHz machine like a C1P or older C2-4Ps would have. So I would tend to say stretch the index hole pulses out and keep the transfer speed the same if you are emulating things.

But that does also get at another issue. Most C4P MFs had 24 kilobytes from the factory. If you doubled the data per track, you also have to increase the size of the disk buffers. (I don't know if you've done that before. There was a BASIC program you had to run that asked you some questions, would poke the right values into the right locations, and create one or two buffers & some extra space if you wanted. Once you ran that program, you had to start your new program that made use of the buffers. The buffer or buffers were not "automatic".) If you start looking at something like 16+ kilobytes for DOS, Page Zero, etc. and then add on say a double sized buffer of 4 K you have eaten up 20K of your 24K of memory.

It would be better to increase the number of tracks. That would be a very easy patch (and fairly seamless since 8" machines had something like 76 tracks compared to the 40 on minifloppies). The track number is stored as a BCD value in places, so going from 0 to 99 tracks is not a problem. (I think there were actually modification on some later systems where double sided minifloppies were used and tracks 40 through 79 were the flip side. I'm not sure if that was a commercial product or not--I did work for the dealer and MA-Com had some cool ideas before the IBM PC overtook them. Converting the C4P to networked workstations on a C3 system was one of those ideas. It is long enough ago now that there are things I know were discussed or even advertised but that never made it into commercially available products.)

I'll admit that something like a 100 track emulated drive with a slightly patched OS65D and some changes so there was only a single sector (ranging in size from 256 bytes up to 2K) seems like a fairly manageable project. It would only require patching for the highest track number and patching for anything that uses a second sector on a track. (And the multiple sectors per track isn't unacheivable--it just seems to add complexity. Like I've mentioned before, I'd rather get something working quickly and then build on that. But that's just my approach to things.)

I'll do some digging on the OS65D code and refresh myself on the track and sector structure the OS itself used.

Thanks,
Jim

dave
Site Admin
Posts: 561
Joined: Tue Sep 09, 2008 5:24 am

Re: Floppy Emulation for the C1P/C4P

Post by dave » Fri Jul 07, 2017 6:33 pm

A serial protocol could pretty easily encapsulate the current interface.

The protocol would involve sending a packet, waiting for a response:

The API would be to all a routine with COMMAND, OUTPUT BUFFER, INPUT BUFFER, ACK length

send: <command, data, crc>
receive: <ack, (data), crc>

One general routine could handle this. Then, search for index hole would translate to a serial request <INDEX> and would reset the server to point to data from the beginning of the track.

<CHECK TK0> would prompt the server to return a 1 or 0
<DEVICE n>, <SIDE m> to select different drives and sides.

The various PIA control code to step in, step out, raise head, etc. would be replaced with serial commands.


ACIA data reads / writes could be replaced wither with byte operations, or whole track/sector read/writes:

Simply replacing the hardware operations with server commands/queries should be fairly straightforward, and any code that uses 1 large sector or multiple small sectors per track would just work.

Since the disk read/write code is fairly segregated, the patch should not be huge. In fact, it may be possible to use mark different devices as real or emulated and call the appropriate code, without much patching at all.

A server could be written in python or whatever, and operate on winOSI (or another standard) disk images.

Actual timing would not be an issue, as long as the serial rates are within the capability of the OSI. For 250K, the serial code would have to be quite tight.

Dave

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

Re: Floppy Emulation for the C1P/C4P

Post by w4jbm » Sat Jul 08, 2017 3:25 pm

A while back I started thinking through the definition of what would amount to a series of calls you could build a DOS around. At that time I was thinking I wanted something flexible enough to be used on new 6502 projects as well as to retrofit into the C4PMF with OS65D. I never made it far, but here were some of the calls I wanted to implement on the server side. Then all or any desired subset of these could actually be implemented on the machine.

_RSET Reset. Clears all drives.
_RDY Ready. Two way handshake that indicates that DOS and the disk system are ready.
_BOOT Boot. Passes a memory address for a boot "track" which can be any length points to and then executes at that address. (Alternatively, the boot strap image could provide the address. Also, instead of executing at the start, an alternate address could be specified. Finally, support for multiple boot "images" could be provided with the image number specified.)
_STRT Start Up. Mounts default volumes to A, B, C, and D drives.
_VDIR Volume Directory. (Returned as text file?)
_VMNT Volume Mount. (Mount specified volume to specified drive. Can mount as read only.)
_VLBL Volume Label
_VCPY Volume Copy
_VFMT Volume Format. Effectively deletes all files on the selected volume
_VLIB Volume Library. Provides a list of all Volumes available by name or other identifier. (Support for comment field.)
_VSTT Volume Statistics. Provides various statistics such as highest Volume available.
_SWD Set Working Drive. This sets the default drive (A, B, C, or D) that will be used when no drive is specified.
_SAVE Save BASIC program. (With support for other languages?)
_LOAD Load BASIC program. (With support for other languages?)
_GET Load a memory block with data from disk. (Address saved, but could be overridden?)
_PUT Save a memory block to disk along with the address the block was originally located at.
_FCPY File Copy
_FDEL File Delete
_VCHK Checks the health of volume.
_BKUP Backup. Can backup all or selected volumes.
_DATE Date. Returns current date.
_TIME Time. Returns current time.
_DBUG Debug. Enters a debug entry into the log file on the serial data server.

That was very much a work in progress that was never refined. But it does seem that one challenge for people building 6502 based systems from scratch has been the lack of a consistent DOS to build around. (With the Z80, you know it is a flavor of CP/M. The 6809 has FLEX and OS-9. There are a few different DOSs for the 6502 but nothing particular stands out--in Europe there was a drastically modified rewrite that seems to have used OS65D as a starting point because it could be purchased separate from hardware.)

I never got to the point of thinking about the more primitive features like track and sector addressing.

There isn't really a point in all of that I guess besides the fact that the server side could be much more feature-rich than necessary so that programs could call those features through some mechanism other than traditional OS65D.

I had at one point envisioned two separate projects--one would be a boot loader that would just always say you were at track zero, send index pulses, and then send a stream of serial data that included the bootstrap. It would just set an run continually, even after the machine was booted. But it would basically be ignored at that point.

Then the second project would be the serial based disk system. The patched bootstrap would basically hand off to this so the normal drive mechanism would be ignored.

That would mean no hardware modes unless you wanted them. Patches to the OS would be needed. Interfacing to an FPGA implementation through a serial port would be easy. Even non-disk machines could be booted if you had some bootstrap mechanism that used BASIC or the built in monitor and a bit of code to load and start things.

Thanks,
Jim

dave
Site Admin
Posts: 561
Joined: Tue Sep 09, 2008 5:24 am

Re: Floppy Emulation for the C1P/C4P

Post by dave » Sat Jul 08, 2017 5:10 pm

If you haven't already looked into it, Rich Leary's DOS/65 is a very nice, cleanly written, well documented CP/M-like OS that is highly portable. It already runs on OSI systems, and could be easily ported to a hosted serial protocol.

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

Re: Floppy Emulation for the C1P/C4P

Post by stm » Sun Jul 09, 2017 11:46 am

dave wrote:
Sun Jul 02, 2017 1:00 pm
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.
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.
C1P Model 600 CPU 1978 REV B, 40K (8K original and 32K BillO memory expansion), RS-232
Maintainer of cc65 OSI target

Post Reply