[Freedos-user] Support for 4k byte sectors

2012-01-10 Thread Bertho Grandpied
Hi FreeDOS users and developers ! This is my first time posting to these lists, I hope I'm not breaking etiquette in the act. My question/request is about accepting larger sector sizes for hard disks (whether ATA, USB or otherwise connected). USB disk appliances presenting 4k sectors only - no

[Freedos-user] Re : Support for 4k byte sectors

2012-01-14 Thread Bertho Grandpied
Dear Freedos-user List ! On Tue, 10 Jan 2012 19:00:30 + (GMT) I wrote : > Hi FreeDOS users and developers ! > This is my first time posting to these lists, I hope I'm > not breaking etiquette in the act. It's been a few days and I'm surprised my first mail hasn't been acknowledged in any wa

[Freedos-user] Re : Support for 4k byte sectors

2012-01-14 Thread Bertho Grandpied
Hi, Bernd! >> should I try posting to the "kernel" or "developers" lists instead ? > Truth is we're not sure, this 4K sector size thing comes in several  > versions: > 1) emulation with aligned 512byte sector emulation > 2) emulation with non-aligned 512byte sector emulation > 3) native 4K (espec

[Freedos-user] Re : Support for 4k byte sectors

2012-01-15 Thread Bertho Grandpied
On Sat, 14 Jan 2012 "Michael B. Brutman" wrote : > As far as 4K blocks go, I wouldn't worry about it too much.  512 byte  > sectors will be supported either natively or by emulation in the drive  > itself for a long time to come - at least 5 to 10 years.  Too many  > existing systems depend on a 5

Re: [Freedos-user] Re : Support for 4k byte sectors

2012-01-15 Thread Bertho Grandpied
Eric Auer wrote : > Interestingly, even 3 TB disks are still sold with 512 byte sectors. Conversely, even 1 TB USB disks are already sold with 2048 byte sectors ;=) (...snipping much...) > By the way - a DRIVER could interface with any disk with any sector size and then just provide an int13

[Freedos-user] Re : Support for 4k byte sectors

2012-01-15 Thread Bertho Grandpied
In reply to : "Michael B. Brutman" Michael, > So the bottom line is that DOS will probably work just fine > when > natively attached to storage devices, and that will work > for a long > time.  "Appliance" storage devices are going to break > that if they can't > emulate 512 byte sectors.

Re: [Freedos-user] Re : Support for 4k byte sectors

