You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(14) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(166) |
Feb
(219) |
Mar
(351) |
Apr
(190) |
May
(136) |
Jun
(148) |
Jul
(269) |
Aug
(198) |
Sep
(167) |
Oct
(16) |
Nov
(68) |
Dec
(15) |
2005 |
Jan
(54) |
Feb
(6) |
Mar
(10) |
Apr
(14) |
May
(8) |
Jun
(6) |
Jul
(16) |
Aug
|
Sep
(12) |
Oct
(15) |
Nov
(16) |
Dec
(22) |
2006 |
Jan
(14) |
Feb
(12) |
Mar
(1) |
Apr
(3) |
May
(10) |
Jun
|
Jul
(6) |
Aug
(5) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
(4) |
2007 |
Jan
(4) |
Feb
|
Mar
|
Apr
(1) |
May
(12) |
Jun
(11) |
Jul
(12) |
Aug
(1) |
Sep
(8) |
Oct
(17) |
Nov
|
Dec
(3) |
2008 |
Jan
|
Feb
(1) |
Mar
(4) |
Apr
(17) |
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
(10) |
Oct
(9) |
Nov
|
Dec
(12) |
2009 |
Jan
|
Feb
(16) |
Mar
|
Apr
(13) |
May
(103) |
Jun
(29) |
Jul
(61) |
Aug
(17) |
Sep
(9) |
Oct
(4) |
Nov
(14) |
Dec
(18) |
2010 |
Jan
(6) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(1) |
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
2011 |
Jan
|
Feb
|
Mar
(4) |
Apr
(9) |
May
(5) |
Jun
(8) |
Jul
(40) |
Aug
(10) |
Sep
(1) |
Oct
|
Nov
(3) |
Dec
(3) |
2012 |
Jan
(6) |
Feb
(18) |
Mar
(3) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
(3) |
2013 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
(22) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
2014 |
Jan
(1) |
Feb
(1) |
Mar
(4) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
|
Nov
|
Dec
|
2015 |
Jan
(2) |
Feb
(2) |
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
(20) |
Sep
|
Oct
|
Nov
(4) |
Dec
|
2016 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
|
May
(3) |
Jun
(3) |
Jul
(2) |
Aug
(5) |
Sep
|
Oct
(1) |
Nov
(9) |
Dec
(7) |
2017 |
Jan
(7) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(2) |
Nov
(2) |
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Jim H. <jh...@fr...> - 2020-05-17 19:57:39
|
Hi freedos-kernel developers: I think everyone on this email list is also on freedos-devel, so you probably have seen the discussion there about the different communication channels for FreeDOS. We obviously use the freedos-devel and freedos-user email lists. But the freedos-kernel list is not used very much. Looking at the archive, this hasn't seen more than a few emails per *year* in the last several years. Because of the light traffic, let's consolidate our developer discussions! The freedos-kernel email list will be closed this week. Instead, please use the freedos-devel email list to discuss any FreeDOS kernel development topics. Thanks! Jim |
From: Eric A. <e....@jp...> - 2020-04-22 16:02:30
|
Hi kernel readers :-) Looking at the development of dosemu2, I find that the many changes there have moved away from freedos SO far that backporting became hard, without me ever noticing. There was the announcement of fdpp in 9/2018, one year after development started, which morphs the kernel into a Linux lib for dosemu2: https://github.com/stsp/fdpp (excuse the extreme simplification of my description) But there apparently never was a discussion about the improvements in fdpp here, very few people at dosemu2 were in the mood to backport things, possibly inspired by the lack of bugzilla readers here and the very few original FreeDOS kernel people who took the effort to cherry pick patches apparently have not shared their capacity bottlenecks here. E.g. Andrew Bird has sent https://github.com/PerditionC/fdkernel and https://github.com/FDOS/kernel some patches and Jeremy has started some cherry picking himself? So what have we missed during all that time, 2.5 years? - fdpp solves obscure MCB / UMB related problems which made FreeDOS unable to use UMB at a000:0 including stack overflows and reboot troubles? - dosemu2 needs some FreeDOS-only "boot work-around" if hdiskboot -1, hdisks >0 and hdisk 0 is not bootable...? (probably to help us to boot from D: drive or similar) - some boot changes (not sure whether dosemu2 specific) on https://github.com/dosemu2/fdpp/commit/10507295bdea1dee3109ed115dc0dc38f98d2565#commitcomment-35887845 - FreedOS 1.2 and older has no int 2f.121f, just 2f.1217, but that might have been fixed back in FreeDOS recently? - many games work better with fdpp than with FreeDOS, says https://github.com/dosemu2/fdpp/releases/tag/beta-9 (Test Drive 2, Tetris Classic, Elite Frontier, Empire Soccer, Virtual Chess, Alone in the Dark, Alpha Waves) - however, for example int 21.71a6 in fdpp may only be used in conjunction with dosemu2, according to the same site?? - fdpp fixes something related to Volkov Commander: https://github.com/dosemu2/fdpp/releases/tag/rc-1 This also mentions 2 of the above games "resize PSP to 0 and then terminate it" which apparently MS DOS accepts - probably a lot more Note that fdpp development seems much faster than freedos kernel devel in part because dosemu2 disciples love their toolchain, but dispise the tools available for real DOS? Please, it is nice to have a few very active experts in a few DOS related projects, but why do I have to feel like an eavesdropper when figuring out which bugs get fixed and which features get added? It looks a lot like many of those probable improvements never made it to FreeDOS kernel sys because people fail to talk about them across projects. So please talk about those things on freedos-kernel! If you know about a bug in FreeDOS, talk about it. If you know about a fix in fdpp and lack the time to backport it to FreeDOS, at least mention it here. If you know about compatibility issues, do not just drop from this list and install fdpp or MS DOS. Talk about it! For those who have not experienced dosemu2 yet: Note that it has less magic guest drivers, so you WILL have to LOAD them in your config sys. Read their pre-installed config. Dosemu2 is a QUICKLY moving target and following their github feels like spying on a private chat, but most of the time the improvements outnumber the regressions and it work much better than the stalled classic dosemu :-) I hope there are still some people HERE who are keen on kernel improvements. Maybe we can wake up and at least find out how FreeDOS 1.3 (and up) kernels COULD improve. Thank you! Regards, Eric PS: Excuse the cross-post CC to freedos-devel. It is for the case that there are not enough kernel readers left. |
From: Robert R. <rr...@bt...> - 2020-03-19 18:52:19
|
Hi Jeremy, > Hi per...@gm..., > >> Thank you. I will try to get to this by the weekend. > > Thanks! :-) > > Regarding the "Space between value and currency symbol" bit errors: > I checked my statement about a space between value and the € sign. > Various Internet sources, e.g., > <https://de.wikipedia.org/wiki/Schreibweise_von_Zahlen#Ma%C3%9Feinheit>, > <http://buerojob-blog.de/2012/11/19/schreibweise-euro/>, > <https://publications.europa.eu/code/de/de-370303.htm#position>, tell, > that there should be a space between. > > *** From publications.europa.eu: *** > Das Symbol € steht hinter dem Betrag und ist von diesem durch einen > Zwischenraum getrennt: > > ein Betrag von 30 € > > Anmerkung: > Im Englischen, Irischen, Maltesischen und im Niederländischen steht der > Code vor dem Betrag: > > an amount of €30 (ohne Zwischenraum) > *** > > "the amount is followed by a hard space and the euro sign" (except > English, Dutch, Irish, and Maltese) > > I've attached an updated diff file for German. Did my changes make it to the repo meanwhile? I don't see at <https://github.com/PerditionC/fdkernel/blob/master/kernel/country.asm>, but maybe it's the wrong URL? Cheers, Robert -- +++ BTTR Software +++ Home page: https://www.bttr-software.de/ DOS ain't dead: https://www.bttr-software.de/forum/ |
From: Robert R. <rr...@bt...> - 2020-01-24 15:10:51
|
Hi per...@gm..., > Thank you. I will try to get to this by the weekend. Thanks! :-) Regarding the "Space between value and currency symbol" bit errors: I checked my statement about a space between value and the € sign. Various Internet sources, e.g., <https://de.wikipedia.org/wiki/Schreibweise_von_Zahlen#Ma%C3%9Feinheit>, <http://buerojob-blog.de/2012/11/19/schreibweise-euro/>, <https://publications.europa.eu/code/de/de-370303.htm#position>, tell, that there should be a space between. *** From publications.europa.eu: *** Das Symbol € steht hinter dem Betrag und ist von diesem durch einen Zwischenraum getrennt: ein Betrag von 30 € Anmerkung: Im Englischen, Irischen, Maltesischen und im Niederländischen steht der Code vor dem Betrag: an amount of €30 (ohne Zwischenraum) *** "the amount is followed by a hard space and the euro sign" (except English, Dutch, Irish, and Maltese) I've attached an updated diff file for German. Cheers, Robert -- +++ BTTR Software +++ Home page: https://www.bttr-software.de/ DOS ain't dead: https://www.bttr-software.de/forum/ |
From: <per...@gm...> - 2020-01-23 21:40:53
|
Thank you. I will try to get to this by the weekend. Jeremy On Thu, Jan 23, 2020, 3:11 PM Robert Riebisch <rr...@bt...> wrote: > Hi > > for Germany COUNTRY.SYS reports "." (dot) for the time separator, when > it should be ":" (colon). > > I noticed the error in FD 1.3 RC2 and FD 1.2, when using: > > !COUNTRY=049,,C:\FDOS\BIN\COUNTRY.SYS > > in FDCONFIG.SYS. > > I didn't test FD 1.1. > > FD 1.0 behaves differently: Although it reports 001 for the current > country code (BX on return from AX=3800h, int21h), the time separator is > correct. > > I tracked the error down to: > > Bad data: > de_850 cnf 49,850,DMY,"E","U","R",0,0,".",",",".",".",1,2,_24; Germany > Tom > de_858 cnf 49,850,DMY,0D5h, 0,0,0,0,".",",",".",".",1,2,_24; Germany > de_437 cnf 49,437,DMY,"E","U","R",0,0,".",",",".",".",1,2,_24; Germany > > Good data: > de_850 cnf 49,850,DMY,"E","U","R",0,0,".",",",".",":",1,2,_24; Germany > Tom > de_858 cnf 49,858,DMY,0D5h, 0,0,0,0,".",",",".",":",1,2,_24; Germany > de_437 cnf 49,437,DMY,"E","U","R",0,0,".",",",".",":",1,2,_24; Germany > > In HELP -> "country" (not "country.sys") it is stated correctly as ":". > > If you don't patch 850 to 858 COUNTRY.SYS doesn't load with: > > !COUNTRY=049,858,C:\FDOS\BIN\COUNTRY.SYS > > because 49 858 are no valid combination. > > This is how I patched current COUNTRY.SYS to make it work: > 00003984: 2E 3A > 00003995: 52 5A > 000039A4: 2E 3A > 000039C4: 2E 3A > > > And I think, for Austria the time separator should also be ":". (see > lines 3075-3077 of COUNTRY.ASM) > > *************************************************************************** > > I just found a second data error. > If you use: > > !COUNTRY=049,437,C:\FDOS\BIN\COUNTRY.SYS > > loading COUNTRY.SYS aborts with error "could not find country info for > country ID 49". > > I fixed this by patching: > 0000041B: 5A B5 > 0000041C: 03 01 > > *************************************************************************** > > A third data error is regarding the "Space between value and currency > symbol" bit. It is reported as NO for codepage 437 and codepage 850. It > should be YES, because the symbol is "EUR" then. > For codepage 858 symbol is "€", so NO is correct here. > > I fixed this by patching: > 00003986: 01 03 > 000039C6: 01 03 > > *************************************************************************** > > Fourth error (?) > German MS-DOS 6.22 and Windows XP SP3 report ";" as the data-list > separator. > > I didn't find, where this is defined. So no patch from me. > > > As this mail and patch list got (and took) longer than expected, I'm > attaching a diff file. > > Maybe someone with access to the kernel sources can integrate this fix. > Thanks in advance! > > *************************************************************************** > > By the way: > To study the error and practice DOS programming I wrote a little tool to > show country information as reported by AX=3800h/INT 21h in some > "obscure" Pascal dialect from Japan called Cabezon. > The EXE file is currently available at > <https://www.bttr-software.de/tmp/COUNTRY.ZIP>. > I can provide source code too, if anyone is interested, but may be > currently of little use, because it depends on my expanded run-time > library for Cabezon, which is still pre-beta code. > > Output will be similar to: > ##### > Country code : 49 > Date format : 0001h (dd mm yy) > Time format : 01h (Bit 0: 24-hour clock = YES) > Thousands separator: . > Decimal separator : , > Date separator : . > Time separator : : > Data-list separator: , > Currency symbol : EUR > Currency format : 01h (Bit 0: Currency symbol follows value = YES > Bit 1: Space between value and currency symbol > = NO > Bit 2: Currency symbol replaces decimal point > = NO) > Currency precision : 2 > Case map routine : 00D8:11EF > ##### > > Cheers, > Robert > -- > +++ BTTR Software +++ > Home page: https://www.bttr-software.de/ > DOS ain't dead: https://www.bttr-software.de/forum/ > _______________________________________________ > Freedos-kernel mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freedos-kernel > |
From: Robert R. <rr...@bt...> - 2020-01-23 20:11:00
|
Hi for Germany COUNTRY.SYS reports "." (dot) for the time separator, when it should be ":" (colon). I noticed the error in FD 1.3 RC2 and FD 1.2, when using: !COUNTRY=049,,C:\FDOS\BIN\COUNTRY.SYS in FDCONFIG.SYS. I didn't test FD 1.1. FD 1.0 behaves differently: Although it reports 001 for the current country code (BX on return from AX=3800h, int21h), the time separator is correct. I tracked the error down to: Bad data: de_850 cnf 49,850,DMY,"E","U","R",0,0,".",",",".",".",1,2,_24; Germany Tom de_858 cnf 49,850,DMY,0D5h, 0,0,0,0,".",",",".",".",1,2,_24; Germany de_437 cnf 49,437,DMY,"E","U","R",0,0,".",",",".",".",1,2,_24; Germany Good data: de_850 cnf 49,850,DMY,"E","U","R",0,0,".",",",".",":",1,2,_24; Germany Tom de_858 cnf 49,858,DMY,0D5h, 0,0,0,0,".",",",".",":",1,2,_24; Germany de_437 cnf 49,437,DMY,"E","U","R",0,0,".",",",".",":",1,2,_24; Germany In HELP -> "country" (not "country.sys") it is stated correctly as ":". If you don't patch 850 to 858 COUNTRY.SYS doesn't load with: !COUNTRY=049,858,C:\FDOS\BIN\COUNTRY.SYS because 49 858 are no valid combination. This is how I patched current COUNTRY.SYS to make it work: 00003984: 2E 3A 00003995: 52 5A 000039A4: 2E 3A 000039C4: 2E 3A And I think, for Austria the time separator should also be ":". (see lines 3075-3077 of COUNTRY.ASM) *************************************************************************** I just found a second data error. If you use: !COUNTRY=049,437,C:\FDOS\BIN\COUNTRY.SYS loading COUNTRY.SYS aborts with error "could not find country info for country ID 49". I fixed this by patching: 0000041B: 5A B5 0000041C: 03 01 *************************************************************************** A third data error is regarding the "Space between value and currency symbol" bit. It is reported as NO for codepage 437 and codepage 850. It should be YES, because the symbol is "EUR" then. For codepage 858 symbol is "€", so NO is correct here. I fixed this by patching: 00003986: 01 03 000039C6: 01 03 *************************************************************************** Fourth error (?) German MS-DOS 6.22 and Windows XP SP3 report ";" as the data-list separator. I didn't find, where this is defined. So no patch from me. As this mail and patch list got (and took) longer than expected, I'm attaching a diff file. Maybe someone with access to the kernel sources can integrate this fix. Thanks in advance! *************************************************************************** By the way: To study the error and practice DOS programming I wrote a little tool to show country information as reported by AX=3800h/INT 21h in some "obscure" Pascal dialect from Japan called Cabezon. The EXE file is currently available at <https://www.bttr-software.de/tmp/COUNTRY.ZIP>. I can provide source code too, if anyone is interested, but may be currently of little use, because it depends on my expanded run-time library for Cabezon, which is still pre-beta code. Output will be similar to: ##### Country code : 49 Date format : 0001h (dd mm yy) Time format : 01h (Bit 0: 24-hour clock = YES) Thousands separator: . Decimal separator : , Date separator : . Time separator : : Data-list separator: , Currency symbol : EUR Currency format : 01h (Bit 0: Currency symbol follows value = YES Bit 1: Space between value and currency symbol = NO Bit 2: Currency symbol replaces decimal point = NO) Currency precision : 2 Case map routine : 00D8:11EF ##### Cheers, Robert -- +++ BTTR Software +++ Home page: https://www.bttr-software.de/ DOS ain't dead: https://www.bttr-software.de/forum/ |
From: aoi k. <aoi...@gm...> - 2019-08-18 12:58:48
|
Hi All, I have added line by line comments to the four boot loaders `boot.asm`, `boot32.asm`, `boot32lb.asm`, and `oemboot.asm`. Check out [this post] <https://aoik.me/blog/posts/freedos-source-code-study-boot-sector>. Are you interested in merging these comments into the code base? Regards Aoik |
From: C. M. <cm...@bt...> - 2018-11-05 15:00:47
|
On at 2018-11-05 15:51 +0100, Tom Ehlert wrote: >> the FreeDOS kernel is seriously slower then MSDOS when doing >> larger copy/xcopy operations. > >> the cause: the disk I/O code avoids transfers that cross a 64K >> boundary, and splits these transfers into 3 (smaller) transfers. > >> this was needed for floppy controllers in the 1980's, but is certainly >> not necessary for harddisks after the IBM XT. > > >> just skip > > >> /* avoid overflowing 64K DMA boundary */ >> count = DMA_max_transfer(buffer, totaltodo); > >> for harddisks, and everything should be *much* faster (at least on >> rotating media in a non-emulated machine) > > investigating in this a bit more, the 64K boundary was/is a problem > with ISA DMA, used only for floppies (and sometimes serial/parallel > ports), but is no problem for UDMA. > > skipping this test for drives with 0x80 set should be save, and result > in a significant speedup of large disk transfers. Another possibility is to depend on the error code (ah = 09h, RBIL lists this as "data boundary error (attempted DMA across 64K boundary or >80h sectors)") and retry the calls to avoid 64 KiB boundaries only then. I've had success with that when loading from an actual diskette drive; the error is properly reported and handled this way. Regards, ecm |
From: Tom E. <te...@dr...> - 2018-11-05 14:52:53
|
> the FreeDOS kernel is seriously slower then MSDOS when doing > larger copy/xcopy operations. > the cause: the disk I/O code avoids transfers that cross a 64K > boundary, and splits these transfers into 3 (smaller) transfers. > this was needed for floppy controllers in the 1980's, but is certainly > not necessary for harddisks after the IBM XT. > just skip > /* avoid overflowing 64K DMA boundary */ > count = DMA_max_transfer(buffer, totaltodo); > for harddisks, and everything should be *much* faster (at least on > rotating media in a non-emulated machine) investigating in this a bit more, the 64K boundary was/is a problem with ISA DMA, used only for floppies (and sometimes serial/parallel ports), but is no problem for UDMA. skipping this test for drives with 0x80 set should be save, and result in a significant speedup of large disk transfers. Tom |
From: Tom E. <te...@dr...> - 2018-10-30 14:05:28
|
Hi everybody, the FreeDOS kernel is seriously slower then MSDOS when doing larger copy/xcopy operations. the cause: the disk I/O code avoids transfers that cross a 64K boundary, and splits these transfers into 3 (smaller) transfers. this was needed for floppy controllers in the 1980's, but is certainly not necessary for harddisks after the IBM XT. just skip /* avoid overflowing 64K DMA boundary */ count = DMA_max_transfer(buffer, totaltodo); for harddisks, and everything should be *much* faster (at least on rotating media in a non-emulated machine) Tom |
From: Tom E. <te...@dr...> - 2018-10-30 14:05:22
|
if exist K:\NUL echo K: is present is broken in kernel 2042 the bug is caused by a change in TrueName(), where code was changed from cdsEntry = get_cds(result); if (cdsEntry == NULL) return DE_PATHNOTFND; to dhp = IsDevice(src); cdsEntry = get_cds(result); if (cdsEntry == NULL) { /* workaround for a device prefixed with invalid drive (e.g. "@:NUL") */ /* (MS-DOS always return drive P: for invalid drive. Why P:?) */ if (dhp) { result = default_drive; cdsEntry = get_cds(result); if (cdsEntry == NULL) return DE_PATHNOTFND; } else return DE_PATHNOTFND; } now truename("e:\NUL") returns not 'path not found', but 'isDevice' probably by fixing one bug, another bug was introduced. Unfortunately I don't know what bug the changed is supposed to fix... who introduced this change and why? comments? Tom |
From: Stas S. <st...@li...> - 2018-09-09 01:12:38
|
Hi all DOS fans! After a year of development, I am glad to announce the new 64bit DOS. But as we know, all new is well-forgotten old, so this actually is a freedos kernel port to 64 bits. Some of you have probably already heard about this project, as it was pre-announced on fosdem-18, but at that time it could barely display the copyright msg. So I bet no one believed this is even possible. :) And here we go: https://github.com/stsp/fdpp The description of the project and the usage instructions are in the readme: https://github.com/stsp/fdpp/blob/master/README.md The current status is on the releases page: https://github.com/stsp/fdpp/releases This is going to be the primary DOS for dosemu2, but I hope it will be useful for other projects too. For example the freedos-32 project: http://freedos-32.sourceforge.net/ can likely get a very good use of it. I don't know if the main freedos project can be interested in a 64bit port of it, but I think there were some talks in the past, including Pat V himself, which I unfortunately can't google out now. Let's see what people think. The next target is going to be a 64bit command.com. While it is in some distant future, the 32bit command.com is already here: https://github.com/stsp/comcom32 So lets move on to 64bits! Happy DOSing. :) |
From: Tom E. <te...@dr...> - 2017-02-01 13:26:20
|
am 1. Februar 2017 um 01:23 schrieben Sie: > this patch is a suggestion for the bootsector to boot on older (like my XT) machines > where the drive requires a few retries before loading a sector. The resulting binary > might be too big actually. that is a clear indication that you did not test this. why do you expect that we do YOUR work ? Tom > In this case I would like a bit of help fitting it in there. > yours, > - Mdasoh Kyaeppd > --- boot.ori/boot.asm 2017-01-30 02:08:55.835437500 -0700 > +++ boot/boot.asm 2017-01-31 13:06:37.742679500 -0700 > @@ -423,7 +423,7 @@ > ; setup LBA disk block > mov LBA_SECTOR_32,bx ; bx is 0 if extended 13h mode supported > mov LBA_SECTOR_48,bx > - > + mov si,1 > mov ah,042h > jmp short do_int13_read > @@ -472,12 +472,20 @@ > inc cx ; make sector 1-based (1-63) > les bx,[LBA_OFF] > + mov si,5 > +do_chs_read: > mov ax, 0x0201 > do_int13_read: > mov dl, [drive] > - int 0x13 > - jc boot_error ; exit on error > + int 0x13 ; read data from disk > + jnc did_int13_read > + xor ax,ax > + int 0x13 > + dec si > + jz boot_error ; exit on error > + jmp do_chs_read ; prod it a few times > +did_int13_read: > mov ax, word [bsBytesPerSec] > push di > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Freedos-kernel mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freedos-kernel Mit freundlichen Grüßen/Kind regards Tom Ehlert +49-241-79886 |
From: Mdasoh K. <mingdaisung@Safe-mail.net> - 2017-02-01 00:23:39
|
this patch is a suggestion for the bootsector to boot on older (like my XT) machines where the drive requires a few retries before loading a sector. The resulting binary might be too big actually. In this case I would like a bit of help fitting it in there. yours, - Mdasoh Kyaeppd --- boot.ori/boot.asm 2017-01-30 02:08:55.835437500 -0700 +++ boot/boot.asm 2017-01-31 13:06:37.742679500 -0700 @@ -423,7 +423,7 @@ ; setup LBA disk block mov LBA_SECTOR_32,bx ; bx is 0 if extended 13h mode supported mov LBA_SECTOR_48,bx - + mov si,1 mov ah,042h jmp short do_int13_read @@ -472,12 +472,20 @@ inc cx ; make sector 1-based (1-63) les bx,[LBA_OFF] + mov si,5 +do_chs_read: mov ax, 0x0201 do_int13_read: mov dl, [drive] - int 0x13 - jc boot_error ; exit on error + int 0x13 ; read data from disk + jnc did_int13_read + xor ax,ax + int 0x13 + dec si + jz boot_error ; exit on error + jmp do_chs_read ; prod it a few times +did_int13_read: mov ax, word [bsBytesPerSec] push di |
From: Nando E. <nan...@ym...> - 2017-01-31 12:32:50
|
Hi, I noticed was getting more messages appearing during my bootup with kernel 2042 compared to 2041. Upon investigation, I found it is not passing any switches given in fdconfig.sys install=<command> <swiches> to the command. This is the case also of installhigh. eg fdconfig.sys lines: 2345?install=\DOS\ansi.com /q 6?install=\core\tm.exe /43 Confirmed behaviour under kernel 2041* ansi.com quietly loads as directed (/q)* tm.exe (inkutils) switches to 80x43 mode as directed (/43) Confirmed behaviour under 2042* ansi.com ignores /q and prints usage messages* tm.exe does not switch to 80x43 mode, instead reports current mode consistent as if no switch given. This and the NUL drive/dir bug I reported several days ago, with a hotfix kernel provide by Tom, are pretty big bugs. For now I've gone back to 2041 as am concerned about other nasties I've yet to discover. Nando |
From: Nando E. <nan...@ym...> - 2017-01-27 02:44:19
|
Tom, screenshots at http://imgur.com/a/h9x9c showing kernel 2042 always identifying e:\nul as present (attrib e:\nul or if exist e:\nul), even though it is not. Kernel 2041 correctly identifies it as not present. A fix for this would be great so I can again check for drive/dir existence using the NUL filename. Thank you,Nando On Friday, 27 January 2017, 3:42, Tom Ehlert <te...@dr...> wrote: Hi, > Was using FreeDOS 1.1 2040 kernel? previously and could check for > drive or directory existence with the NUL device: > If exist c:\nul echo C: exists > If exist c:\mydir\nul echo C:\mydir exists > This behavior is broken with 2042, no longer being able to identify if a drive/dir exists anymore. I tried to reproduce this here, and I think that it behaves exactly as it should. can you be more specific how it fails ? Tom |
From: Tom E. <te...@dr...> - 2017-01-26 16:42:14
|
Hi, > Was using FreeDOS 1.1 2040 kernel? previously and could check for > drive or directory existence with the NUL device: > If exist c:\nul echo C: exists > If exist c:\mydir\nul echo C:\mydir exists > This behavior is broken with 2042, no longer being able to identify if a drive/dir exists anymore. I tried to reproduce this here, and I think that it behaves exactly as it should. can you be more specific how it fails ? Tom |
From: Nando E. <nan...@ym...> - 2017-01-26 07:32:33
|
Was using FreeDOS 1.1 2040 kernel? previously and could check for drive or directory existence with the NUL device: If exist c:\nul echo C: existsIf exist c:\mydir\nul echo C:\mydir exists This behavior is broken with 2042, no longer being able to identify if a drive/dir exists anymore. Can the devs please add the previous behaviour with NUL drive/directory identification? Thank you |
From: Louis S. <lps...@gm...> - 2017-01-05 21:20:16
|
See the FreeDOS Spec [0]. OpenWatcom C/C++ (1.9?) (and by extension WASM/JWASM? for ASM??) and NASM (no version either though many are based on 0.98.x) are the reference compilers/assemblers/linker. I was able to able to compile a recent kernel version with the non-reference compiler Borland C/C++ 4.5.2 (the last Borland C/C++ compiler to support DOS compiling executables). I had to make minor changes to the Makefiles to successfully compile the kernel. See the mailing list archives for my notes. [0] http://wiki.freedos.org/wiki/index.php/FreeDOS_Spec#Programming_tools On Wed, Jan 4, 2017 at 11:17 PM, Mateusz Viste <ma...@no...> wrote: > On Wed, 04 Jan 2017 18:59:25 -0800, Ben Hutchinson wrote: >> Of all the many files in the FreeDOS sourcecode, which files will I need >> if I just want to compile the bootsector and the kernel? > > You'll need the source files present in the "KERNEL" package, > unsurprisingly. You can also fetch these sources on-line here: > https://sourceforge.net/p/freedos/svn/HEAD/tree/kernel/trunk/ > >> And also, what is the recommended free compiler (I'm >> not about to spend money to buy one) for use in compiling the FreeDOS >> bootsector and kernel? > > The FreeDOS kernel can supposedly be compiled with the following > compilers: MS C, Watcom C, Turbo C, Turbo C++, Borland C. > >From those, I have tested successfully Open Watcom and Turbo C 2.01. Both > are free (no cost). Using Turbo C requires to change a few lines of > comments though, as I wrote here the 26th November of last year (still > not fixed on SVN). > > Mateusz > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Freedos-kernel mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freedos-kernel |
From: Mateusz V. <ma...@no...> - 2017-01-05 07:18:32
|
On Wed, 04 Jan 2017 18:59:25 -0800, Ben Hutchinson wrote: > Of all the many files in the FreeDOS sourcecode, which files will I need > if I just want to compile the bootsector and the kernel? You'll need the source files present in the "KERNEL" package, unsurprisingly. You can also fetch these sources on-line here: https://sourceforge.net/p/freedos/svn/HEAD/tree/kernel/trunk/ > And also, what is the recommended free compiler (I'm > not about to spend money to buy one) for use in compiling the FreeDOS > bootsector and kernel? The FreeDOS kernel can supposedly be compiled with the following compilers: MS C, Watcom C, Turbo C, Turbo C++, Borland C. >From those, I have tested successfully Open Watcom and Turbo C 2.01. Both are free (no cost). Using Turbo C requires to change a few lines of comments though, as I wrote here the 26th November of last year (still not fixed on SVN). Mateusz |
From: Ben H. <be...@gm...> - 2017-01-05 02:59:32
|
Of all the many files in the FreeDOS sourcecode, which files will I need if I just want to compile the bootsector and the kernel? I don't care to build command.com, or any of the tools that normally come with a full copy of FreeDOS. And also, what is the recommended free compiler (I'm not about to spend money to buy one) for use in compiling the FreeDOS bootsector and kernel? |
From: Tom E. <te...@dr...> - 2016-12-09 14:07:05
|
>>From the point of view of protecting this system from counterfeiting & > unauthorised access, is it possible to interrupt processing config.sys? I > had read about pressing F5 to bypass config.sys and autoexec.bat. Also that > this can be disabled in config.sys. modify kernel.sys by using sys config kernel.sys SKIPCONFIGSECONDS=-1 to disable F5/F8 completely. OTOH, removing command.com will also completely disable tinkering with the system. > Another thought I have - what would the behaviour of the kernel be if my > program (as the command processor) does terminate? Does it reboot, restart > the command processor, or just hang? most likely just hang. test yourself. Tom |
From: David K. <dk...@qb...> - 2016-12-09 13:22:53
|
Thanks! It looks like the shell directive does exactly what I want. It defines what the kernel loads as the command processor. I'm in a funny situation where I only have just over 6 months total experience with DOS, and yet I'm writing DOS software for machinery which is 200 miles away... Not ideal, but it is what it is. >From the point of view of protecting this system from counterfeiting & unauthorised access, is it possible to interrupt processing config.sys? I had read about pressing F5 to bypass config.sys and autoexec.bat. Also that this can be disabled in config.sys. That seemed like a chicken and egg situation to me - disabling processing of config.sys by executing config.sys ? What if F5 is pressed before config.sys is loaded? The system doesn't have a keyboard plugged in, but it's not impossible to plug one in if you're interested in poking around the system. However, if I completely removed command.com and all other commands then the kernel wouldn't be able to load anything. Another thought I have - what would the behaviour of the kernel be if my program (as the command processor) does terminate? Does it reboot, restart the command processor, or just hang? -- View this message in context: http://freedos.10956.n7.nabble.com/Can-the-Kernel-start-my-program-instead-of-command-com-tp25676p25679.html Sent from the FreeDOS - Kernel mailing list archive at Nabble.com. |
From: Mateusz V. <ma...@no...> - 2016-12-09 12:03:36
|
On Fri, 09 Dec 2016 02:07:24 -0700, David Kay wrote: > Is it possible to get the kernel to load my program directly instead of > via autoexec.bat? Then my system would just be composed of the kernel > and my program? Have you tried to declare your program in CONFIG.SYS using the SHELL= directive ? Seems like an easy test that would provide you with the answer you look for. Renaming your program to COMMAND.COM is also a possible test, albeit perhaps less elegant. I wouldn't expect troubles, but as usual, testing it out is the only way to be sure. cheers, Mateusz |
From: David K. <dk...@qb...> - 2016-12-09 10:55:50
|
Currently the program uses a separate DPMI host. But I believe I can prepend my program with a DPMI host so that it starts directly in real mode? Would renaming this executable to command.com enable the kernel to load it directly? -- View this message in context: http://freedos.10956.n7.nabble.com/Can-the-Kernel-start-my-program-instead-of-command-com-tp25676p25677.html Sent from the FreeDOS - Kernel mailing list archive at Nabble.com. |