• Please review our updated Terms and Rules here

Using BDOS calls to read & write to disk

bakemono said:
I wrote a CP/M client program to fetch files from a (PC) server over serial. It takes the filename from the command line, opens a new file, sends the name over serial, then receives the file using plain xmodem or a variant with 256-byte blocks and 16-bit checksum. Each block is written to disk as it is received.

It uses the Z280 serial port and contains some Z280 instructions, but might still be a useful reference for your project. It also contains my notes about how BDOS calls work, since I sometimes like to have documentation handy within my source file when I'm writing code. http://www.hyakushiki.net/misc/zget.no
Click to expand...
Oh, I will be sure to grab a hold of that, even if it is something I can use for notes and suggestions. Thanks
 
MykeLawson said:
As for the worry of dropped bits & bytes; I'm going to start out slow, with something like 9600 baud.
Click to expand...
Handshaking is there for a reason. It works, and you should utilize it. If "everyone" is basically blocking on I/O, then the handshaking will let you read/write/stream "as fast as practical". As long as your UART buffer can keep up (i.e. with a very high baud rate), you should be fine.

Are you writing this in assembly? Are you doing that on purpose? You could probably knock this out in Turbo Pascal or any of the C implementations quite quickly.

Again, with handshaking, "efficiency" is less of an issue. While TP or C will have their core loops slower than assembly, this is going to be dominated by the disk and serial I/O, so any inefficiency introduced by using a higher level language will be mostly moot. At a minimum, it's an easy way to prototype at a high level before you fall into the bowels of assembly.

But, please, get hardware handshaking to work -- it will make your life much easier.
 