2012-01-15 Thread Bertho Grandpied
In response to : "Bret Johnson" Subj : MSDOS - increasing max sector size ... > Likewise, it will "ignore" disks with sector sizes larger > than what DOS says it can handle (this particular detail is > part of the easily accessible DOS "List of Lists").  In > the source code for USBDRIVE (starting

[Freedos-user] Re : Support for 4k byte sectors

2012-01-15 Thread Bertho Grandpied
New follow-up ! In response to : "Bret Johnson" Subj : MSDOS - increasing max sector size quoting myself (sorry!) : > According to Rudolf Loew, increasing maximum sector size in LoL of an > unpatched MSDOS will work up to 2048 byte sectors, not 4096 :( I have > not verified it for a fact. Wow

[Freedos-user] Re : Support for 4k byte sectors

2012-01-15 Thread Bertho Grandpied
> Hi Bret, Not Bret, but I'll provide answers to 2 of your points. > BPB CHS geometry differs - but does a disk with 4096 byte > sectors allow CHS based access at all? I hope it does not. you can't preclude it, it may for compatibility sake (at the int 13h interface). (big big snipping) > B

[Freedos-user] Re : Support for 4k byte > sectors

2012-01-17 Thread Bertho Grandpied
In reply to : Eric Auer > Hi Bertho, trying to reiterate / re-explain my plan / > idea: Fine ! >> a DRIVER could interface with any disk with >> any sector size and then just provide an int13 or int25/26 interface >> with 512 byte "sector" size for data transfer to DOS. > As explained in a lo

[Freedos-user] Re : Support for 4k byte sectors

2012-01-18 Thread Bertho Grandpied
In reply to : Eric Auer Realising I left away this point of your previous msg : >> Someone, maybe not Eric, asked what I have been using for accessing >> USB mass storage in DOS. Answer : a version of Panasonic's >> USBASPI.SYS. This allows access to 4k sectors using SCSI commands. > Interestin

[Freedos-user] Re : Support for 4k byte sectors

2012-01-18 Thread Bertho Grandpied
In reply to: Bret Johnson >> only support Intel/Via (UHCI) controllers yet. > True. Working on that. Great :=) >> I also think they have hard coded 512 bytes per sector. > No. USBDRIVE reads the maximum buffer size from the DOS List of Lists (as > discussed some earlier in the thread), and

[Freedos-user] Re : Support for 4k byte sectors

2012-01-25 Thread Bertho Grandpied
Just a note, Folks, /who/ said "advanced" format disks (presenting 512 byte sectors) are with us for ten years - or more, so we should be little concerned about having to support true 4K sector disks ? But I stumbled upon a couple pages that say otherwise : "the industry" has agreed to sell AF

[Freedos-user] USB/ASPI to DOS, 4K sectors.

2012-01-29 Thread Bertho Grandpied
Continuation of previous question, subj changed, was: "Support for 4k byte sectors" Leaving aside (Free)DOS kernel support for bigger HD sectors. Reminder : the following - should fit on one line - is a schematic of what is expected to work : Hard Disk -- USB (4K sectors) -- DOS with "usbaspi

Re: [Freedos-user] USB/ASPI to DOS, 4K sectors.

2012-01-29 Thread Bertho Grandpied
In reply to: Bernd Blaauw > Op 29-1-2012 12:21, Bertho Grandpied schreef: >> Hard Disk -- USB (4K sectors) -- DOS with "usbaspi.sys" (ASPI manager) -- >> "didd1000.sys" (ASPI to DOS converter) (...) >> The ASPI to DOS converter is the part that has

Re: [Freedos-user] USB/ASPI to DOS, 4K sectors - DOS ASPI specification in a nutshell

2012-01-29 Thread Bertho Grandpied
In reply to: Eric Auer >>> ... in vague terms, that most stringent "anti >>> reverse engineering" laws allow for independent fixes >>> and enhancements to IP protected code, but IANAL. > You can manipulate software to fix interoperability bugs afair. My understanding too. >> usually the cl

[Freedos-user] Re : Freedos-user Digest, Vol 581, Issue 2

2012-01-30 Thread Bertho Grandpied
Jeffrey wrote: > Are there any plans for adding a shell escape character(like \ in UNIX)  in FreeCOM? Left to be answered by those in the know... > If so, what character would be a suitable candidate? If so, I think compatibility to 4DOS should be considered. FYI and IIRC, 4DOS uses the Contro

Re: [Freedos-user] Escape character (reposted)

2012-01-30 Thread Bertho Grandpied
Reposting, reason : corrected Subject line. Apologies for my previous mistake, and for any inconvenience caused by double-mailing. Jeffrey wrote: > Are there any plans for adding a shell escape character(like \ in UNIX)  in FreeCOM? Left to be answered by those in the know... > If so, what ch

[Freedos-user] Re : Support for 4k byte sectors

2012-02-04 Thread Bertho Grandpied
Kenneth J. Davis wrote : "Improved support for sectors other than 512 bytes has been committed, I am still working on it, default support will still be for 512 bytes (currently not while testing).  I have tested 256, 512, 1024, and 2048 byte sectors with tdsk (currently my only way to test).  Usin

[Freedos-user] Re : Support for 4k byte sectors + TDSK

2012-02-04 Thread Bertho Grandpied
Hi, Guys! Replying to self, sort of, and Jeremy at the same time. I've been glancing thru the ram disk, TDSK, source. Internal buffer (used for init only) was provisionned for one 4K sector, but for some reason author(s) limited sector size to 2K, as specified on the driver's command line. I

[Freedos-user] Re : Support for 4k byte sectors + TDSK

2012-02-06 Thread Bertho Grandpied
On Sun, 5 Feb 2012 22:56-0500 Kenneth Davis wrote : > For testing only - warning may corrupt data!!! > https://www.fdos.org/kernel/testing/4K/ Got'm alright! For information, had to downgrade URL protocol to HTTP:// (from http per provided link). Not sure if it's a temporary problem at the se

[Freedos-user] Re : Support for 4k byte sectors + TDSK

2012-02-07 Thread Bertho Grandpied
On Sun, 5 Feb 2012, Kenneth Davis wrote : > test kernel supporting 4KB sectors, note it limits > buffers to 2 to avoid memory corruption on boot.   > Thanks for testing, Eager to try your kernel mods with real HW, but, there is a but! in order for my Iomega device to be recognised & proc

[Freedos-user] Re : Support for 4k byte sectors + PLoP

2012-02-07 Thread Bertho Grandpied
>  test kernel supporting 4KB sectors, note it limits > buffers to 2 to avoid memory corruption on boot.   > Thanks for testing, By an extraordinary coincidence - I am not making this up ! I received mail from PLoP's developer today, a short time after I had posted the following note to th

[Freedos-user] Re : Support for 4k byte sectors

2012-02-07 Thread Bertho Grandpied
In reply to: Mark Brown > you *could* try USBASPI.SYS /V /W > followed by DI1000DD.SYS This is what I tried first thing, and the DI1000DD.SYS ["Ninja ASPI DISK DRIVER Ver2.00", 16368 bytes, MD5=9C240A5F1848F76893364AB3A26D545F] which I use definitely /won't/ work with 4K sectors. > ( wor

[Freedos-user] Re : Support for 4k byte sectors + TDSK

2012-02-07 Thread Bertho Grandpied
This is correcting my mistake, --- On : Tue 2/7/12, Bertho Grandpied wrote : > In reply to: Mark Brown > > you *could* try USBASPI.SYS /V /W > > followed by DI1000DD.SYS   > This is what I tried first thing, and the DI1000DD.SYS > ["Ninja ASPI DISK DRIVER Ver2.

[Freedos-user] Re : Support for 4k byte sectors + PLoP

2012-02-07 Thread Bertho Grandpied
In reply to: Bernd Blaauw >Op 7-2-2012 15:05, Bertho Grandpied schreef: >> Also of note, PLoP's license has changed it is now free for use >> including >> commercial. Donations will be accepted still?. The question mark after the word "still" was un,intende

[Freedos-user] Re : Support for 4k byte

2012-02-08 Thread Bertho Grandpied
From: Czerno (aka Bertho Grandpied) To: freedos-users Cc: Eric Auer Hi Eric! On the freedos-kernel list, you voiced such opinion about the future of big sector disks: " that has low priority imho, as drives with large sectors are a temporary thing, will be gone with GPT parti

[Freedos-user] Re : Support for 4k byte sectors

2012-02-08 Thread Bertho Grandpied
Replying to Eric Auer > This refers to the following quote from an earlier 4 kB > related mail: >> I stumbled upon a couple pages that say otherwise : "the industry" >> has agreed to sell AF disks only *until the end of 2014*! > It was actually you yourself who said that on 25 Jan 2012 > ;-)

[Freedos-user] Re : Support for 4k byte

2012-02-08 Thread Bertho Grandpied
Hi Dennis! dmccunney wrote : > (albeit much of the additional space is lost slack at the user files level > ...) Slack space will be a real issue? I don't see how. There would be a net loss for partitions sizes and file systems comprised of less than 4K bytes per cluster. You are right,

[Freedos-user] writing a loadable block driver for 4k-sector drive (Questions)

2012-02-20 Thread Bertho Grandpied
Dear List... I'm calling back with respect to the 4k-sector USB disk drive. I'm considering writing a loadable DOS 'block' driver for it, as Eric Auer suggested. My experience with programming DOS driver is unfortunately more on the side of character devices than block, so, please bear with basi

Re: [Freedos-user] writing a loadable block driver for 4k-sector drive (Questions)

2012-02-21 Thread Bertho Grandpied
eb 2012 11:15:00 PST BretJ wrote in Freedos-user : > Bertho Grandpied wrote: >> Therefore my first interrogation is, what set of device header attributes >> - and associated functions, including IOCTL codes - must be present /at a >> minimum/ for letting DOS access the disk

Re: [Freedos-user] Virtual floppy change problem

2012-05-20 Thread Bertho Grandpied
--- On : Sat, 19 May 2012 15:43:57 -0700, Jack <...@earthlink.net> wrote : > Given the "high level of responsibility" [Ha-Ha!] taken by the > VirtualBox creators, it looks as if I will have to add another > UIDE switch, that disables diskette caching regardless of what > its other switches tell i

Re: [Freedos-user] Virtual floppy change problem

2012-05-20 Thread Bertho Grandpied
Replies to Jack /and/ to Ralf follow in sequence. Jack, >> On REAL (old) PC hardware, the existence of floppy disk changelines is >> not guaranteed [] > My design goal for UIDE/UIDE2 was to write a driver that uses as FEW > "DOS system calls" as possible.At present, UIDE/UIDE2 are mor

Re: [Freedos-user] Virtual floppy change problem

2012-05-20 Thread Bertho Grandpied
--- En date de : Dim 20.5.12, freedos-user-requ...@lists.sourceforge.net a écrit : > De: freedos-user-requ...@lists.sourceforge.net > > Objet: Freedos-user Digest, Vol 636, Issue 2 > À: freedos-user@lists.sourceforge.net > Date: Dimanche 20 mai 2012, 22h41 > Send Freedos-user mailing list >

Re: [Freedos-user] Virtual floppy change problem

2012-05-20 Thread Bertho Grandpied
> From: "Ralf A. Quint" > At 02:45 PM 5/20/2012, Bertho Grandpied wrote: >>Case in point : unless explicitly excluded, MS-not-so-Smart-Drive >>will happily cache certain RAMdisks (not MS ramdrive) > What ramdisks would that be? Your question is challenging my m

Re: [Freedos-user] Virtual floppy change problem

2012-05-21 Thread Bertho Grandpied
Reply to Ralf A. Quint (2012-05-21 00:45) >Bertho Grandpied wrote: >>Raises the question of what a Ramdisk should do in order to >>"properly" identify itself to smartdrv... impersonate MS-RAMDRIVE, maybe ;=) > For starters, use a media descriptor byte value of 0xFA

