On Tuesday, August 9, 2022 at 2:52:09 PM UTC-5,
muta...@gmail.com wrote:
> On Wednesday, August 10, 2022 at 1:32:26 AM UTC+8,
s_dub...@yahoo.com wrote:
> > On Thursday, August 4, 2022 at 9:36:39 PM UTC-5,
muta...@gmail.com wrote:
> > > On Thursday, August 4, 2022 at 10:04:54 PM UTC+8, JJ wrote:
> > > > On Wed, 3 Aug 2022 15:36:27 -0700 (PDT),
muta...@gmail.com wrote:
> > > > >
> > > > > Hi 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.
> So far in pdos I have not attempted or needed such a concept.
> > >
> > > If someone types:
> > >
> > > rm -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.
> > > > Serial 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!
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.
> > > Specifically 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