Physical drives & RAM drives.

[danielbooneamerica]

I am writing a RAM disk driver and have been researching a question I had while working on this project.

Looking at legacy drivers creating RAM disks on TRSDOS 6 each of them requires their own format program. I am curious about that.

To me if you (or me) were developing a RAM disk driver, we would want it to resemble standard hardware storage as closely as possible. Then you could use existing tools like format on this storage. I would think format would not need know it if it were talking with real hardware or simulated.

It seems even with RAM drives we could simulate things like SEEK, SELECT, STEP, TSTBSY etc.

But looking back, it does not seem it is ever done this way.

I guess that is part of my question; if driver is written correctly, why would tools like format and disk editor made for physical drives not work with virtual drives?

Just curious if others have thoughts about this or tried writing a more universal driver?

 

[Chuck(G)]

Oh, you could do it with a RAM drive--it's a matter of implementing the IOCTL call for formatting. But it's not worth the trouble, generally, which is why it's not done.

 

[danielbooneamerica]

I am working in IOCTL code area right now. Can you elaborate why IOCTL is considered a lot of trouble?

am not sure it is needed as it is now exists. One thing is RAM DISK driver will never have to handle interrupts etc.

I mean on model 4 the CPU is both HOST & HOST ADAPTER so it handles some timing and interrupts but as a RAM drive you dont have any of that so that makes it a little simpler.

 

[Chuck(G)]

Oh, you're not talking about the x86 Tandy systems. My bad. Nevermind.

 

[gp2000]

The format command uses the "write track" interface of the floppy driver. It pretty much constructs an entire track itself and the driver does little more than feed it to the floppy hardware. Your RAM disk driver would have to interpret what the WD17xx controller expects. That'd be pretty cumbersome to program and of little benefit to the user as you'd have to give them specific instructions on what geometry to enter. Easier for everybody just to have a special format program.

I believe hard drives need their own format program, too. It wasn't an area of the operating system that had been abstracted.

It might be that a sector editor will work with a RAM drive but I don't know for sure.

 

[danielbooneamerica]

Hello, I guess short answer is nobody knows why format will not work across all different drive types or why they didn't make it that way anyway.

Really, a drive driver has no functions we should not be able to fool format program into thinking exists. So far on my network I can access files on PC from TRS80. These files are not inside a dsk file on PC but TRS80 directly reads and writes in PC directory.

I also want to add a dsk type file to project and that will require format. This dsk style file will reside on PC and formatted from TRS80. It would be nice to use existing format program simply because it exists, tried and proven etc. Of course its capacity would prevent it for being useful for mass storage.

I have been looking for a development forum for trs80 but that dont seem to exists.I am not sure how many programmers are still developing software, drivers, games etc but be nice if we had our own forum.

Stay tuned and I hope to share these drivers once bugs are out.

I have (Z)LSDOS running on a 50mhz eZ80 and works nicely. Very fast.

I am looking for folks that can CAD some boards for me if anyone interested. Due to COVID, it is difficult for me to continue with same engineering group in India I had been using .

If your interested in TRS80 networking HMU.

thanks guys