Re: [Freedos-user] Virtual floppy change problem

2012-05-23 Thread Bertho Grandpied
On Wed, 23 May 2012 09:22:03 Jack <...@earthlink.net> wrote : > Subject: Re: [Freedos-user] Virtual floppy change problem > You are WRONG, Tom!! Is he ? or are you being RUDE, Jack ? > UIDE has NEVER ignored if a diskette has change-line support!   It > does in fact check the BIOS data table at

Re: [Freedos-user] false info on the freedos home page?

2012-09-19 Thread Bertho Grandpied
Hi ! On Tue, 18 Sep 2012 15:29:38 -0500, Rugxulo wrote: > MS-DOS / Win9x forced you to install in the very beginning > of the hard drive.  Uh ? What have you been smoking ? (smile)... MS-DOS will happily install to any primary partition on the first HD - and boot itself from the standard MBR, n

[Freedos-user] command.com (Freecom) main environment location

2013-07-04 Thread Bertho Grandpied
Hi List ! I've seemed to notice Command.com locates its master environment block at the top of conventional memory, just under the video (and under a BIOS defined extended bios data aka EBDA, if any). Is this behaviour user-controllable with some switch while loading FreeCOM ? Or otherwise,

Re: [Freedos-user] command.com (Freecom) main environment location