whartung said:
But, please, get hardware handshaking to work -- it will make your life much easier.
Click to expand...
Which comes back to driving the serial port manually - CP/M does not understand or support hardware handshaking (at least CP/M 2.2 doesn't). Hence my comment that 9600 bps is actually considered fast.

This is the primary reason why XMODEM utilities for CP/M require the user to manually customize them for their particular system, and this is also why I brought up the issue that even checking for available data is something CP/M (again, 2.2) cannot do.

Myke has to decide what system(s) to target, and that's it. But all of that can happen later, after he got familiar enough with the system to handle the basic functionality (such as reading and writing files, which is pretty fundamental).
 
Svenska said:
Which comes back to driving the serial port manually - CP/M does not understand or support hardware handshaking (at least CP/M 2.2 doesn't). Hence my comment that 9600 bps is actually considered fast.
Click to expand...

It doesn't? I thought that was a BIOS related issue rather than a CP/M specific related issue? ie, it was left to the BIOS? Even the ZX Spectrum supports this, with a "software" uart.

And isn't hardware handshaking independent of the OS? Some chips like the 16c750 support it - and IIRC, the 16c550 might as well. It's just a setup option in the UART config. Even the PC serial supports hardware handshaking with the 16c750 in place of a normal UART IC. You just need to turn it on.
 
CP/M does not understand or support it, no.

If the BIOS implements it, it does so "behind CP/M's back",
because CP/M simply does not understand or support it.

Also, fully automatic handshaking requires the UART to have a FIFO,
and using a 16C750 as an example in a CP/M context is just ... well.
Inappropriate.
 
There was not standard interface for S100 serial port cards. Different addresses, different interrupts, different methods for setting the parameters. CP/M couldn't be designed to work with what isn't there.
 
whartung said:
Handshaking is there for a reason. It works, and you should utilize it. If "everyone" is basically blocking on I/O, then the handshaking will let you read/write/stream "as fast as practical". As long as your UART buffer can keep up (i.e. with a very high baud rate), you should be fine.

Are you writing this in assembly? Are you doing that on purpose? You could probably knock this out in Turbo Pascal or any of the C implementations quite quickly.

Again, with handshaking, "efficiency" is less of an issue. While TP or C will have their core loops slower than assembly, this is going to be dominated by the disk and serial I/O, so any inefficiency introduced by using a higher level language will be mostly moot. At a minimum, it's an easy way to prototype at a high level before you fall into the bowels of assembly.

But, please, get hardware handshaking to work -- it will make your life much easier.
Click to expand...
Oh, assembly all the way. Heck, I even fiddle with changing 8080 assembly mnemonics to Z80 so I can under it better. And yes, once I get something basic working, then I'll move to some hardware handshaking, then on to x-modem and see how fast I can push it.
 
You are going to do flow control even if you don't want to. You don't have an infinite buffer.
You can do it byte by byte (CTS/RTS) or you can do it by sending in fixed blocks with an ACK to signal go ahead.
Your disk IO occurs in the gaps when the serial is blocked or between ACK/GO ahead signals.
IMHO fixed block data with ACK is the easiest to implement.
 
I got the feeling Myke simply wanted to transfer in one continuous block until the file was sent, and store it in RAM.

Though it would be cool if he hooked this into the BIOS and let the computer request files over the serial connection, like a RS232 file share :)
 
Small packets with an acknowledge (like XMODEM) are the way to get simple flow control with limited risk of overwhelming the receiving end..
I used it to send files from the PC to the Exidy Sorcerer and Kaypro. I did use the hardware registers directly, the BDOS is only used for creating the file(s).
In the attachment my simple xmodem receive program for the Exidy.
 

Attachments

cj7hawk said:
I'd also recommend this series:


It's an old article called "Sliding Into BDOS the Smooth and Easy way" - and it provides enough to write your own CP/M software from scratch. The code examples are in 8080, but someone converted Part 1 to z80 here ( in six segments ) : https://www.msxcomputermagazine.nl/mccm/millennium/milc/disk/topic_13.htm
Click to expand...
Thanks for the link. Every littel bit of knowledge makes one write better code. My past code has been mostly standalone with minimal CP/M interaction. This new program will use CP/M to the fullest extent I possibly can.
 
gertk said:
Small packets with an acknowledge (like XMODEM) are the way to get simple flow control with limited risk of overwhelming the receiving end..
I used it to send files from the PC to the Exidy Sorcerer and Kaypro. I did use the hardware registers directly, the BDOS is only used for creating the file(s).
In the attachment my simple xmodem receive program for the Exidy.
Click to expand...
I'll keep this for when I migrate the code to use x-modem to get the data from the other machine and onto the one running the code that will save it to the disk. Thanks
 
MykeLawson said:
Well, this looks exactly like what I want to do. So much so that I just bought the book from eBay. I'll be looking to convert to Z80, tweak a bit, and make it part of my routines. Thank you

View attachment 1311289
Click to expand...
Hmm, that does not look at all correct, intuitive, or as simple as it should. I'll throw together something simple and let you adapt it to your needs. I'll use Intel mnemonics.
 
Here's a fairly simple example. Just enough to make it working code as-is. This program basically writes itself to whatever file you specify on the command. It writes the first 10 records from 0100H, which includes the program itself and whatever is left-over in memory after that. (remove the ".txt" suffix from the file, obviously)
 

Attachments

durgadas311 said:
Here's a fairly simple example. Just enough to make it working code as-is. This program basically writes itself to whatever file you specify on the command. It writes the first 10 records from 0100H, which includes the program itself and whatever is left-over in memory after that. (remove the ".txt" suffix from the file, obviously)
Click to expand...
Thanks Doug. Between all the stuff and info you all have provided, this seems like it will go a whole lot easier than I ever expected. I'll probably start fleshing the whole routine (save side at least) real soon.
 
MykeLawson said:
Thanks Doug. Between all the stuff and info you all have provided, this seems like it will go a whole lot easier than I ever expected. I'll probably start fleshing the whole routine (save side at least) real soon.
Click to expand...
Well, the coding has begun..... Just a bit of framework for now; but it's a start... Yea, I liked 'Wargames'....
 

Attachments

You must log in or register to reply here.
Back
Top