Post by ***@gmail.comPost by ***@gmail.comPost by JJPost by ***@gmail.comHi JJ. Thanks for your thoughtful response.
Do you think, with the benefit of hindsight, there should have been a
mechanism for what we now know as host file access?
It would be nice, but don't you think it's too late for that?
No. I am trying to extract philosophy.
If you think this would be nice, then what
would you propose exactly?
And could this have been figured out decades ago?
Or was something missing?
At the same time you can solve the problem of
people in real life, for years, taking their chances
with line noise. Before error-correcting modems.
Does error-correction belong in modems or applications,
as happened in real life?
Or does it belong in the os?
Here is where a driver for the device is useful. The OS should only get notification of device error.
The driver for the device would be the place to attempt error correction, at the least, return a fail status to the OS.
Ok, good point. I don't really understand drivers.
Think 'Device Control'. A device driver is the controlling code for the device, that is, the device specific code.
Post by ***@gmail.comSo far in pdos I have not attempted or needed such a concept.
Post by ***@gmail.comrm -fr /scratch
And line noise of "enter" happens after
the "/", who failed to think things through?
The shell. It's design fails to catch that and issue a warning and a confirm request, istm.
Your example uses the keyboard to communicate to the console through the 'shell'.
Very early on, before the ibm pc this was handled through the i8255, with the pc this changed.
reference note of modes of operation..
https://en.wikipedia.org/wiki/Intel_8255
The OS kernel should not have to deal with these low level details, a specific driver should handle it.
Same with error detection and attempted correction. It should be handled by the specific driver.
So for example, if an app does an fseek of a com
Port to an earlier position, what I want is for the com port
to be reset, which Bochs detects and does a rewind
of the host file, then reads done from the com port to
get to the right position. That is something that would go
into a driver?
Yes. Bochs has provided a driver for you.
From your description, Bochs is treating the COM: as a rewindable Mag Tape device, by chance.
Generally though, COM: has a device attached that is not rewindable.
A Modem, paper tape reader RDR:, paper tape punch PUN:, a console, provide a data stream that is not rewindable. (A limited cheat would be to write the input stream to a temporary file, and perform the seek on the temporary file. The temp file would need to be in fast memory, a huge ring buffer basically).
Each of these devices require code specific to the device, a device driver.
Post by ***@gmail.comPost by ***@gmail.comPost by JJSerial port is
now considered as a legacy (but not dead yet) communication port. It's no
longer in development and it's no longer widely used except in industrial
and business fields. What's your intended use case scenario for it, anyway?
Host file access is what I am after right now.
What is this 'Host'? Bochs? -- or are you calling your OS the host? -or- ?
I am running pdos under Bochs on an Android phone.
Pdos is the guest os and the android is the host.
I thought this was standard terminology?
It is, but I didn't see mention of Android.
I didn't know you could do what you're doing on the Android phone. Kudos to you!
Post by ***@gmail.comPost by ***@gmail.comPost by JJCause I could think that it's for a special use case only.
I'm more interested in the philosophy of
external communication.
You develop in C I think, so dig into the topic of streams.
-- It's likely you have, forgive me for being a dunce.
In addition to stdin, stdout, stderr, you could add stdtmp where stdtmp is a file already in an opened state, like the others, to catch COM1: input stream through the stdtmp driver.
I don't have a problem at this level.
For the purposes of this conversation I am happy
to do an fopen of com1 r+b
The hard part is determining End Of Transmission.
For normal com port usage I would rely on the
Bios timeout. When I am accessing a host file,
I expect Bochs to give a timeout at EOF.
Perhaps the stdtmp driver has a time-out function to catch EOT.
When the simplest protocol is the case, where COM1: just takes byte data, no control bytes are allowed to be embedded. The risk of errors is low if stored in memory, or a thumb-drive.
The risk is high if the device is slower than COM1: such as a floppy drive.
Early on, all devices were slow, so some form of transmission protocols were developed.
So think in terms a byte being converted into two bytes, each an ASCII nibble.
Prepend some ascii info and trailing check sum and you have a Intel .HEX record.
https://en.wikipedia.org/wiki/Intel_HEX
Since ASCII HEX restricts bytes into the printable range, bytes outside this range can be used for control.
For example, 07h aka byte value 7, where value 7 is not printable if handled by the console.
But causes the console to 'beep'.
The ASCII form of 07h is 30,37.
Post by ***@gmail.comPost by JJPost by ***@gmail.comThe method above, abusing the hardware, is not the only
method I have used. My pdos-generic code is already capable of
this, but relies on a cooperative bios.
That's expected, since it's not part of the standard specification. Though,
BIOS modification is not actually required, since what's needed can be
implemented as a TSR/driver which hooks BIOS functions; unless you want it
to work even without an OS.
I'm interested in changing the bios specification.
Within the limits of the old computers.
Or close.
Are you talking about IO.SYS or RomBios?
I'd say the IO.SYS is the walkway into the RomBios, perhaps the minimum io functions handler.
Either will do the job from the point of view
of the os. Which leads to another question. Someone said
that what I am calling an ideal bios or pseudo-bios
is actually a hardware abstraction layer.
Does that sound right?
From what I am envisioning, yes, but the existing RomBios is that.
The lowest level is dealing with i/o ports, each device has its range of i/o ports.
You can control a device directly by programming using the port addresses of the device, but this isn't done normally. The OEM, say Dell, engineers this assignment, which likely changes from model to model.
We are talking Legacy systems here. Query 'Southbridge' chip.
https://en.wikipedia.org › wiki › Southbridge_(computing)
https://www.computerhope.com/jargon/s/soutbrid.htm
The next level up, the RomBios, is the HAL and it provides the consistent way of access.
INT 10h functions for the display .
INT 16h functions for keyboard.
INT 13h functions for disk drive access & control/status. Sub-functions AH=41h, 42h, 43h for Extended Disk Drives ie. LB addressing.
The next level up is the Bios, which resides in the OS, IO.SYS if you will.
This part is most likely to change on porting the OS to different, non ibm, hardware platforms.
Post by ***@gmail.comPost by ***@gmail.comSpecifically I am after fopen of 0x80
At first glance I saw fopen port 80, the http port, but you have written 80h.
The first hard disk. Being opened as a stream.
That's what I want the bios to provide.
Ahh, you are after low-level access to the HD??
Likely it supports Logical Block addressing, Extended Disk Drive functions.
Check EDD supported thru int 13h fn 41h.
Fns 42h Read, 43h Write.
NOTE!! This is not safe to do. Any write changes would/could destroy the file system on the HD
I have used a thumbdrive for hobby os work. The host is linux debian.
I boot it thru USB boot option, which treats the thumbdrive as HD 80h.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
o /dev/sdb --verify this addresses the USB Thumb drive!
o /dev/sdb1 --if so, then this addresses the first partition.
o Tranfer image to Thumb Drive:
su
********
# dd bs=512 seek=1 if=hobby-os.bin of=/dev/sdb1
104+1 records in
104+1 records out
53681 bytes (54 kB) copied, 0.00825874 s, 6.5 MB/s
This discussion pertains to Real Mode programming, Protected Mode is a different thing.
Steve