2013-07-04 Thread Bertho Grandpied
On Thu, 4 Jul 2013 21:08:12 +0200 Tom Ehlert wrote : >> I've seemed to notice Command.com locates its master environment >> block at the top of conventional memory >> Is this behaviour user-controllable with some switch while loading >> FreeCOM ? > what would be the purpose to change this ? w

Re: [Freedos-user] command.com (Freecom) main environment location

2013-07-05 Thread Bertho Grandpied
In composing this reply from the terrible Yahoo! web mail, I'll be trying to /force/ hard end-of-lines, not "flowed" lines, at long last! fingers crossed. On Thu, 4 Jul 2013 dmccunney wrote: > Placing the environment at the top of conventional memory is what > MS-DOS COMMAND.COM did, and Free

Re: [Freedos-user] command.com (Freecom) main environment location

2013-07-05 Thread Bertho Grandpied
Hi Tom ! >> I'm surprised you have to question this! >after ~12 years without anybody complaining, I'm surprised about you complaining. How many users do you have ? Of these, how many understands this level of detail, /and/ in addition, will care ? Methinks you were p.ssed off by my remarks,

[Freedos-user] Fw : (Q) recommended way to reliably check for FreeDOS vs. AnyDOS ?

2013-07-05 Thread Bertho Grandpied
receiving 2 or more copies, in advance of which I send my most sincere apology. --- On Thursday, 7.4.13, Bertho Grandpied a wrote : > Objet: (Q) recommended way to reliably check for FreeDOS vs. AnyDOS ? > Programmers, Kernel people, hi ! > > What is (are) the recommended way(s) t

Re: [Freedos-user] command.com (Freecom) main environment

2013-07-05 Thread Bertho Grandpied
On Fri, 5 Jul 2013 15:45:34 GMT "Bret Johnson" Hi Bret ! (long time, no see...) >> ... a user who is able, one way or another, to have usable RAM >> mapped above the 640 k so-called limit into the "video memory' >> segments, up to 736 k (B7FFF), will be forced to use the added >> memory as "UMB

Re: [Freedos-user] command.com (Freecom) main environment

2013-07-05 Thread Bertho Grandpied
Hi Eric, > this thread seems to mix two topics: Yep, things got mixed, I suppose it's my fault. Consequently I'll try to leavo out - not quote - the bits which, though they may be interesting, I think irrelevant herein (snip...) > As Tom already pointed out, the location of the > master env i

Re: [Freedos-user] command.com (Freecom) main environment

2013-07-06 Thread Bertho Grandpied
Guys... Casually peeking at Freecom source, branch MAIN, init.c v 1.31, Freecom's rev 1.31 (Excerpt, from Sourceforge CVS, w/ line numbers) [code] 437 env_resizeCtrl |= ENV_USEUMB | ENV_ALLOWMOVE | ENV_LASTFIT; 438 if(forceLow) 439 env_resizeCtrl &= ~ENV_USEUMB; 440

Re: [Freedos-user] command.com (Freecom) main environment

2013-07-07 Thread Bertho Grandpied
"Bret Johnson" wrote : >From my perspective, whether the XBDA, master > environment, or anything else is at the top of memory > instead of the bottom shouldn't make any difference, as long > as there's an MCB to identify and "protect" it. I see... following a very famous lead, you think that 640

Re: [Freedos-user] command.com (Freecom) main environment location

2013-07-07 Thread Bertho Grandpied
Tom, >> How many users do you have ? > I have no idea - and don't care. >> Of these, how many understands this level of detail, /and/ in addition, will >> care ? > answering this question would imply that /you/ understand the problem. > you don't. Now, is that not arrogance ! This kind of rem

Re: [Freedos-user] command.com (Freecom) main environment location

2013-07-08 Thread Bertho Grandpied
Hi, Eric Auer ! > PS: XBDA and moving it is not necessarily trivial. Our EBDA mover is working flawlessly AFAICT.Old code of mine actually, written for MSDOS 5+ before MS introduced the switches=/E option (or before I was aware of the switch?). Last week when I had discovered that the respecti

Re: [Freedos-user] command.com (Freecom) main environment location

2013-07-08 Thread Bertho Grandpied
> Bertho ???, You may call me Czerno, Herr Ehlert >> You can't escape having to explain what "adverse effects" you were evoking, >> now anyway. > command.com is a 'normal' program. just allocating DOS memory will > give you an environment at ~1800:0. not such a good idea. You are joking, Her

Re: [Freedos-user] command.com (Freecom) main environment location

2013-07-08 Thread Bertho Grandpied
>> You may call me Czerno, Herr Ehlert > your email signature reads "Bertho Grandpied " > that translates to Bob Bigfoot, right ? Ask Yahoo!... Then if you insist on calling me Bertho, be my guest. >> And EVEN if for some reason HMA was not available or not given to &

Re: [Freedos-user] command.com (Freecom) main environment location

2013-07-08 Thread Bertho Grandpied
Att: Rugxulo Hi, > Patience, young padawan. I had to look that padawan up on wOOkipedia (not a typo!) :=) > Things like this take time and thought (and research and testing). Accepted. I've passed the message, now letting things ripen (and tone down

[Freedos-user] Re : Freedos-user Digest, Vol 808, Issue 1

2013-07-08 Thread Bertho Grandpied
Hi, Matej Horvat: > I've spent the last three hours writing a tiny COM program that moves > COMMAND.COM's environment block to the lowest address possible (using > DOS's "low memory first fit" strategy). Nice ! > Unfortunately, it does not seem to   > be able to find the environment block if u

Re: [Freedos-user] command.com (Freecom) main environment location

2013-07-09 Thread Bertho Grandpied
On Mon, 8 Jul 2013 16:29:14 +0200 Tom Ehlert >> I may sound harsh, but being accused of ignorance by >> more ignorant is the only word of excuse I will utter. > this 'more' makes me think that you should prove your competence first I agree. The above quoted phrase was a late minute, unfort

Re: [Freedos-user] command.com (Freecom)

2013-07-09 Thread Bertho Grandpied
Hi again, Tom... > that's how 'edit the parent/master environment' utilities work(ed), > it's 'documented undocumented' behaviour, and FreeCOM behaves > and has to behave) the same way. It's a good point, but it was not written in stone. Thus it is nice - for our purpose - that FreeCM taking com

Re: [Freedos-user] command.com (Freecom) main environment location

2013-07-09 Thread Bertho Grandpied
Tom Ehlert wrote : > sure your particular problem could be solved by freecom, but nobody > will spend time on this. Still, Rugxulo, I think, has suggested one could ping Bart Oldemann with the question. Now, after you have pointed out very plausibly that FreeCOM does not hold "hidden" pointer

[Freedos-user] DOS networking with embedded Realtek PCIe - 8168

2018-08-18 Thread Bertho Grandpied via Freedos-user
Had anyone been successfully DOS-networking using the RT Gigabit adapter in Subj, I will humbly take their lessons. My new board (Biostar A68MD-Pro with AMD A10 CPU) has embedded Realtek 8168 GB ethernet controller, for which I sought a DOS "packet driver". At Realtek's site, no packet driver

Re: [Freedos-user] DOS networking with embedded Realtek PCIe - 8168

2018-08-19 Thread Bertho Grandpied via Freedos-user
rearrange frame | hierarchy;  there are several odipkt driver | you may have to hunt try way back | machine On Saturday, August 18, 2018, Bertho Grandpied via Freedos-user < freedos-user@lists.sourceforge.net> wrote: > Had anyone been successfully DOS-networking using the RT Gigabit adap

Re: [Freedos-user] DOS networking with embedded Realtek PCIe - 8168

2018-08-19 Thread Bertho Grandpied via Freedos-user
> After fleshing out the net.cfg to a > bare minimum - leaving Ethernet-II framing /only/ - it is > working now ! I've received in-private request to display the contents of the so fleshed out NET.CFG. Thanks for asking. ! Here is the resultant, FWIW - it could hardly be simpler : ---